MCP server analytics: count the calls, then ask the caller
Call counts, latency, and error rates tell you what agents did with your server. They cannot tell you what the agent was trying to do, what confused it, what it needed that did not exist, or whether a 200 OK was actually useful.
- For
- Teams running MCP servers who want to know how agents use them
- Question
- Measure MCP server usage and the agent experience behind it
- Start with
- Take the tool with the most calls per session, read its retry sequences, and ask its agents what they were trying to do.
- Updated
- Usage analytics
- Calls per tool, latency, error rates, and client mix, from logs, APM, or product analytics.Cannot tell a useful 200 from an empty one.
- Behavioral signal
- A sequence the server sees, such as a near-identical retry or an error followed by silence.Observed. Any reason attached to it is inference.
- The agent account
- What the agent says it was trying to do, what confused it, and what it needed.Stated. It proves what was said, not every fact inside it.
Each term is paired with the thing it is not. Most agent research arguments are really vocabulary arguments.
Three things to hold on to
Measure what happened on the server
Calls, latency, errors, and client names are cheap to collect and answer operational questions.
Read behavior as a clue, not a verdict
Retries and abandoned sessions point at friction. Their meaning stays inference until the agent says so.
Ask the caller what the call was for
Only the agent can say what it wanted and what it worked around. Give it a tool to say so.
The argument, in order
What usage numbers can and cannot answer
Most MCP server analytics start with calls per tool, latency percentiles, error rate, and client mix. They answer load, speed, and reliability questions well.
Every one of those numbers describes what the server saw. A tool can show zero errors while agents call it three times per task because the first answer was never enough.
Counts, latency, and errors from the server
Log one structured event per tools/call. Any log search or analytics tool can build the dashboard from it.
- Tool name and a session or connection identifier
- Client name and version, from clientInfo in the initialize request
- Duration, and whether the result set isError
- Result size, so empty and truncated responses stand out
- Protocol errors such as unknown tool names, counted apart from tool errors
Sequences are observed. Their meaning is not.
Order each session’s calls and patterns appear: a near-identical retry, the same second call every time, an error followed by silence.
These are observed facts, worth alerting on. Their reasons are inference: a retry can mean confusion or deliberate comparison, and an empty result can be true.
The agent account, in its own words
The third layer is one a log cannot produce: the agent states what it was trying to do, what confused it, and what it needed. Each report names a tool, so it joins the first two layers.
Add submit_agent_feedback beside your tools, optionally with one exit-survey question. Agents file when the tool and a filing norm are visible in their context and stay silent when they are not, so verify one real report first.
Join the layers on the tool name
Put each tool’s reports next to its counts and sequences. After a change, look for it in both: fewer calls per session, and reports that stop naming the gap.
- Is the server up and fast? Layer one answers.
- Where do agents struggle? Layer two points, layer three explains.
- What should we build next? Layer three, weighted by layer one.
What each source is allowed to proveThe tier decides the claim. Read the right-hand columns first.
Five successful calls, and the task still failed
An agent needed last week’s paid orders. It called search_orders four times with a since filter, got 200 and an empty list each time, then called list_orders.
Four search_orders calls with different since values, each 200 and empty, then one list_orders call.
ProvesThe calls, their order, and that each succeeded at the protocol level.
Does not proveWhether an empty list was the true answer or a misread input.
A retry rule flags the session as a search loop that ended in a fallback.
ProvesThat the sequence matches a pattern someone defined.
Does not proveThe cause. Empty results can be correct, and retries can be deliberate.
The agent reported it could not tell whether no orders existed or its date format was wrong, so it listed everything and filtered itself.
ProvesWhat the agent was trying to do and what the empty response cost it.
Does not proveThat every client fails this way. Check the parser before shipping a fix.
Illustrative, not customer evidence. A usage dashboard counts this session as five successful calls.
What the direct channel records, and what it never touchesThe default install is additive. It adds two tools and changes nothing else.
The research submission
- Reports the agent chooses to file, each naming a tool
- The goal, outcome, and satisfaction the agent supplies
- What the agent says was confusing or missing
- Direct answers to an exit survey
Everything else
- Your call counts, latency, and error metrics
- Arguments and results of your existing tools
- Session capture in the default install
- Any claim that a retry pattern explains itself
One paste, then verify a real reportA healthy endpoint is not an active study. The inbox record is the proof.
Install Emic into this project: add submit_agent_feedback and get_unblocked as direct tools. Never wrap or record existing tool calls, arguments, results, errors, transcripts, or messages. Additive only, plain HTTP, zero dependencies. Full instructions: https://emic.sh/llms-full.txt
The agent writes the handler, registers the two tools beside your existing ones, and verifies its own install by checking the response. Nothing is placed in front of the tools you already ship.
- Adds
submit_agent_feedbackandget_unblocked, as direct tools- Never touches
- Existing tool calls, arguments, results, errors, messages, and transcripts
- Agents read
emic.sh/llms-full.txt- Start with
- Take the tool with the most calls per session, read its retry sequences, and ask its agents what they were trying to do.
Questions teams ask before starting
What should I log for MCP server analytics?
One structured event per tool call: tool name, session, client name and version, duration, isError, and result size. Count protocol errors such as unknown tool names separately.
Does Emic replace my analytics?
No. Emic does not record your tool calls. It adds the agent account, so keep your analytics and join the two on the tool name.
Can analytics tell me why agents retry a tool?
They show that it happened and how often. The reason stays inference until the agent states it.
Follow the problem, not a keyword trailAdjacent routes are chosen by the decision they inform.
Experience vs observability
Observability explains system behavior. Experience research preserves what the user says the work was like. Strong product decisions often need both, clearly labeled.
Read next Use cases · MCP serversMCP server feedback
Your server can return valid JSON and still make an agent guess through five calls. Emic gives that agent a direct research channel after the work is done.
Read next Guides · Tool design guideMCP tool descriptions
An agent chooses and calls your tool from a name, a few sentences, and a schema. Write them for a reader that cannot ask a follow-up, then let agents tell you where they still guessed.
Read nextKeep your counts. Add the caller’s account.
Register the feedback tool beside your MCP tools and read its reports next to your numbers.
Free covers 2,000 feedback events a month, no card. Prefer help? The assisted 14-day pilot is free too. Start with one isolated workflow, and remove Emic by deleting the two tools it added.
- One paste to install
- 0ms on your hot path
- Free tier, no card
- Two added tools to remove