Apideck
Apideck · Agents
Schedule a demo
AI agents & MCP

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.

https://mcp.apideck.dev/mcp
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

four tools · every unified API behind them

Four meta-tools

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_tools

Browse available tools by API

describe_tool

Get a tool's input schema

execute_tool

Run a tool with typed arguments

list_scopes

Check available permission scopes

Why it matters
A tool catalog is context you pay for on every single turn. Keeping discovery behind three calls means the cost of Apideck having 200+ connectors is paid by the server, not by the agent's window — so the same agent stays practical whether you use one connector or all of them.
Interactive

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.

step 1 / 4
Find the right tool

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.

agent sends
{
"tool": "list_tools",
"arguments": {
"domain": "accounting"
}
}
server returns
{
"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"
}
Connect your agent

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
{
"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's
x-apideck-app-idwhich of your apps is asking
x-apideck-consumer-idwhich customer's ledger the agent may touch
Placeholders
The block ships with placeholder credentials on purpose — nothing here is a real secret. Swap them for your own from the dashboard.
What it can reach

An 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.

Vault still holds the keys

The agent never sees a credential. It sends a consumer id; Apideck resolves the connection, exactly as it does for your backend.

Every call is logged

Agent traffic lands in the same parent/child request log as everything else, so an autonomous write is as auditable as a manual one.

Same models, same shapes

The agent gets the unified model back, so a prompt written against QuickBooks works on NetSuite without a rewrite.

Across every connector

One prompt. Whichever ledger the customer runs.

quickbooks logoQuickBooksnetsuite logoNetSuitexero logoXerosage-intacct logoSage Intacctexact-online logoExact Onlinefreshbooks logoFreshBooks+42 more
accounting-invoices-allaccounting-bills-addaccounting-payments-addaccounting-journal-entries-addaccounting-ledger-accounts-allaccounting-balance-sheet-one

Tool names are the unified operations you already know — resource, then verb.