How can I monitor and capture telemetry for MCP tool calls?
Every MCP deployment on CMD+K captures telemetry for you: one row per request, written inside the gateway after the response body exists, so the tool name and the real outcome are both on it. An HTTP access log cannot do this, because every tool call is the same POST to the same URL and a failed tool call returns HTTP 200. The dashboard turns those rows into a request log you can filter and a daily usage rollup, and the same rows drive billing.
The request log
Each deployment has a Requests tab listing one row per request handled by the gateway. Every row carries the fields you need to answer "who called what, and did it work":
- What ran.
method(the JSON-RPC method) andtool_name, kept separate so handshakes and tool listings never inflate your tool-call counts. - How it went.
okread from the result body,error_code,status_codeandlatency_ms. - How big it was.
request_bytesandresponse_bytes, which is how an oversized tool result shows up before it starts truncating answers. - Who called.
client_ip,user_agent, the connectedend_user_id, and for in-product assistant traffic the visitor subject and email from the verified token.
The log is filterable by method, tool, outcome, HTTP status class, caller and time window. Dashboard smoke tests are excluded, and synthetic system events are hidden unless you ask for them.
Daily usage
The Usage panel shows the last 30 days (UTC) from a daily rollup written alongside each request: calls, failures, latency and bytes per day. Rejected and probe traffic is kept out of the rollup on purpose, so a bot hammering your endpoint with bad credentials cannot turn your error rate into a number that means nothing.
Where the time went
Every gateway response carries an x-cmdk-timing header with a phase breakdown in milliseconds, for example session=2;gates=14;auth=31;upstream=2810;record=48;total=2905. The upstream phase is time spent in your own API. This is the fastest way to settle whether a slow tool call is the gateway or the service behind it.
Retention and export
- Per-request rows: 30 days, pruned nightly.
- Daily aggregates: kept indefinitely.
- CSV export: from the Requests tab, up to 30 days and 10,000 rows per file.
Telemetry and billing are the same rows
Every billable tool call appears in the request log. If a request is missing from the log it was not billed. There is no separate billing log to reconcile against.
Next steps
FAQ
- How can I monitor and capture telemetry for MCP tool calls?
- On a CMD+K deployment it is already captured: open the deployment and use the Requests tab for per-request rows (tool, outcome, latency, bytes, caller, end user) and the Usage panel for daily totals. If you are instrumenting your own server, the capture point is inside the JSON-RPC handler after the response body exists, because the tool name is in the request body and the outcome is in the response body. Neither is visible to a proxy or an access log.
- Are failed tool calls counted as failures?
- Yes. The gateway reads isError out of the result body and stores it as its own ok boolean, so a tool that fails inside an HTTP 200 is recorded as failed. Requests rejected before dispatch (auth failures, gateway rejections) are logged too, but under a parenthesised synthetic method such as (POST rejected), which keeps them out of the usage rollup while leaving them searchable.
- Can I tell which AI client made a call?
- The request log classifies the caller from the user agent across 13 client families (Claude, ChatGPT, Cursor, Windsurf, VS Code, Gemini, MCP Inspector, Postman, curl, Python, Node, browsers) plus explicit buckets for the in-product assistant, your own test sessions and unknown. Filter the log by caller to separate real client traffic from your own testing.
- How long is MCP telemetry kept?
- Per-request rows are kept for 30 days and deleted by a nightly job. Daily aggregates are kept indefinitely, so trends and billing history survive after the raw rows are gone.
- Can I export MCP telemetry?
- Yes. The Requests tab exports CSV over a window of up to 30 days (7 by default), capped at 10,000 rows, with the columns at, method, tool_name, ok, status_code, latency_ms, request_bytes, response_bytes, end_user_id and error_code. For programmatic access, the management MCP exposes get_widget_usage and get_workspace_usage.
- How do I tell whether a slow tool call is your gateway or my API?
- Read the x-cmdk-timing response header. It breaks the request into session, gates, auth, upstream, record and total milliseconds, so upstream=2810;total=2905 means your API took the time, not the gateway. Requests over 1500 ms are also written to the platform log with the same breakdown and the tool name.