> ## Documentation Index > Fetch the complete documentation index at: https://agnt.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 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__*`) — 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__*`) — 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__` for data APIs. * `connection__` for connections. * `_` 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](/billing/usage). ## Next steps The `agnt_db_*` family in detail. Marking tools `always_ask`. Configure BYOK + OAuth vendor tools. What each tool family costs.