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.

Tool families

Family	Source	Examples
Data APIs	Your enabled APIs in /dashboard/apis	linkedin_get_profile, youtube_search_videos
Integrations	API-key integrations in /dashboard/connections	gmail_send_message, hubspot_create_contact
Connectors	First-party OAuth installs on /dashboard/connections	slack_post_message, slack_conversation_history
Utilities	Built-in	credits_balance, webhook_send, escalate_to_human

Connectors vs. Integrations

Both categories represent third-party services, but they differ in how they’re wired up:

• Integrations are generic REST proxies. The workspace pastes an API key on the Integrations page and any tool from that provider becomes callable. They appear in list_available_tools with type: "integration" and a connected: boolean.
• Connectors require a bespoke install flow (typically OAuth). agntdata stores the resulting bot token and dispatches each tool call through a connector-specific code path. They appear with type: "connector", a connected: boolean, and a setup_path pointing at the dashboard page where the user installs them.

When the Builder meta-agent suggests a connector tool that isn’t installed yet, it will tell the user to install it from the linked setup_path first.

Picking tools at the deployed agent level (vs. exposing every tool in your workspace) keeps the agent’s context window focused and reduces the surface area for prompt injection.

Tool argument shape

The MCP gateway generates JSON Schema for each tool from the underlying OpenAPI spec. Path parameters become required string args, query parameters become typed scalars, and request bodies become nested objects. The agent rarely needs to think about HTTP — it just calls the tool by name.

Logging

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

• provider_id — the API/integration slug
• cost_cents — billable cost (zero for utilities and integrations)
• 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).