An operations agent receives a simple request: update the renewal date for one account. Its catalog contains two CRM connectors, a generic HTTP tool, a database tool, a billing specialist, a customer-success subagent, and three search functions. All of them are described clearly. The agent chooses the old CRM connector because its description contains the closest wording and updates a stale sandbox record.
Nothing was missing. The system failed because it had too many plausible choices and no measured basis for selecting among them.
A NeurIPS 2025 paper, Automated Composition of Agents, treats components as a portfolio selected under capability and cost constraints. Its online method improved single-agent success by as much as 31.6 percent over retrieval baselines. In a synthetically expanded inventory of about 117 subagents with uniform pricing, a smaller selected team raised success from 37 to 87 percent. The experiment used simulated tools, one underlying model for every subagent, and well-defined task descriptions. Its live sandbox trials also took 10 to 30 minutes, depending on budget. Those constraints argue against recomposing every routine request from scratch. Measure components offline, reuse a validated shortlist for recurring task classes, and rerun selection when the task or catalog changes.
MCP makes this decision more important, not less. Standardized connections can expand a catalog quickly. Production reliability depends on what you refuse to put in the agent's context.
MCP Exposes Capability; It Does Not Curate It
The Model Context Protocol gives clients a common way to discover and call tools. A server can publish a tool name, description, and input schema. That is useful plumbing. It does not establish that the server is trusted, the description is accurate, the current user is authorized, or the tool is the best choice for a task.
The current MCP tools specification tells clients to treat tool annotations as untrusted unless they come from trusted servers. It also notes that clients aggregating tools can encounter naming collisions. Those are protocol-level reminders of an application-level responsibility: discovery is not governance.
Separate four decisions that teams often collapse into "tool use":
- Admission: Is this server and tool allowed into the enterprise catalog?
- Assignment: Which tools should this workflow, user, and task class be able to see?
- Selection: Which assigned tool should the agent call now, with which arguments?
- Authorization: Is this exact principal allowed to perform this action on this resource in this context?
MCP helps with discovery and invocation. Your platform owns all four decisions.
This distinction prevents a common architecture mistake: connecting every approved MCP server to one general agent. An approved payroll server may still be irrelevant to a sales-research task. A read-only CRM search tool may be appropriate; an account-deletion tool is not. Trusting the server does not justify exposing all its capability.
Tool descriptions also describe intent, not measured behavior. "Searches the customer system" does not tell you its tenant-filter accuracy, latency, freshness, pagination failures, rate limits, or handling of ambiguous names. A component registry must contain evidence beyond prose.
Build a Component Registry From Measured Behavior
Create one registry for tools, models, retrievers, and specialist agents. Every component gets an owner and an evidence record.
| Registry field | Question it answers |
|---|---|
| Component ID and version | Exactly what was tested? |
| Supported task classes | Which work is it allowed to serve? |
| Measured success rate | How often did it complete representative cases? |
| Argument accuracy | Did it choose valid records, amounts, dates, and destinations? |
| Cost and latency | What does one successful outcome consume? |
| Required scopes | What data and actions can its credential reach? |
| Side-effect class | Read, reversible write, consequential write, or destructive action? |
| Dependencies | Which models, services, and other tools must be present? |
| Known failure modes | When should routing avoid it or escalate? |
| Last validation date | Is the evidence still current? |
| Owner and retirement date | Who fixes it, and when is it reviewed? |
Benchmark components on real workflow cases. The Berkeley Function Calling Leaderboard evaluates function selection, multi-turn use, relevance detection, and other tool-calling behavior at scale. Use that work as inspiration for structure, then build a smaller company-specific suite. A model's public function-calling rank does not tell you whether it chooses the correct internal customer record.
Include cases where no tool should be called. Relevance detection matters because agents often force a task into the closest available capability. "No applicable tool" should be a valid, scored outcome followed by clarification, routing, or refusal.
Test overlapping tools head to head. If two connectors both search accounts, run the same cases through each and compare result correctness, freshness, permissions, latency, cost, and operational support. Keep a backup only when it provides a real resilience benefit. Otherwise, overlap becomes ambiguity.
For subagents, score the whole handoff: whether the orchestrator delegated correctly, whether the specialist received enough context, whether it stayed within scope, and whether its result was usable. A specialist with a high standalone score can still damage the system if routing sends it the wrong work.
The registry should feed runtime selection and procurement. If a tool has no owner, no recent tests, or broader permissions than its business value justifies, it should not remain available because somebody may need it later.
Select a Bounded Set Before the Agent Starts
Do not ask one model to reason over the entire enterprise catalog on every turn. Classify the request first, then expose a bounded component set.
A practical two-stage router works like this:
Stage 1: task routing. Map the request to a workflow and risk class using the user, channel, business object, intent, and current state. "Find the latest Acme renewal" routes to account research. "Change the Acme renewal date" routes to a controlled CRM update workflow.
Stage 2: component selection. Query the registry for components validated for that task, compatible with the user's permissions, within the risk and cost budget, and current enough to use. The agent receives only that shortlist.
Use three independent budgets:
| Budget | Limits | Example |
|---|---|---|
| Capability budget | Number and breadth of tools | CRM lookup, contract search, renewal update only |
| Risk budget | Maximum side-effect severity and permission scope | One reversible CRM write; no billing or deletion |
| Resource budget | Calls, tokens, time, and money | 8 calls, 60 seconds, $0.20 estimated cost |
A high-capability component is not automatically selectable. It must fit all three budgets. A general SQL tool may answer the request, but it fails the risk budget when a scoped account lookup exists.
Selection should consider compatibility. A specialist agent built around one CRM schema may not understand records returned by another connector. A tool that returns an asynchronous job ID requires a polling or callback capability. A retriever that emits citations may be necessary for a compliance agent but unnecessary for a simple status check.
Record why each component was selected or excluded. This turns a confusing failure into a debuggable one. If the correct tool never reached the shortlist, fix task routing or registry metadata. If it reached the shortlist and the model chose another, fix descriptions, examples, or the selection policy. If the right call failed, fix the tool.
Design Tools for Clear Choice and Safe Failure
Routing cannot compensate for poor tool contracts. Tools need names, schemas, and outputs that make the choice obvious.
Prefer a narrow verb and business object: get_account_by_domain, propose_renewal_date_change, send_approved_quote. Avoid generic names such as execute, manage_record, or call_api. Two tools should not claim the same action unless the routing layer has an explicit rule for choosing between them.
Descriptions should state:
- What the tool does and does not do
- Required preconditions
- Authoritative system and freshness
- Side effects
- Permission and approval requirements
- Expected errors and recovery behavior
- When another tool is the correct choice
Input schemas should use enums, typed identifiers, numeric bounds, and required fields. Do not hide five decisions in one free-text argument. Output schemas should distinguish not found, unauthorized, invalid request, conflict, temporary failure, and completed action. The agent needs different recovery behavior for each.
Split read from write. Split propose from commit for consequential operations. A renewal workflow might expose get_renewal, propose_renewal_change, and commit_approved_renewal_change as separate capabilities with separate credentials. The model cannot bypass the approval because the proposal tool lacks the authority to commit.
Use user-scoped credentials and enforce authorization downstream. OWASP's excessive agency guidance recommends minimizing extensions, functionality, and permissions, avoiding open-ended tools, and requiring approval for high-impact actions. Tool selection and least privilege support each other: a smaller catalog reduces both confusion and blast radius. The guardrails playbook explains how to keep those controls outside the model's discretion.
MCP's security best practices forbid token passthrough in the authorization specification because it can bypass audience and other security controls. Do not turn an interoperability layer into a credential tunnel. Each server and downstream API must validate the token intended for it.
Know When to Use a Tool, Workflow, or Subagent
Teams often turn every new capability into a subagent because specialization sounds cleaner. That can add extra model calls, context handoffs, failure modes, and unclear ownership. Use the simplest component that fits the work.
Use a deterministic tool for one bounded operation with a clear schema and result: fetch an invoice, calculate tax, update a status, or create a draft record.
Use a workflow when the sequence and decisions are known: verify identity, retrieve order, check policy, propose refund, request approval, commit, notify. Some steps may use models, but orchestration owns the state transitions.
Use a specialist subagent when the task needs its own instructions, context window, multi-step reasoning, tool set, evaluation, and ownership boundary. Contract review or data-pipeline diagnosis may justify one. Formatting a date does not.
| Question | Tool | Workflow | Subagent |
|---|---|---|---|
| Is the operation deterministic and bounded? | Strong fit | Possible step | Poor fit |
| Does it require persisted multi-step state? | No | Strong fit | Sometimes |
| Does it need an independent context and skill set? | No | Sometimes | Strong fit |
| Can success be checked from one result? | Usually | From final state | From task outcome |
| Is separate ownership useful? | Connector owner | Process owner | Domain owner |
An orchestrator should delegate a goal and scoped context, not dump its entire conversation. The subagent should return a typed result with evidence, status, and unresolved questions. Do not let delegated agents silently inherit every credential from the parent.
The knapsack framing is helpful here. Components have value, cost, and compatibility. The objective is not to assemble the biggest team. It is to choose the smallest portfolio likely to complete the task within constraints.
Operate the Catalog Like a Product Portfolio
Tool catalogs accumulate debris. A pilot connector remains after the vendor changes. A temporary subagent has no owner. Two versions coexist because nobody knows whether the old one is still called. Every unused component adds context, security review, dependency updates, monitoring, and incident surface.
Review the catalog on a fixed cadence. For each component, examine:
- Selection volume and successful completion rate
- Wrong-selection and no-tool rates
- Cost and latency per completed task
- Permission scope and security findings
- Incidents, retries, and fallback use
- Owner responsiveness and dependency health
- Overlap with other components
- Last validated model, schema, and policy version
Retire tools with no justified traffic, no owner, stale evidence, or strictly worse performance than an alternative. Remove their credentials and server configuration, not just their prompt description. Add a deprecation period for active workflows and test that routing no longer selects them.
Roll out catalog changes like software changes. Compare the candidate tool set against the current set on held-out cases. Shadow new routing decisions, then expand by workflow. Keep a known-good catalog version and a capability-level stop switch.
Track business outcome, not tool activity. A dashboard showing 10,000 successful calls can hide an agent that used three searches and two retries for a task one lookup should complete. The unit economics should be cost and latency per completed workflow, with safety failures reported separately.
For a broader architecture view, our guide to domain-specific agents explains why MCP connects capability but does not replace routing, state, approvals, audit logs, and handoffs.
How OpenNash Can Help
OpenNash helps enterprise teams rationalize an agent's component portfolio before adding more integrations. We inventory tools, MCP servers, models, retrievers, and subagents; map each to task classes and permissions; and benchmark overlapping options against real cases. The output is a measured registry, routing policy, budget model, and retirement list.
We can then implement the bounded selection layer, narrow tool contracts, identity propagation, approvals, traces, and release evals. Built-in routing and MCP support are often enough for a stable workflow on one platform. A custom registry becomes useful when work crosses vendors, tenants, and risk classes. Without stable workflow boundaries, delay multi-agent architecture and start with one controlled workflow.
The goal is not an impressive tool count. It is a smaller system whose choices can be explained, tested, and owned.
Book a call to benchmark one agent catalog. Bring the current tool list, ten real requests, and the connector nobody is quite sure is still in use.