Fast-agent as “Advanced Tool Use” runtime for MCP: static config-based filtration + dynamic discover/learn/execute + MCP-proxy mode to reduce tool context bloat

[iqdoctor]

Summary

• MCP tool schemas can consume tens of thousands of tokens before work starts; tool selection errors also rise with large toolsets.
• Proposal: fast-agent as an “Advanced Tool Use” runtime for MCP with static config-based filtration + dynamic discover/learn/execute + MCP-proxy mode to reduce context bloat.
• Phase 1 is policy controls: static tools filtering in fastagent.config.yaml (AgentCard semantics).

Phased plan

1. Phase 1: static config filtering (fastagent.config.yaml, per-server allowlist + glob patterns; omitted = allow all)
2. Phase 2: discover/learn/execute meta-tools + on-demand schema hydration + caching in proxy mode
3. Phase 3: Tool Use Examples + Programmatic Tool Calling

Visuals

Source: https://www.anthropic.com/engineering/advanced-tool-use (figure: Context Usage: Traditional vs. Tool Search Tool).

flowchart LR
  C["Client / IDE\n(Claude Code, etc.)"] <--> |"MCP: tools/list + tools/call"| FA["fast-agent-mcp-proxy"]

  FA <--> |"MCP upstream"| S1["Google Sheets MCP"]
  FA <--> |"MCP upstream"| S2["Google Calendar MCP"]
  FA <--> |"MCP upstream"| S3["Todoist MCP"]
  FA <--> |"MCP upstream"| S4["...more MCP servers..."]

  subgraph R["fast-agent responsibilities"]
    D["discover_tools / tool_search (compact tool cards)"]
    L["learn_tool (fetch 1 schema on-demand)"]
    E["execute_tool (proxy tools/call)"]
    P["policy: allowlist/denylist + caching + limits"]
  end

  FA -.-> D
  FA -.-> L
  FA -.-> E
  FA -.-> P

Loading

Full writeup

• https://github.com/strato-space/report/blob/main/fast-agent-as-an-advanced-tool-use.md

References

• Feature request: Tool filtering via --include-tools or env var xing5/mcp-google-sheets#58
• https://www.anthropic.com/engineering/advanced-tool-use

[iqdoctor]

See also: fast-agent-as-an-advanced-tool-use.md

[iqdoctor]

TL;DR: fast-agent already knows how to trim tool surfaces. Let’s aim those scissors at the whole MCP zoo.

fast-agent already has an excellent tool filtration mechanism — it works both:

• in Python code (registry/runtime-level filtering), and
• in AgentCard (declarative, config-driven filtering).

That’s “least privilege by default” done right: the model sees only what it needs, not a 17-button toolbar dumped into context.

But today this filtering mostly lives inside the fast-agent ecosystem: it’s great at controlling fast-agent’s own tools/agents, while the wider MCP world can still flood the client with huge JSON schemas via tools/list, burning context at session start.

This issue is the logical next step: export the existing filtration mechanics outward and make them universal for any upstream MCP server:

• intercept upstream tools/list
• apply config-based allowlist/denylist (the same way fast-agent already does)
• return only the minimal tool set to the client
• (and later evolve toward discover → learn → execute, so full schemas are loaded on-demand)

Result: fast-agent gains an additional option — an MCP proxy that tackles context bloat not piecemeal (server by server), but systematically across the entire MCP ecosystem.