MCP insights & logs
Agents do not file support tickets. When a tool call fails, loops, or slows to a crawl, the only witness is the wire — so Elva records it. Every hosted MCP server ships with observability for the agent era: per-agent activity, per-tool health, latency percentiles, token metering, and a call-by-call log, with zero instrumentation on your side.
Your MCP server, six tabs
Open any MCP server in Elva and everything about it lives in one workspace. Insights and Logs are the observability half.
Tab | What it holds |
Overview | The server's identity: name, visibility badge, and the live MCP URL agents connect to |
Tools | Every operation you exposed as a tool, exactly as agents see it |
Authorization | How the gateway authenticates to your upstream API |
Insights | Rolled-up metrics: requests, latency, errors, tokens, agents, and per-tool breakdowns |
Logs | The raw feed — one entry per tool invocation |
Settings | Branding, visibility, custom slug, and the public install page configuration |
Four numbers that tell you if agents are winning
The top of the Insights tab answers the health question at a glance, over a rolling 24-hour window:
Metric | What you learn |
Total requests (24h) | Demand, with a day-over-day trend so a spike or a silence stands out immediately |
Avg response time | Typical speed, paired with P95 — the tail latency agents actually feel when they chain tool calls |
Error rate | The share of failed calls, with the failed-versus-total count behind it |
Token usage | Aggregate tokens plus the average per call — the cost signal for agent traffic |
Agents retry. A human hits a broken endpoint once and gives up; an agent may hammer it in a loop. That is why error rate and token usage sit on the same row — a failing tool is usually also an expensive one.
Agent activity: who is actually using your API
This is the adoption dashboard most API teams have never had. Elva auto-detects each calling client from its requests — claude, cursor, windsurf, copilot, or the raw identifier for anything else, such as openai-mcp/1.0.0 (Codex) — and renders a card per agent:
- Last seen — how recently the agent called, from minutes to days.
- Calls today — the volume this agent is driving.
- Tools used — how much of your surface it has discovered and adopted.
You do not tag anything and agents do not register. They connect, they call, and they appear.
This is the question every platform team is about to be asked: "which AI assistants use our API, and for what?" With Elva the answer is a screen, not a research project.
Drill-down panels: from symptom to culprit
Below the headline metrics, four expandable panels break the same 24 hours down by key, tool, and failure mode:
Panel | The question it answers |
API Key Usage (24h) | Which credentials are driving the traffic — and which issued key nobody uses |
Most Error-Prone Tools | Which tools fail most, their top error, and the agent hitting them hardest |
Slowest Tools (P95) | Where the latency tail lives, with P50 / P95 / P99 per tool |
Top Tools by Volume (24h) | What agents actually lean on — often not the endpoints you expected |
The Logs tab: every call, on the record
Insights are rollups; Logs are the evidence. The gateway writes one entry for every tool invocation it serves — the detected client, the tool name, the upstream status code, the round-trip duration, and the timestamp — so nothing an agent does is a black box.
That single feed does double duty:
- Debugging. A tool started failing at 14:02? The log shows which agent, which arguments pattern, and which upstream status — before your first guess.
- Audit. When security asks “what exactly did the agent touch,” you scroll, you do not reconstruct.
Prefer push over pull? MCP webhooks deliver server activity to your own endpoints — Slack, PagerDuty, SIEM — the moment it happens. See the Admin & management section.
From signal to fix
The views are designed to chain, so a bad metric turns into a shipped fix in minutes:
1
Spot the symptom
The error-rate tile jumps — say 36% of calls failing in the last 24 hours.
2
Find the culprit
Open Most Error-Prone Tools. One tool owns nearly all the failures, and the panel names its top error and the agent driving it.
3
Read the evidence
Jump to Logs and filter your eyes to that tool: the status codes tell you whether it is a 401 (auth), a 422 (schema), or a 500 (your API).
4
Fix at the source
Auth failures point at the Authorization tab; malformed-argument failures point at the operation's schema and descriptions — see AI readiness.
5
Watch it recover
The 24-hour window rolls forward and the error rate falls with it. No deploy, no dashboard to build.
While a deployment warms up, some dashboards render illustrative sample data alongside your real logs so the layout is never empty. Read them as capability types rather than exact figures until your own traffic fills in.
FAQ
What counts as a connected agent?
What counts as a connected agent?
Any client the gateway identified and logged in the last 24 hours. Elva counts distinct client names over that window, so an assistant that called yesterday but not today drops off the live count while its history stays in the logs.
How are Claude, Cursor and other clients told apart?
How are Claude, Cursor and other clients told apart?
The gateway inspects each incoming request and classifies the caller. Recognized clients map to friendly names like claude, cursor, windsurf and copilot; anything else is logged under its raw client identifier so it is never lost.
Where do the numbers come from?
Where do the numbers come from?
Every metric on the Insights tab is aggregated from the per-call log the gateway writes on each invocation — the same entries you can read raw on the Logs tab. One source of truth, two zoom levels.
Where to go next
The enterprise MCP gateway
The control point that writes these logs: auth relay, encrypted envelopes, and tool-level exposure control.
AI readiness
Fix the schema and description gaps behind malformed-argument failures before agents hit them.
On this page
- MCP insights & logs