Your customers are telling their agent what they want from your product. Can you hear them?
Every agent call is a request in plain language, but when your API can't meet their needs, you see a 200
instead of an error. The request vanishes with no ticket and no trace. Baton captures the friction from
your API, ranks what customers actually want, and lets you respond to them if you want to.
Point Baton at a server you've already configured in Claude and get a friction report in minutes:
uvx baton-proxy scan --config <server-name>
Aim at dev, not prod · runs locally · open source · no signup ·
View source
Your logs capture status codes. Baton captures your customer's intent.
When your API falls short, you get a report like this. Pick the example closest to your product:
See it on your own MCP server. One line, no rebuild.
uvx baton-proxy scan --config <server-name>
A friction report in a few minutes.
Exercises every tool, including writes. Aim it at a dev or local instance, not production.
Runs locally. Events write to a file on your machine; nothing is sent anywhere by default.
Open source, Apache-2.0, zero deps. Read every line before you run it.
No rebuild, no signup, no creds. It wraps your server, it doesn't change it.
What it does and doesn't do
Targets a server you've already configured in Claude — pass --config <server-name> and it reuses your saved credentials.
Drives a headless agent that exercises every tool and annotates friction — errors, missing capabilities, and silent successes.
Runs on your own Claude session; LLM cost lands on your auth, never Baton's.
Events write to a local temp file and are deleted after the report — nothing leaves your machine.
The scan is a preflight — one run, inferred signal. To capture friction from real customer traffic, add the
SDK to your MCP server in about five lines. Every agent that connects gets the signal automatically, nothing
changes for your customers. It injects one tool, annotate,
that records intent before each call and flags the gap after — the four things only the agent has: intent,
the call, what it expected, what it got. Free and open source.
No MCP server? If your customers reach you through agent-generated code — a Skill calling your REST API — the
SDK's Library API wraps those calls instead. Same signal, same sinks, nothing to rebuild.
Not the server author? The proxy picks up where the scan left off: prepend baton-proxy --
to any server you run and capture the same signal from your own real sessions — yours, your team's, or
servers you use regularly. No rebuild, same local events file.
Go from signal to an actionable system with Baton Console.
The proxy and SDK capture the friction for free. The Baton Console collects it from every customer and every
session, then does two things a local report can't:
See the friction across every customer
It dedupes and ranks the friction into trends: your top unmet demands, your silent-failure rate by tool, what to build next. A roadmap, not a single transcript.
Respond when you want
When something's worth a human, the Console hands your team the fully-described issue and sends the resolution back into the customer's agent. That's where support lives: the first response is a fix, not a question.
Capturing the signal is free. The Console is the paid tier where you act on it.
You control what's captured. You can audit the rest.
You decide where the data goes
You choose which fields are captured, and PII is scrubbed before anything leaves your machine. From there it's your call: keep events entirely in your perimeter (a local file, your own OpenTelemetry sink, or your S3) and send us nothing, or route them to the Console.
The Console is hosted by us, auditable by you
When you route to the Console, your data is hosted single-tenant and fully auditable: every event is logged and inspectable, so you can see exactly what each agent sent, when, and why. You still define the schema, so what you don't capture can never reach us.
Questions, answered.
Isn't this just LangSmith or observability?
No. Tracing tells you a call happened and how long it took. Baton captures what the customer was trying to do, where your API fell short, and the fix. It runs alongside Sentry and LangSmith and sees the layer they don't: intent.
Do I have to rebuild anything?
No. If you have an MCP server, the proxy wraps it with no code changes, or the SDK builds in with about five lines — your tools stay exactly as they are. If you don't have an MCP server and your customers reach you through agent-generated code (a Skill calling your API), the SDK's Library API instruments those calls instead. Either way, nothing about your product changes.
Will the scan change anything on my server?
The agent exercises every tool, including write tools, so aim it at a local or dev instance rather than production. It reuses the credentials from your existing Claude config entry — it doesn't add or change anything on your server itself.
Where does my data go?
Nowhere, by default. The open-source capture writes to a local file or a sink you choose: your own OpenTelemetry endpoint or your S3. PII is scrubbed before anything leaves. You only send to the Console if you choose to.
What's free, and what's paid?
Capturing the signal is free and open source: the proxy, the SDK, and the local report. The paid Baton Console is where you aggregate the signal across customers, see trends, and respond back to the user.
Do my customers' agents have to change?
No. You instrument your side, once. Whatever agent your customers use, Claude, Cursor, ChatGPT, or Codex, keeps working exactly as before.
See what your customers wish your agent-facing product did.
Start free: run the scan on your own server. When you're ready to turn the signal into a system, talk to us about the Console.