Hand the ledger to an agent
Everything the other tours describe — the unified models, Vault's managed credentials, one call per connector — is also exposed as an MCP server. Point Claude, Cursor or your own agent at it and it reads and writes your customers' ledgers without a line of glue code.
list_toolsBrowse available tools by APIdescribe_toolGet a tool's input schemaexecute_toolRun a tool with typed argumentslist_scopesCheck available permission scopesfour tools · every unified API behind them
Four tools, not four hundred. That's the whole trick.
Every operation across every unified API is available as an MCP tool. Advertising all of them up front would fill an agent's context window before it had done anything — so in dynamic mode the server advertises four, and the agent discovers the rest on demand.
list_toolsBrowse available tools by API
describe_toolGet a tool's input schema
execute_toolRun a tool with typed arguments
list_scopesCheck available permission scopes
Find it, read it, run it. In that order.
What an agent actually sends, and what comes back. Pick a meta-tool to see both halves.
The agent doesn't hold a catalog of hundreds of tools in context. It asks for the ones in the API it needs, when it needs them.
{ "tool": "list_tools", "arguments": { "domain": "accounting" }}{ "tools": [ "accounting-invoices-all", "accounting-invoices-add", "accounting-bills-all", "accounting-bills-add", "accounting-payments-add", "accounting-journal-entries-add", "accounting-ledger-accounts-all", "accounting-balance-sheet-one" ], "note": "…and the rest of the Accounting API"}One config block, and you're done.
Drop this into Claude Desktop, Cursor or any MCP client. The headers are the same three that route every REST call — your app, your customer, your key — so an agent is scoped exactly the way your backend is.
{ "mcpServers": { "apideck": { "url": "https://mcp.apideck.dev/mcp", "headers": { "x-apideck-api-key": "YOUR_API_KEY", "x-apideck-app-id": "YOUR_APP_ID", "x-apideck-consumer-id": "YOUR_CONSUMER_ID" } } }}x-apideck-api-keyyour key — never a customer'sx-apideck-app-idwhich of your apps is askingx-apideck-consumer-idwhich customer's ledger the agent may touchAn agent inherits the consumer's consent. Nothing more.
The consumer id in the config is the boundary. An agent can only touch what that customer authorized through Vault — the same scopes, the same connection, the same request logs on every call it makes.
The agent never sees a credential. It sends a consumer id; Apideck resolves the connection, exactly as it does for your backend.
Agent traffic lands in the same parent/child request log as everything else, so an autonomous write is as auditable as a manual one.
The agent gets the unified model back, so a prompt written against QuickBooks works on NetSuite without a rewrite.
One prompt. Whichever ledger the customer runs.
accounting-invoices-allaccounting-bills-addaccounting-payments-addaccounting-journal-entries-addaccounting-ledger-accounts-allaccounting-balance-sheet-oneTool names are the unified operations you already know — resource, then verb.