Connect your context once, and every agent can reach it — from Claude Code, Cursor, and ChatGPT to your own backend — over MCP and REST. One retrieval layer instead of a pipeline per tool, every fact traceable from commit to rank, at a fraction of the tokens.
No card required · first retrieval in ~5 minutes
Agents connect over MCP with OAuth handled for you. Your product calls the same retrieval over REST with an API key. Same context, same ranking, same provenance either way.
Claude Code, Cursor, ChatGPT, or any MCP-aware agent. OAuth 2.0 with dynamic client registration means no keys to mint — your agent signs in and starts retrieving.
{
"mcpServers": {
"aidrop": {
"url": "https://mcp.aidrop.it/mcp"
}
}
}One POST with tenant context. Every chunk returns rank signals, and include_provenance attaches the commit history behind each page.
curl https://api.aidrop.it/v1/context/search \
-H "Authorization: Bearer $AIDROP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"query": "how do we isolate tenant data?",
"include_provenance": true
}'Quickstart, guides, Python and TypeScript SDKs, and the full API reference in the docs.
Every platform ships retrieval that feeds only its own models, explains nothing, and still leaves you rebuilding the same plumbing around it.
OpenAI's file search serves OpenAI. Gemini's serves Gemini. Azure's lives in Azure. The moment your agents span tools — and they already do — your context doesn't follow them.
When an agent answers wrong, nothing tells you which chunk came back or why it ranked. Opaque retrieval is the most repeated complaint developers make about platform search — debugging it is guesswork.
Teams spend months on embedding pipelines and vector stores, then pay for idle clusters before the first query. The pipeline was never your edge — the context is.
Model vendors can't build this without feeding their competitors' models — an independent layer can. Describe your context once and stop re-integrating it per tool, per model, per quarter.
Claude Code, Cursor, ChatGPT, and any MCP-aware client hit the same retrieval endpoint. OAuth 2.0 with dynamic client registration is in production — connecting a new tool is a paste, not a project.
The same layer answers your backend over REST, with Python and TypeScript SDKs. Post documents, search with tenant context, ship the retrieval part of your AI feature in days.
37% of enterprises already run five or more models in production. Vendor retrieval can't follow a model swap — a context layer that belongs to you does, unchanged.
Every answer decomposes: which chunk, from which commit, recorded by whom, matched by which signal — full-text, semantic, or link-graph — and with what rerank score. In the dashboard and in every API response.
Your context is versioned like code, so provenance isn't a log we bolted on — it's the storage model. When an agent answers from your data, you can show your compliance team, your customers, and yourself exactly where every fact came from and how it changed over time.
Five stages, all managed — you never stand up a vector store, tune an index, or babysit freshness.
Connect a GitHub repo, Notion, or upload files. With git sources the content stays in your repository — we index chunks, not copies of your knowledge base.
Chunking follows your headings instead of arbitrary windows, with multilingual embeddings — your context works in English, German, or anything else your team writes.
Full-text, semantic, and link-graph retrieval run together, get fused, and a cross-encoder reranks the result. Most managed retrieval has no graph leg at all.
Agent clients connect over MCP with OAuth. Your product calls REST with an API key and SDKs. One retrieval layer behind both.
Rank signals on every chunk, commit history on every page, and an audit trail attributing every call to a user and client.
To find or update context, an agent greps and re-reads — and the stateless API re-sends the whole growing transcript on every call. One targeted retrieval replaces the loop. Drag the sliders to your reality; the numbers update live.
How the estimate works: each grep/read step appends ~30k to the transcript, and the stateless API re-sends the whole transcript on every call — with 20 steps you pay for it roughly N(N+1)/2 times over. The re-sent transcript is billed at cache-read rates (~0.1× input) and each step's new output at cache-write (~1.25×), so the dollar figure already accounts for prompt caching. The alternative is a single ~30k-token retrieval — the relevant slice of your context, not the whole corpus — over 22 working days at $5/1M input.
See pricing for your usageCoding agents meter usage in windows — burn through yours and work stops until it resets. A grep loop bills the re-sent transcript against that window on every step; a retrieval bills once. At your slider settings that's 6.3M versus 30k tokens per task.
Our context-merge pipeline used to load the whole vault into the model on every run. We routed it through the same retrieval you get — fetching only the pages a write touches — and the cost fell off a cliff. Same output, a fraction of the tokens.
Our own context-merge pipeline runs through the same endpoint we sell. When it loaded the whole vault per run, we felt it in our bill — retrieval cut those writes 20×.
A golden set of queries scores recall and ranking quality on every change, so search quality is a regression-tested number — not something we eyeball after a deploy.
We publish reproducible comparisons against black-box file search on realistic corpora. Want it proven on your own data? That's what the free tier is for.
Security review shouldn't be where your retrieval vendor falls over. Isolation, access control, and attribution are in the foundation — because our first user was our own team.
Every row carries the team, every index routes by it, every query filters by it. Multi-tenant separation is the storage model, not a setting you can forget to flip.
Invite teammates with scoped roles. Remove someone and their OAuth tokens die with the membership — no orphaned access from a laptop you forgot about.
Each retrieval and write is logged down to the user and the client that made it — the answer to "who asked what, from where" is a query, not an investigation.
Connect your repository and the source of truth never moves — we index chunks for search, while your knowledge stays under your access control and your history.
Your users don't live on your docs site — they live in Cursor and Claude Code. Connect your docs repository, hand them one MCP endpoint, and their agents answer from documentation that's current as of your last merge.
Not a chat widget on your website — your docs as a first-class tool inside the IDE where questions actually come up. And you see what your users ask, which is the roadmap input your docs team never had.
Usage you can compute before you commit — no surprise bills for idle clusters, no "contact sales" wall in front of a number.