How many tools can an LLM agent reliably use at once

The question “how many tools can an LLM agent use at once” has no single numeric answer, but the practical ceiling for reliable production agents is lower than most teams assume. Based on current frontier model behavior, exposing more than 15–20 distinct functions in a single prompt reliably degrades selection accuracy and increases malformed calls.

Context window is not the bottleneck

A model with a 128k context can technically hold the schemas for hundreds of tools. Each JSON Schema description averages 150–300 tokens. Fifty tools cost 7.5k–15k tokens before the agent sees a single user message. That leaves plenty of room numerically, but the model’s ability to attend to the correct schema at the right moment decays well before the window fills.

Tool selection is a retrieval problem inside the model’s attention head. When you pack 50 candidate functions, the probability of the model confusing send_email with send_sms or omitting a required parameter climbs. This is not a theoretical concern; it shows up as silent failures in agent loops.

What degradation actually looks like

Consider a simple agent that books travel. With five tools—search_flights, book_hotel, rent_car, get_weather, email_itinerary—the model rarely messes up. The schemas are distinct, verbs differ, and parameters are clear.

Now expand to 50 tools including search_flights_business, search_flights_economy, book_hotel_Refundable, book_hotel_NonRefundable, rent_car_at_airport, rent_car_downtown, plus 40 CRM and analytics endpoints. Even if each schema is correct, the model starts:

• Calling the wrong variant because the names blur.
• Skipping required params when two schemas share optional ones.
• Hallucinating a tool that sounds plausible but isn’t in the list.

When evaluating how many tools can an LLM agent use, separate the context-window limit from the cognitive limit. The cognitive limit is what kills reliability.

Parameter complexity compounds the problem

Even with few tools, a single tool with 20 optional parameters can confuse the model as much as five extra tools. The model must track which fields apply under which conditions. Keep schemas flat, use enums instead of free text, and avoid overlapping parameter names across tools.

{
  "name": "book_hotel",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {"type": "string"},
      "check_in": {"type": "string", "format": "date"},
      "room_type": {"type": "string", "enum": ["single", "double", "suite"]}
    },
    "required": ["city", "check_in"]
  }
}

A flat schema with explicit enums is far easier for the model to ground than a nested preferences object with conditional sub-fields.

Pattern 1: Static namespacing and grouping

The cheapest fix is to group tools by domain and only expose one group per agent role. Instead of a monolithic agent with 50 tools, run three sub-agents: travel, CRM, analytics. Each gets 10–15 tools max.

# dispatch based on intent classification
def select_toolset(query: str) -> list[str]:
    if "flight" in query or "hotel" in query:
        return TRAVEL_TOOLS
    if "lead" in query or "opportunity" in query:
        return CRM_TOOLS
    return ANALYTICS_TOOLS

This pushes the problem upstream to a router, but the router itself only needs a tiny prompt. The sub-agents stay within the reliable zone.

Pattern 2: Dynamic tool retrieval (RAG for tools)

A more scalable answer to how many tools can an LLM agent use is: don’t show them all. Embed tool descriptions and retrieve the top-k relevant schemas per user turn.

from numpy import dot, norm

def retrieve_tools(query_emb, tool_embs, k=5):
    scores = [dot(query_emb, t) / (norm(query_emb) * norm(t)) for t in tool_embs]
    idx = sorted(range(len(scores)), key=lambda i: scores[i], reverse=True)[:k]
    return [TOOLS[i] for i in idx]

The agent sees only 5 schemas per step. You can index 500 tools in the vector store. The tradeoff: you must trust the retriever. If it misses the right tool, the agent can’t call it. In practice, a lexical + semantic hybrid retriever gets high recall at k=5–8.

Pattern 3: Planner-executor with constrained action space

For complex workflows, separate planning from execution. A planner model outputs a high-level plan referencing tool categories. An executor then gets the specific tools for that category.

{
  "plan": [
    {"step": 1, "action": "travel.search", "detail": "flights to NYC"},
    {"step": 2, "action": "travel.book", "detail": "hotel near midtown"}
  ]
}

The executor receives only travel tools. This keeps the executed context small and makes the plan auditable.

Caching schemas to cut token waste

If you do expose many tools, repeated schema tokens burn money and latency. Mark stable tool definitions with cache-control so the provider caches them across turns. A gateway that honors client routing directives and forwards provider cache-control hints—such as n4n.ai—lets you keep a large tool registry without re-paying input tokens every round-trip. That doesn’t raise the reliability ceiling, but it makes broad exposure cheaper while you architect around the limit.

How to measure your own ceiling

Don’t trust vendor claims. Run a synthetic eval: generate tasks each requiring one tool from your set, increase set size, measure accuracy.

import random

def eval_tool_selection(model_call, tool_set_sizes, n=200):
    results = {}
    for size in tool_set_sizes:
        tools = sample_tools(size)
        correct = 0
        for _ in range(n):
            task = make_task(tools)
            chosen = model_call(task, tools)
            if chosen == task.target:
                correct += 1
        results[size] = correct / n
    return results

Plot accuracy versus size. The knee of the curve is your limit. For most GPT-4-class and Claude-class models, that knee lands between 10 and 20 exposed functions when parameters are reasonably clean.

Naming and description discipline

Use verb_noun convention, avoid synonyms. create_user not add_user and make_account. Descriptions should state the trigger condition explicitly: “Call this when the user provides a physical address and asks to ship a package.” Vague descriptions like “Handles user operations” force the model to guess.

Why fine-tuning isn’t a silver bullet

Fine-tuned tool classifiers (e.g., Gorilla) improve over base models but still degrade with scale. They shift the curve, not the shape. If your base model falls off a cliff at 18 tools, a fine-tune might push that to 30. It does not give you 200 reliable in-context tools.

Tradeoffs engineers should weigh

None of these let you ignore the underlying cognitive limit. They redistribute where the limit applies.

What we ship in production

For customer-facing agents, we cap exposed tools at 12 per prompt. Anything broader goes through a retriever that pulls 6–8 candidates. We log every tool-call mismatch and feed it back into retriever tuning. The result: selection error stays under observable thresholds even with a backend registry of 200+ functions.

When the question is how many tools can an LLM agent use reliably, our answer is: 12–15 in-context, unlimited behind a retriever. Treat the model as a weak selector that needs a narrow menu.

Decisive takeaway

Stop dumping your entire API surface into the system prompt. Measure your own model’s crossover point—typically between 10 and 20 tools—and architect so the agent never sees more than that at once. Use grouping, retrieval, or planning to keep the live action space small. The models will improve, but the economics of attention mean constrained tool sets win for the foreseeable future.