One MCP server for every AI IDE

OriginChainDB · May 4, 2026

mcp ai-tools claude cursor

The OriginChainDB MCP server exposes five tools - oc_ask, oc_sql, oc_vector_topk, oc_fts_search and oc_list_schemas - so an agent inside an AI IDE queries your tenant directly. It runs over stdio as a child process of the IDE, reads three environment variables, and keeps no state of its own.

If you watched the AI tooling stack settle in 2025–2026, the tooling layer that won is MCP - the Model Context Protocol. It is a thin JSON-RPC contract that lets a client (Claude Desktop, Cursor, Zed, Windsurf, Continue, OpenAI’s Apps SDK) plug into a server (a database, a filesystem, a ticket tracker) over stdio or HTTP. The agent inside the IDE sees the server’s tools - typed, named functions with JSON-Schema arguments - and calls them when the user’s prompt suggests it should.

This is not a niche developer-experience improvement. It is the new front door. When an engineer opens Claude Desktop and asks “what’s the schema of the products table?”, the answer comes from whichever database server is registered in claude_desktop_config.json - and the database that isn’t there at all does not get queried, recommended, or even mentioned. Database vendors without an MCP server are, increasingly, vendors who don’t exist inside the agent’s tool list.

We shipped @originchain/mcp-server for exactly this reason.

The five tools

An MCP server’s surface is its tool list. Tools are named functions; the agent reads the name + description + JSON-Schema and decides when to call. Bigger surfaces are not better - every tool the agent considers is an opportunity to call the wrong one. We exposed five, mapping 1:1 to the OriginChainDB query shapes:

oc_ask Natural-language question → rows back
oc_sql Typed SQL with bind params
oc_vector_topk HNSW similarity search with metadata filter
oc_fts_search BM25 full-text search
oc_list_schemas Introspect the tenant's tables, columns, indexes

oc_list_schemas matters more than it looks. Without it, the agent has to guess column names and table layouts; with it, the very first call from a fresh session produces a schema the agent can reason from. We see this in traces - Claude consistently calls oc_list_schemas first when the user’s question references a table the agent hasn’t seen, then writes a oc_sql query that’s right on the first try.

Each tool’s input schema is small and typed. oc_sql takes sql (string) and params (array). oc_vector_topk takes table, vector, k, optional mode (fast or high_recall), and optional filter. The schemas are derived from the same OpenAPI spec the SDK is built from, so the agent sees the same shapes a TypeScript client would.

The stdio transport pattern

MCP supports two transports - stdio and HTTP. For local IDE integrations, stdio is the right answer. The IDE spawns the server as a child process; JSON-RPC messages travel over stdin/stdout; lifecycle is bound to the IDE’s lifecycle. No port to allocate, no localhost server to forget about, no auth surface beyond what the IDE itself enforces.

The server’s main loop is small:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server(
 { name: "originchain", version: "0.1.0" },
 { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async  => ({
 tools: [OC_ASK, OC_SQL, OC_VECTOR_TOPK, OC_FTS_SEARCH, OC_LIST_SCHEMAS],
}));

server.setRequestHandler(CallToolRequestSchema, async (req) => {
 switch (req.params.name) {
 case "oc_sql": return runSql(req.params.arguments);
 case "oc_ask": return runAsk(req.params.arguments);
 //...
 }
});

await server.connect(new StdioServerTransport);

Every handler hits the tenant’s HTTPS endpoint with the bearer token from the env. There is no local cache, no connection pool, no state - the MCP server is a thin shim, and that’s the point. When the engine ships a new query shape, the spec updates and the shim rebuilds; there is nothing in the shim to break.

Env-var config

The server reads three environment variables:

ORIGINCHAIN_URL https://acme.originchain.ai
ORIGINCHAIN_TOKEN bearer_xxxxxxxxxxxxxxxxxxxxxxxx
ORIGINCHAIN_TENANT acme # optional; inferred from URL when absent

No config files. No interactive setup. The IDE’s config block holds the env, the server reads it on launch, and there is exactly one place to rotate the token when it expires. This matters for security review - tokens never land on disk in a config file the user might commit.

A working Claude Desktop config

Drop this into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the platform equivalent on Windows / Linux:

{
 "mcpServers": {
 "originchain": {
 "command": "npx",
 "args": ["-y", "@originchain/mcp-server"],
 "env": {
 "ORIGINCHAIN_URL": "https://acme.originchain.ai",
 "ORIGINCHAIN_TOKEN": "bearer_xxxxxxxxxxxxxxxxxxxxxxxx"
 }
 }
 }
}

Restart Claude Desktop. Open a fresh chat. Ask “what tables do I have?” and the agent calls oc_list_schemas. Ask “top 10 suppliers in Mumbai by shipment volume last quarter” and it calls oc_ask, which routes through the natural-language planner on the tenant. Ask “find products similar to this paragraph and group by category” and it calls oc_vector_topk followed by oc_sql to aggregate. The whole loop closes inside the IDE.

Cursor’s setup is identical - ~/.cursor/mcp.json, same shape, same env. We tested against both clients on the same tenant.

What MCP doesn’t yet solve

Three things the protocol is honest about not solving, and that matter for production database integrations:

Agent observability. When the agent calls oc_sql ten times in a session, who sees those calls? The IDE logs them locally; the database logs them under the bearer’s tenant; there is no per-agent identity. If your auditor asks “which agent ran which query?” the answer today is “the bearer”, not “the agent.” Per-agent identity over MCP is being discussed; it is not in the wire format yet.
Granular permissions. oc_sql either runs or doesn’t. There is no row-level scope inside the tool call, no “read-only on these tables” gate, no rate limit per tool per session. The bearer’s tenant-scope is the only fence. We mitigate this by recommending a separate read-only bearer for IDE use, but the protocol itself doesn’t have a permission story.
Billing-per-call. The free database caps /ask at 50 calls per day. MCP has no notion of cost. An agent that loops oc_ask 200 times in a runaway session burns that quota with no IDE-side warning. Quota is enforced server-side via 429 responses; the agent will see them and back off, but the cost-control story is one-way (the server tells the client to stop) rather than budgeted (the client knows in advance).

None of these are blockers for shipping. They are the shape of the next protocol revision, and the kind of work the database vendor gets to do when the protocol catches up.

Status

The MCP server is built and tested against Claude Desktop and Cursor on macOS. It is not yet on npm publicly - the GitHub repo at github.com/originchain-ai/originchain-mcp is being pushed in the next release window. Until then, paid tenants who want early access can email support and we’ll wire them up directly.

Provision a tenant in under two minutes via the quickstart. The MCP repo lands at github.com/originchain-ai/originchain-mcp soon - bookmark it.

One bearer. One server. Every IDE.

← All posts Subscribe to RSS →