Binding foreign tools
A tool that is not part of the harness - how does it get in, under what name, and who decides whether the model sees it?
Why this is hard
A harness's built-in tools are finite, the world is not. At some point the agent should operate a calendar, a database, a foreign system the harness author never saw. MCP is the answer that has prevailed for that - but not every harness gives it, and those that do give it differently: as a subprocess, over HTTP, with or without approval per server.
Three layers are involved. The tool definition says what a tool even is inside the harness - every foreign one has to measure up to that. The MCP binding translates and registers it. And tool routing decides whether the model sees every tool on every call or only the ones that currently fit - with thirty foreign servers that is no longer a matter of style but of tokens.
From Pro: the matrix per challenge, all eleven topics with citations, and the architecture portrait of every harness. Freely visible are the six short portraits:
- OpenClaw - The multi-channel personal agent - a half-million-line estate of gateway, channels and tooling whose loop core shares its lineage with Pi.
- Hermes - Nous Research's Python harness - deterministic loop, a skill system, and an error path that escalates in stages instead of just giving up.
- Pi - The coding agent with a deliberately small core - every layer hand-built and kept readable, from the provider package to the session file.
- HybridClaw - The enterprise runtime - sandboxed execution, approvals, and credentials that travel through context as references instead of plain text.
- DeepSeek Harness - The plugin radical - “everything is a plugin” is meant literally here: providers, tools and the loop itself are modules on the Cordis core.
- NanoClaw - The minimalist - small enough to understand in full: the model layer moves behind the Claude Agent SDK, isolation into a container.