One endpoint for your agents, within limits
Give AI agents one MCP endpoint: search and lookup tools over the records in a KiviDB database, plus the tools of your own MCP servers, with keys that carry server-side filters and credentials...
Describe the records already in a database as a context model, and put your own MCP servers behind it. Agents connect to one MCP endpoint with a key that decides what they may see: which records, through filters they cannot get past, and which of your servers, whose credentials stay on the gateway.
Describe it once, the tools follow
- Entities Each kind of record: the keys under a prefix, stored as hashes or JSON, the fields an agent may search and read, and how records relate.
- Tools search, get and related records for every entity, such as search_customer and customer_orders, with the descriptions an agent needs to choose between them.
- Only your fields Records come back with the id and the fields in the model. Anything else in the key, an internal note or a hash, is never returned.
Your MCP servers, behind one endpoint
Add up to ten of your own remote MCP servers to a gateway. Agents see their tools next to the model's, each under its server's name.
- Namespaced tools A server added as crm brings its tools as crm__find_contact and so on, so two servers can both have a search tool.
- Only what a key allows A key reaches only the servers on its list. Keys made before upstreams existed reach none, so nothing changes for them.
- Limits you can count on Streamable HTTP over https only. A call gets 15 seconds and 1 MB of answer, and a longer answer is cut and marked. Tool lists are kept for five minutes, or refreshed from the console.
Search the tools, not the whole list
A gateway with many servers can bring hundreds of tools, more than an agent should carry in its context.
- Two tools instead of hundreds With tool search on, an agent sees search_tools and call_tool. It describes what it wants to do and gets the few tools that fit, with their schemas.
- Ranked by meaning Tool names and descriptions are compared by meaning with an embedding model that runs inside KiviDB Cloud, so a search for the weather finds get_forecast.
- Per key or for the gateway Turn it on for the whole gateway, or for the keys of agents that need it.
Filters the agent cannot remove
- Row-level filters A key can carry filters such as tenant = acme. Every query through it adds them on the server, so a record outside them is not found, whatever the agent asks for. Many gateways can only hide whole kinds of record; this hides the rows.
- Limited to some entities A key can be limited to some of the model's entities; the others' tools are not even listed.
- Shown once, revoked any time Keys are stored only as a hash and limited to 600 calls a minute each. Revoke one and the agent is refused at once.
Credentials stay on the gateway
- Stored sealed A server's bearer token or custom headers are encrypted when saved and never shown again, not in the console and not through the API.
- Never seen by the agent The gateway adds them to each call it makes for the agent. If a server repeats them back, they are removed from the answer.
- Only public addresses The gateway refuses private, loopback and cloud metadata addresses, checks the address again each time it connects, and never follows a redirect.
With the rest of KiviDB
- Over live tables Point a model at the keys a data integration pipeline keeps from PostgreSQL or MySQL, and agents read your tables at memory speed.
- MCP or HTTP Any MCP client connects with one block of configuration; agents without MCP list and call the same tools over plain HTTP.
- No extra charge The indexes and caches use the database's own memory, and calling the tools costs nothing beyond the database.
Questions
Is this the context retriever?
Yes, renamed. Models, agent keys, the endpoint and its kvctx_ keys are unchanged, so agents set up before keep working.
Which MCP servers can I add?
Remote servers that speak the Streamable HTTP transport at a public https address. Servers that run as a local process (stdio) cannot be reached from the gateway.
Can it cache what my servers answer?
Yes, per server and off by default: identical calls, the same tool with the same arguments, are answered from the database for up to 300 seconds. Turn it on only for servers whose tools just read, since a cached call does not reach the server.
Can I try a tool before giving it to an agent?
Yes. The console runs any tool, the model's or a server's, and shows the result exactly as an agent gets it, either seeing everything or as one of the gateway's keys would.
Does it change my data?
The model's own tools only read, and deleting a model drops its indexes but never touches the records. What a server's tools do is up to that server.
Does it work on sharded databases?
Not yet. Context models run on databases without shards.
Give your agent the right context
Create a context model over a database in the console's Context gateway section, add your MCP servers, then make an agent key.