← Back to feed
WritingArticle

Useful agent tools leave something the next tool can use

Pi’s MCP support emphasizes structured results and tool composition. The opportunity is to connect pieces of real work without making a model reconstruct every intermediate result from prose.

SourceEarendil Engineering: You Said No MCP!earendil.com ↗

Finding the right support case is only useful if the next step can use it. In a hypothetical workflow, one tool finds an unresolved issue and another retrieves the customer’s recent service history. A result containing the issue ID, customer ID, and explicit status gives the second operation a clear input. A paragraph saying that someone seems unhappy leaves more interpretation to the model.

That distinction helps explain Earendil’s decision to bring MCP into Pi’s core after earlier opposition. Its engineering account describes exposing tools to a JavaScript sandbox and argues for structured results and discovery through tool documentation. The team still sees composition problems across existing servers. Supporting a protocol does not, on its own, make a useful sequence of operations easy to build.

Structured results let code select fields, filter a set, and pass identifiers to another call. The model can reason about what should happen while ordinary program logic carries the exact values between steps. That does not remove errors, but it gives a builder a more explicit place to see whether the right record moved through the workflow.

The product opportunity is to make a meaningful piece of work composable. In the support example, the useful outcome might be a case assembled with its relevant history and unresolved questions, ready for a specialist to decide what happens next. Adding another connector matters less than making those outputs fit together without repeatedly reconstructing context.

There is an important limit to that argument. Structured fields and a JavaScript sandbox do not establish durable recovery, correct permissions, or exactly-once execution. A system that retries an external action still needs its own safeguards. Earendil’s post is an implementer’s design account, not an independent reliability evaluation.

The practical distinction for builders is between an output written only to be read and an output designed to support further work. Both can include a useful explanation for the person reviewing it. But when the underlying identifiers and evidence remain available as data, the next step can build on the result instead of starting another interpretation exercise.

Grey Haven
Grey HavenApplied AI Venture Studio