An AI agent that shows its work.
Connect an agent to real tools over the Model Context Protocol — a read-only SQL database, a live weather API, a calculator. Ask a question, watch it plan, call each tool, recover from a failure, and produce the answer.
- Free to try
- No credit card
- Real tools, real results
plan
Decide which tools this question needs
get_weather
Fetch current conditions for New York
save_to_database
First attempt — connection refused
save_to_database
Retry with backoff — row written
query_database
Read back to confirm the write
It's 18°C and sunny in New York. I've saved this to your database.
Why transparent execution matters
A chat box hides whether anything happened. This exposes the system's behaviour.
Transparent execution
Every tool call and its result is visible. You can tell the difference between a real agent and a wrapper around one model call.
Real integrations
A read-only SQL database, a live weather API and a calculator — actual services, not stubbed responses shaped like them.
Reliable and recoverable
A failing tool feeds its error back into the model rather than ending the run. The recovery is part of what you watch.
Production shaped
A real MCP client/server boundary, streamed over SSE, with the tool surface declared rather than improvised in a prompt.
The loop
- 1
You ask a question
Plain language. No tool names, no syntax.
- 2
The agent plans
The model picks tools from the surface the MCP server declares — not from a list glued into a prompt.
- 3
Tools execute
Each call runs against the real service, and its result and latency stream back as they land.
- 4
You get the answer
A complete response, with the trail of how it was reached still on screen next to it.
System architecture
The interesting part isn't that it calls tools. It's where the boundaries are drawn.
Client
Agent service
MCP client
MCP server
Model
Key engineering decisions
- Why a real MCP client/server split rather than functions in one process?
- Because the split is the point. In-process function calling works until the tools belong to another team, another language or another security boundary — which is the situation in every organisation worth building this for. Paying the protocol cost in a demo proves the design survives contact with that reality.
- Why is the SQL tool read-only, and guarded?
- An agent with write access to a database is one hallucinated statement away from a very bad afternoon. The tool accepts a constrained query shape and rejects anything outside it before the database sees it. Capability restriction belongs at the tool boundary, not in a prompt asking the model to behave.
- Why stream every tool call to the screen?
- Operationally, because a run that takes twenty seconds with no output is indistinguishable from one that has hung. Commercially, because the streamed timeline is the only way a visitor can verify from the outside that any of this is real.
- What happens when a tool fails mid-plan?
- The error is fed back to the model as a result, not swallowed and not raised to the top. The model can retry, substitute another tool, or tell you plainly that it could not complete the step — and you see which of the three it chose.
Need AI agents connected to your real systems?
The hard part of an agent is not the prompt. It is deciding what the model is allowed to touch, what happens when a tool fails mid-plan, and how an operator sees what the agent actually did. That is the part I designed here — and the part I would design for your systems.