Tools & MCP gateway

How deployed agents discover and call tools through agntdata’s MCP gateway.

Every deployed agent gets a unique MCP server URL:

https://api.agntdata.dev/runtime/agents/{deployed_agent_id}/mcp

Anthropic’s runtime calls tools/list against this URL on every conversation start, then tools/call for each invocation. Authentication is a Bearer token — an agent-scoped API key minted automatically when the agent was deployed.

What the gateway emits is derived from the agent’s config — not the workspace’s. Two agents in the same workspace can expose entirely different tool sets.

Tool families

Family	Source	Example names
Data APIs	Enabled data sources in /dashboard/apis	data_linkedin_get_profile, data_youtube_search_videos
Connections	BYOK + OAuth proxies in /dashboard/connections	connection_stripe_create_customer, connection_notion_create_page
Workspace database	workspace_db.enabled on the agent config	agnt_db_select, agnt_db_insert, agnt_db_apply_migration
Utility	Always available	agnt_credits_balance, agnt_usage_recent, agnt_webhooks_send, escalate_to_human
Workspace files	Always available	agnt_files_list, agnt_files_get, agnt_files_read, agnt_files_upload
Skills (code execution)	code_execution.enabled + attached skills	agnt_skill_manifest, agnt_typescript_run_skill
Agent memory	Opt-in via enable_agent_memory	agnt_memory_remember, agnt_memory_recall, agnt_memory_search, agnt_memory_forget, agnt_memory_recall_entity, agnt_memory_commit
Observability	observability_enabled flag	agnt_observability_list_agents, agnt_observability_read_session, …
Prospector	prospector feature enabled	agnt_prospect_lists, agnt_prospect_leads, agnt_prospect_refresh, agnt_prospect_update_lead
Remote MCP	Native vendor MCP servers (e.g. Linear)	linear_list_issues, linear_save_issue
Config change requests	Always available	agnt_request_config_change (filed back to the Builder for review)

The data, connection, and remote-MCP families are dynamic — they grow as you enable APIs, connect vendors, or add remote MCP servers. The utility, files, skills, and memory families are first-party and stable.

Connections vs. Data APIs

The split between data_* and connection_* tools mirrors who pays the upstream:

• Data APIs (data_<source>_*) — agntdata pays the upstream vendor, you pay in data credits. You don’t need your own LinkedIn / X / etc. account to use them.
• Connections (connection_<vendor>_*) — you connect your own credentials (BYOK or OAuth). agntdata proxies your requests; the vendor bills you directly.

Both shapes are identical at the MCP layer — the agent calls a typed tool, the gateway proxies to the right backend.

Picking tools per-agent

Picking tools at the deployed-agent level (vs. exposing every tool in your workspace) keeps the context window focused and reduces the surface area for prompt injection. The Builder helps with this — its propose_agent_patch proposals usually include adding or removing exactly the tools the agent needs for the new behavior.

A few tools are gated by sub-config:

Config	Effect
workspace_db.enabled: false	Strips every agnt_db_* tool.
workspace_db.read_only: true	Keeps reads (agnt_db_select, agnt_db_execute_sql) but strips writes and DDL.
workspace_db.allow_apply_migration: false	Strips agnt_db_apply_migration specifically (DDL off, CRUD on).
code_execution.enabled: false	Strips agnt_typescript_run_skill, agnt_skill_manifest.
observability_enabled: false	Strips the agnt_observability_* family.

The Builder’s enable_agent_memory tool flips memory on atomically: it installs pgvector inside the workspace DB, creates an agent_memories table, and adds the agnt_memory_* tools to the agent’s tool list in one transaction.

Tool argument shape

The MCP gateway generates JSON Schema for each tool from the underlying OpenAPI spec (for data APIs and connections) or from hand-written Zod schemas (for utility, DB, files, skill, and memory tools). Path parameters become required string args, query parameters become typed scalars, request bodies become nested objects. The agent rarely needs to think about HTTP — it just calls the tool by name.

Tool names are normalized to [a-zA-Z0-9_]+ (Anthropic’s constraint), lower-cased, with collisions disambiguated by prefix:

• data_<slug>_<operationId> for data APIs.
• connection_<vendor>_<operationId> for connections.
• <server_id>_<tool> for remote MCP servers — the server id prefix keeps native vendor names from colliding across servers.

Logging

Every successful and failed tool call writes a row to usage_logs with:

• provider_id — the API or connection slug.
• cost_cents — billable cost (zero for utilities, files, memory, observability).
• metadata.tool_name — the exact MCP tool name the agent called.
• metadata.deployed_agent_id — the agent that made the call.

The agent detail page in the dashboard shows a per-tool breakdown so you can see which tools are actually getting used (and which are just bloating the context).

AI credit usage is logged separately, per-session, in agent_compute_usage — see Usage.

Next steps

Workspace database

The agnt_db_* family in detail.

Permissions

Marking tools always_ask.

Connections

Configure BYOK + OAuth vendor tools.

Credits

What each tool family costs.