{"slug": "how-to-expose-tools-to-ai-agents-without-clogging-their-context", "title": "How to expose tools to AI agents without clogging their context", "summary": "Nango tested tool-exposure patterns for AI agents and found that exposing a small pinned working set with on-demand discovery cut median cumulative input tokens per task by 69% versus loading all 57 tool definitions upfront. In the synthetic benchmark of six tasks run twice per configuration, discovery alone reduced input tokens by 44%, while pinning two frequently used tools avoided extra searches and used less input across complete tasks. The company recommends enforcing permissions at execution time and measuring whole-task token use when deciding which tools to pin.", "body_md": "To give AI agents access to hundreds of tools without filling their context window, expose a small working set and let them discover additional tools on demand. Enforce permissions when tools execute, and keep responses compact: tool definitions and returned data both consume context.\n\nA sales assistant connected to Gmail, Google Calendar, and Salesforce may have hundreds of operations available. Preparing for a meeting needs only a handful. Nango [Agent Sessions](https://nango.dev/docs/guides/agent-sessions) let developers scope permitted tools, pin frequently used tools, and keep the rest searchable. We tested these exposure patterns with 57 tools and a fixed dataset.\n\nTool exposure creates three separate costs:\n\n`search_messages`, `list_threads`, and `get_thread` require the agent to distinguish similar choices. Mailbox administration adds choices that meeting preparation does not need.\nAnthropic’s [advanced tool use article](https://www.anthropic.com/engineering/advanced-tool-use) (November 2025) describes five MCP servers exposing 58 tools whose definitions consumed approximately 55,000 tokens. Schema complexity matters as well as tool count.\n\nDiscovery with two pinned tools used **69% fewer input tokens per task** than loading all 57 tool definitions upfront in our synthetic test.\n\nWe ran six tasks twice per configuration. The tasks used three tools returning fixed fictional meeting, account, and email records; the other 54 tool definitions served as distractors. Discovery exposed two meta tools. The pinned configuration also loaded the meeting and account tools upfront.\n\n*Claude Sonnet 4.6, six synthetic tasks run twice per configuration. All used Agent Sessions with client-supplied typed schemas and passed the task checks. Input is summed across model calls, not peak context size.*\n\n| Tool exposure | Median cumulative input tokens per task | Reduction vs full loading | \n|---|---|---|\n| Baseline: load all 57 definitions | 19,394.5 | Reference | \n| Discovery only | 10,861 | 44% | \n| Discovery with two pinned tools | 6,070.5 | 69% | \n\nPinning common tools avoided searches for those tools. Discovery alone started with fewer tokens, but the pinned configuration used less input across complete tasks. **Measure the whole task when choosing what to pin.**\n\nUser authorization, session permissions, and tool visibility control different things. Decide what the agent may execute before choosing what the model sees.\n\n| Layer | What it controls | Meeting-preparation example | \n|---|---|---|\n| User authorization | Access granted through the connected account and OAuth permissions | Salesforce access under the user's existing rights | \n| Session permissions | Connections and operations the application permits | CRM reads allowed; writes excluded | \n| Tool visibility | Definitions presented to the model | Common tools loaded; others discoverable | \n\nWith Nango Agent Sessions, your backend selects connections using tags or specific IDs and defines a `toolset` with `allow` and `deny` rules. Nango executes calls using those connections without exposing provider credentials to the model. The agent cannot broaden its own scope. Configure restrictions explicitly: omitting `toolset` includes every tool on integrations the tenant has a resolved connection for.\n\nThe execution layer must enforce permissions on every call, including guessed tool names or instructions found in retrieved content. See [how developers secure AI agent access to APIs](https://nango.dev/blog/how-developers-secure-ai-agent-access-to-apis).\n\nUse task-specific tools for predictable work, select tool groups from application state, and add discovery for capabilities outside the initial selection.\n\nA tool for every API endpoint forces the agent to assemble low-level calls into a workflow. Preparing a briefing might require finding an account, resolving record IDs, fetching opportunities, and filtering activities.\n\nA custom `get_account_briefing` tool could accept an account identifier and return its owner, open opportunities, and recent activities in one call. Supply identifiers from application state where possible, or provide a lookup that resolves ambiguous names.\n\nExplain what each tool returns, when to use it, and its limitations. Purpose-built tools reduce repeated decisions but require maintenance and may not cover unusual requests. Anthropic’s [tool-design guidance](https://www.anthropic.com/engineering/writing-tools-for-agents) describes similar task-oriented designs.\n\nCoding agents such as Claude Code, Cursor, and Codex can use the [Nango builder skill](https://nango.dev/docs/guides/functions/functions-guide) to build or customize tools for API integrations. Nango runs those functions using the user’s connected account; see [how to build reliable tool calls for AI agents](https://nango.dev/blog/build-reliable-tool-calls-for-ai-agents-integrating-with-external-apis) for the broader design pattern.\n\nYour application can often select tools before calling the model. A “Prepare for meeting” button can expose calendar, email search, and CRM read tools. “Log call notes” can expose CRM write tools if the session permits writes.\n\nUse routing rules for predictable workflows or a classifier for open-ended requests. The tradeoff is omission: if the user adds “also check Acme’s support tickets” and routing selected no ticketing tools, the agent needs a recovery path. Discovery provides one within its permitted scope.\n\nProgressive disclosure loads definitions as the task needs them. The agent searches a catalog of permitted tools, receives matching definitions, and executes a selected tool. Tool discovery searches capabilities: finding an email-search tool returns its definition; executing it returns emails.\n\nNango Agent Sessions expose two default [meta tools](https://nango.dev/docs/guides/agent-sessions#meta-tools):\n\n`**nango_tool_search**``** nango_execute**`\nOther permitted tools stay searchable without appearing individually in `tools/list`. Use `pinned_tools` to list the small core needed on most requests, avoiding discovery for common operations. Choose the core from observed usage; no fixed number suits every workflow.\n\nOur pinned core contained the meeting and account fixture actions. One recorded Acme briefing used four calls:\n\n| Call | Observed result | \n|---|---|\n| Pinned meeting action, company Acme | Meeting mtg_acme_001, starting 2026-10-16T14:00:00Z | \n| Pinned account action, company Acme | Owner Mira Stone; opportunity opp_acme_001 in Proposal | \n| nango_tool_search, query \"latest customer email note benchmark fixture\" | Email-summary fixture action with its input schema | \n| nango_execute, email-summary action with company Acme | Thread thread_acme_001; \"Legal review pending\" | \n\nSearch adds a step, and names, descriptions, and ranking settings affect retrieval. Allow query refinement when the expected tool appears only as a related lead. Discovery cannot grant access outside the toolset.\n\nThe optional `nango_proxy` meta tool makes authenticated endpoint requests for connected integrations in the toolset. It bypasses tool-level `allow` and `deny` restrictions and is disabled by default. Keep it disabled when those restrictions must constrain the agent.\n\nThe pilot revealed a difference between listing and discovery. In the tested dev build, pinned action tools appeared in `tools/list` with a permissive object schema and no declared properties. Searching for the same fixture action returned its deployed schema, including the required `company` argument.\n\nIn one full-catalog pilot briefing, the model sent `{\"account\":\"Acme\"}` to actions requiring `company`, and the calls failed. A typed function declaration alone did not establish what the model received.\n\nWe excluded the pilot from the comparison and supplied input schemas from management MCP metadata client-side for listed integration tools. The controlled results therefore compare exposure strategies with typed input contracts supplied on both paths. Inspect actual `tools/list` and search responses in your client, and validate arguments before executing function logic.\n\nMCP does not guarantee selective loading. Its `tools/list` interface supports [pagination](https://modelcontextprotocol.io/specification/2025-11-25/server/utilities/pagination), which divides a tool list across responses. A client can still fetch every page and load every definition. The server or client must control which definitions reach the model.\n\nReturn what the next decision requires, with identifiers that let the agent retrieve more detail. A small catalog can still exhaust context through large results.\n\nKeep source links for verification and IDs for follow-up calls. Make truncation explicit: “10 of 42 opportunities returned” tells the agent whether further retrieval may be necessary.\n\nNango’s [action functions](https://nango.dev/docs/guides/functions/action-functions) let developers define schemas and choose which provider fields reach the agent. Implement response reduction in function code while preserving a way to retrieve omitted information.\n\nFor repeated calls or large intermediate datasets, run loops, filtering, and aggregation in a backend function or [code-execution environment](https://www.anthropic.com/engineering/code-execution-with-mcp). Return relevant records and totals together. Predefined functions suit stable workflows; agent-written code requires a sandbox, resource limits, and monitoring. Retain enough evidence for the model to explain its answer.\n\n| Situation | Approach | \n|---|---|\n| Small, predictable workflow | Curated tools exposed directly | \n| Distinct product workflows | Tool groups selected from task and application state | \n| Large, varied tool catalog | On-demand discovery with a small pinned core | \n| Large responses or repetitive processing | Compact outputs and execution outside the conversation | \n\nEvaluate completion quality, wrong-tool calls, discovery misses, input tokens, and latency together. Include follow-up requests and less common capabilities, and compare identical tasks before and after changing exposure. Inspect the schemas as well as the number of visible tools.\n\nTo implement this with Nango, [create an Agent Session](https://nango.dev/docs/guides/agent-sessions) with explicit connection and tool permissions. Keep the permitted catalog searchable, pin common tools, and shape outputs around the agent’s next decision.\n\n*Related reading:*", "url": "https://wpnews.pro/news/how-to-expose-tools-to-ai-agents-without-clogging-their-context", "canonical_source": "https://dev.to/nangohq/how-to-expose-tools-to-ai-agents-without-clogging-their-context-186i", "published_at": "2026-10-15 18:52:16+00:00", "updated_at": "2026-10-15 18:56:41.783053+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "agent-protocols", "developer-tools", "mlops"], "entities": ["Nango", "Anthropic", "Claude Sonnet 4.6", "Gmail", "Google Calendar", "Salesforce", "MCP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-to-expose-tools-to-ai-agents-without-clogging-their-context", "markdown": "https://wpnews.pro/news/how-to-expose-tools-to-ai-agents-without-clogging-their-context.md", "text": "https://wpnews.pro/news/how-to-expose-tools-to-ai-agents-without-clogging-their-context.txt", "jsonld": "https://wpnews.pro/news/how-to-expose-tools-to-ai-agents-without-clogging-their-context.jsonld"}}