Hundreds of Tools
Zero Context Window Bloat.

Tools are registered in a central ToolboxRegistry with a one-line summary each. The agent planner sees a lightweight catalogue — not full schemas. When the planner decides it needs a specific toolbox, schemas are hydrated from the MCP server in real time. After execution, schemas are evicted. The 99 other tools never occupy a single token.

Not every integration is a flat list of API endpoints. Complex domains — e-commerce with multiple retailers, travel with multiple providers — need their own planning logic, state, and human-in-the-loop flows. Swisper Toolbox supports two execution paths from a single orchestrator:

Instead of exposing hundreds of individual tools, Swisper surfaces entire domain agents as tools. The Global Supervisor delegates to the Travel Agent (which internally knows dozens of booking APIs) rather than choosing between individual flight, hotel, taxi, and parking tools. This dramatically reduces the decision space for the orchestrating agent while preserving full capability.

The same lazy loading pattern works at every level of the hierarchy. A domain agent managing e-commerce across multiple retailers doesn’t load all provider APIs — it discovers which provider to use and lazy-loads that provider’s toolbox. This means an e-commerce agent with 100+ tools across 5 providers pays the same token cost as one with 10 tools.

This is architecturally distinct from what Claude Code or LangGraph offer. Their solutions add lazy loading as a bolt-on at the top level. Swisper’s pattern is recursive: the global planner, domain agents, and sub-agents all share the same hydrate-execute-evict cycle. Scale is built in, not patched on.

Pre-built MCP connectors for enterprise systems. Each connector is a toolbox — loaded on demand, evicted when done.