Configuration

On every tool call, the wrapper records the following. Arguments and results are sanitized and bounded in your process before transmission.

• Tool name and bounded sanitized arguments/results (after automatic and configured redaction)
• Capture policy and whether fields were truncated
• Client name and version when the MCP initialize exchange provides them
• Protocol method, transport, catalog descriptions, and schema hashes when observed
• Duration in milliseconds and transport status
• Session id, so calls can be inspected in order
• Timestamp and environment
• Optional caller context with explicit intent provenance, or an explicit missing-capability report

Payload capture defaults to redacted. Sensitive keys such as passwords, tokens, API keys, authorization, cookies, private keys, SSNs, and card numbers are replaced recursively before transmission. Data URIs, large base64 strings, bearer tokens, and credentialed resource URLs are scrubbed.

metadata sends no arguments or results. full is opt-in but is never unlimited: every mode is capped at 32 KiB, depth 6, 50 keys/items per container, and 2,048 characters per string. Omitted content is represented by a structured truncation marker, and payload_size_bytesmeasures the final sanitized payload. The SDK's 32 KiB payload budget is intentionally lower than the ingest route's independent 128 KiB payload and 1 MiB request limits; the server limits are a last-line defense for non-SDK clients.

The redactEvent hook runs after automatic sanitization. It may mutate the sanitized event or return null to drop it. Hook failures drop only that telemetry event; they never interrupt the wrapped MCP server. SDK queues are bounded to 500 events or 2 MiB, and failed deliveries are requeued only within those limits.

• Active clients, new and returning connections
• Explicit workflow outcomes and a separately labeled session heuristic
• Tool call volume, adoption, and week-over-week change
• p50 / p95 latency and error rate per tool
• Observed MCP tool errors, including errors inside a successful transport response
• Ordered server-boundary traces and where observed sessions stop
• Tool call share, observable empty-result rate, explicit retry and repeat-call patterns, and historical catalog comparisons

Tool latency is calculated from observed non-negative duration_msvalues. p50 and p95 use the nearest-rank method: sort the values and select ranks ceil(n × percentile). The dashboard shows N/Awhen no duration samples exist; it does not invent or interpolate a value.

A successful tool response is not proof that the user's job finished. The completion source is workflow_events when your application emits an explicit workflow lifecycle event, session_heuristicwhen TrackMCP only sees a final successful tool call, or nonewhen neither signal exists.

The trace explorer is authenticated and workspace-scoped. Each trace response is capped at 200 events by the dashboard (API callers may request 1–1,000), and reports event_count and truncated so a partial trace is visible. TrackMCP observes the MCP server boundary; it does not read private model reasoning or host-side turns.

Tool-quality analytics are exposed at /api/v1/tool-quality and remain separate from aggregate analytics. tool_call_share is the observed share of eligible calls for a tool; it does not measure considered but unselected tools. Rates use known outcomes or inspectable payloads only, and missing, metadata-only, or truncated evidence is not treated as an empty result.

An observed repeat call is the same tool called at least twice within five minutes in the same session or correlation group, excluding explicit retries. It is not a confirmed re-ask. Catalog comparisons use the snapshot effective at each call's timestamp. Explicit workflow completion uses only workflow IDs, ordered tool paths, and explicit started/completed/failed events.

“Associated with low explicit completion” is shown only when the explicit completion rate is strictly below 0.80, at least 20 eligible workflows have an explicit completed or failed terminal outcome, and at least 30 associated eligible calls exist. Unknown or missing outcomes are excluded. This is an association for investigation, not a causal claim or a statement about an LLM/model.

Correlation is disabled by default. TrackMCP never overloads session_idor request_id. External mode accepts a synchronous application resolver for bounded metadata and records only a validated anonymized opaque handle. Resolver failures and invalid values are fail-open and recorded as missing. Handles are capped at 128 UTF-8 bytes and must not contain credentials, URLs, emails, raw user IDs, prompts, completions, or private reasoning.

TypeScript issued mode is compatibility-limited to compatible object-shapedtools/list schemas: the optional namespaced field is stripped before the customer handler and only echoed values receive issued provenance. Unsupported schemas and clients that ignore the field remain missing. Python exposes the same option names for parity, but its current middleware reports missing because it has no stable schema rewrite seam.

@trackmcp/sdk/client-adapter is a separate Node-only entry point pinned to @modelcontextprotocol/sdk 1.30.0. It wrapsStdioClientTransport orStreamableHTTPClientTransport beforeClient.connect(transport). Browser and Edge runtimes, frontend bundles, SSE, custom transports, Python clients, and universal desktop-client support are outside this release.

Client capture defaults to metadata-only and is limited to transport-observed issued calls, matched results, next observable calls, repeats, and lifecycle boundaries. It does not claim timeout, abort, promise rejection, late-response, or hidden Streamable HTTP reconnect/authentication attribution. Malformed, notification, unmatched, and duplicate messages produce diagnostics only. Client events use observation_source: "client"; aggregate and Tool Quality metrics remain server-observation-only.

Intent is never inferred. A compatible TypeScript tools list may advertise an optional context argument describing the user's underlying goal; TrackMCP removes that known field before the customer handler runs. Context is labeled context_parameter. AnintentFallback callback is called only when safe context is absent and its value is labeled fallback. External systems may submit bounded text with intent_source: "external_callback". Otherwise the source is missing.

Use trackmcp_report_missing for an explicit missing tool or capability report. Context and capability values inherit the SDK string and privacy limits; credentials, URLs, emails, and oversized values are omitted. Python keeps handler arguments unchanged and exposes the same event fields andreport_missing method, but does not rewrite tool schemas.

Python reads TRACKMCP_KEY automatically when an API key is not passed. TypeScript requires apiKey in the options. For a compatible deployment, pass the ingest URL explicitly as endpoint;TRACKMCP_ENDPOINT is not read automatically.