Give Your AI Agents Hundreds of Tools Without Overloading Their Context

A Connic agent can access hundreds of tools without carrying every schema in the model’s context window. Connic keeps discoverable tools in a separate catalog. The agent searches that catalog when it needs a capability, and the matching schemas enter its context then. It can use those tools without loading the full catalog upfront.

Tool definitions can fill context before the work begins

A model needs more than a tool’s name to call it reliably. Its schema describes the purpose, arguments, types, and required fields. As an agent gains access to more APIs and MCP servers, those definitions can become a substantial part of every request, even when the current task uses only one or two tools.

The context window has a finite token budget. Instructions, conversation history, task data, and tool results all need space alongside the tool definitions. Anthropic’s tool-context documentation describes how definitions and accumulated results can exhaust that budget. Loading an entire toolset leaves less room for the information the agent needs to finish its work.

Connic keeps the catalog outside the model’s context

Connic keeps tool descriptions and required inputs in a searchable catalog outside the model’s context. The model has two tools for accessing it: one to search the catalog and another to execute the tools it finds. Frequently used tools can still be available directly, with their schemas supplied from the start.

Consider an agent with 200 task tools, all available for the run. Keeping two directly available and making the other 198 discoverable gives the model access to all 200 with just four tool definitions supplied upfront:

The remaining 198 functions are still callable through discovery. Adding another discoverable function expands the catalog without adding its schema to the definitions the model receives upfront.

A schema enters context when the agent searches for it

A billing assistant handling a payment-status question can call its routine lookup directly. A request for a monthly invoice export can instead lead it to search the catalog for an invoice export tool.

Connic matches the search against tool names and descriptions. It returns matching, available tools with their names, descriptions, and schemas explaining the inputs they accept. Each search returns up to five results by default, with a maximum of 20.

If the model finds a suitable export tool, it can ask the execution tool to run it for August 2026, supplying the inputs described in the search result. Connic runs the selected tool and returns its result.

The model has received the definitions needed for this step. Schemas it has not retrieved remain in the catalog. Found tools continue to run through the same execution tool, so the model does not need a separate calling interface for each one.

Search depends on the words in tool names and descriptions. Descriptions such as “Create a monthly invoice export” give the agent useful search terms. Synonyms or queries in another language may need different wording to find a match. After an empty result, the agent can refine its search or report that the requested capability is unavailable.

Local functions, API operations, and MCP tools share the catalog

The same mechanism works across Python functions, tools generated from OpenAPI specifications, and tools supplied by MCP servers. In an existing LLM agent configuration, tools selects directly available functions and discoverable_tools selects functions for the catalog:

system_prompt: |
  Answer customer billing questions using the available tools.
  Search the tool catalog when a task needs an additional capability.
  Read the returned schemas and use the execution tool to call a match.
  If no suitable tool is available or a call fails, explain the limitation.

tools:
  - billing.get_invoice_status
  - support.find_customer

discoverable_tools:
  - reporting.*
  - exports.create_invoice_export: context.exports_enabled == true
  - api:billing_admin.invoices_*

These are example application functions. The Python functions must exist under tools/; reporting.* selects public functions from tools/reporting.py. The Run Context article provides the invoice lookup example. The api:billing_admin.invoices_* entry requires an imported OpenAPI specification named billing_admin with generated tool names matching that pattern. The agent’s name, version, description, and model belong in the surrounding configuration.

An MCP server joins the catalog with discoverable: true. The example below expects a server with the two named tools and its endpoint and token set as project environment variables. Its tools list restricts which server tools enter the catalog.

mcp_servers:
  - name: finance-tools
    url: "${FINANCE_MCP_URL}"
    headers:
      Authorization: "Bearer ${FINANCE_MCP_TOKEN}"
    tools:
      - invoice_search
      - supplier_lookup
    discoverable: true

Connic connects to the server and loads its tool catalog before model execution. Connic holds those schemas in the catalog until search returns them to the model. The MCP configuration guide covers the connection details. The invoice MCP tutorial covers the other direction: making a Connic agent callable by external clients.

Conditions narrow the available catalog for each run

A tool can remain in the configured catalog while being unavailable for a particular request. In the example, context.exports_enabled == true makes invoice exports available only when the application enables them through Run Context. Conditions can also read JSON input fields through input.*.

Connic evaluates conditions after the agent’s before middleware runs. A false condition excludes the tool from search results and prevents the execution tool from calling it. Later context changes do not recalculate availability during that run. The agent YAML reference documents these conditions and the rules for tool lists, including avoiding overlap between directly available and discoverable functions. Account permissions still need to be enforced by the tool or its backing API.

More context remains for the task

Retrieving schemas on demand leaves more of the context budget for the customer’s question, relevant documents, and the results of earlier steps.

The model’s context window still has a limit. Returned schemas and tool results become conversation history and can accumulate, including across runs in a persistent session. A result-count limit does not impose a token limit. Connic’s optional context compression addresses growing history. Discovery addresses the size of the tool catalog presented upfront. In run traces, the search results, selected tool, and model calls show how that separation works for a real task.