Division of labor
| Component | Role | Official basis |
|---|---|---|
| MCP server | Reliable tools + resources + prompts | Server concepts |
| MCP client | Connection + protocol session | Architecture |
| MCP host / agent framework | Planning, UI, multi-step loops, which tools enter context | Client best practices |
| Model | Chooses tools given definitions/results | Host-dependent |
MCP does not dictate how apps use LLMs (architecture note) — only how context is exchanged.
Why MCP helps frameworks
- Swap hosts without rewriting integrations
- Share tools across IDE agents and backend agents
- Centralize secrets and audit at the server
- Scale tool sprawl with progressive discovery patterns published for hosts
Progressive discovery (official host pattern)
When many servers expose hundreds of tools, loading every definition into the model wastes tokens and hurts quality. Official client best practices describe:
- Fetch
tools/listbut defer injecting all definitions - Expose a lightweight search_tools meta-tool
- Load full schemas only for candidates
- Optionally connect/disconnect whole servers dynamically
Guidelines include caching definitions, refreshing on notifications/tools/list_changed, and grouping tools by server.
Implication for server authors: write excellent names/descriptions; keep tools cohesive per server so search works.
Programmatic tool calling / code mode
The same client-best-practices page describes composing multi-tool workflows in a sandbox so intermediate payloads don’t flood the model. Security notes:
- Per-call authorization still applies (human-in-the-loop policy)
- Sandbox has no direct network; host brokers
tools/call - Credentials stay in the host, not model-generated code
- Respect
isError: truetool results (tools error handling)
Design servers for agents
| Practice | Why |
|---|---|
| Idempotent tools when possible | Agent retries |
Actionable isError messages | Model self-correction (tools) |
Optional outputSchema | Better typed composition in code mode |
| Avoid 100-tool dumps on one server | Discovery quality |
| Resources for large context | Don’t force multi‑MB tool returns |
Hosting implication
Frameworks assume tools are reachable. Remote Streamable HTTP + auth (transports, connect remote) is what makes shared agent platforms real.
Worked scenario: Hundreds of tools, one confused model
You connect twelve MCP servers to an agent host. Every turn injects the full tools/list for all of them. Quality drops; latency rises; cost spikes—before any tool even runs.
You implement progressive discovery patterns from official client best practices: search tools meta-API, load full schemas only for candidates, connect servers on demand. For multi-step ETL-like tool chains, you experiment with programmatic tool calling so intermediate payloads skip the model context.
Server authors help by writing clear names/descriptions and keeping servers domain-scoped.
Checklist for this topic
- Avoid dumping all tool definitions into every turn at scale
- Group tools by server with clear naming
- Provide solid tool descriptions for search/discovery
- Consider outputSchema for structured composition
- Keep credentials in the host/broker, not model-written code
- Apply human-in-the-loop to sandbox-originated calls too
Topic-specific failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Context window blown | Naive tool loading | Progressive discovery |
| Wrong tool selected | Ambiguous descriptions | Better names + smaller catalogs |
| Sandbox exfil risk | Networked code mode | Brokered calls only; no sandbox net |
| Framework lock-in | Native tools only | Expose via MCP for multi-host use |
Related guides
Coding agents · Tools primitives · Client vs host
In practice: host-side knobs
Even with perfect servers, hosts must:
- Cap how many servers connect at once for a task
- Prefer search-then-load for large catalogs
- Show users which tools will run (human-in-the-loop)
- Keep credentials in the broker when using code-mode sandboxes
Document those host settings next to your server catalog so app engineers do not “fix” quality by attaching every server globally.
Server author checklist for framework-friendly tools
- Stable names; no silent renames
- Descriptions that state preconditions and side effects
- Small result payloads; paginate large lists
- Optional
outputSchemawhen returning structured data - Clear
isErrormessages - Domain-scoped servers (repo tools separate from CRM tools)
Frameworks and hosts can only orchestrate well if the tool surface is boring and predictable.
Takeaways
For MCP and Agent Frameworks: How Agents Consume Tools, remember three things:
- Be specific to this problem — the worked scenario “Hundreds of tools, one confused model” is the failure mode you should design against, not a generic outage narrative.
- Progressive tool discovery and tight schemas beat dumping hundreds of tools into one context window.
- Framework orchestration cannot fix vague tool descriptions or unbounded result payloads.
If you only remember one habit: design tools for the model that will choose them, not only for the engineer who wrote them. Framework teams should treat MCP servers as versioned dependencies: pin URLs or package versions, review tool diffs on upgrade, and refuse silent renames from server owners.
Sources
- Client best practices
- Architecture overview
- Server concepts
- Tools — 2025-11-25
- Transports — 2025-11-25
