Which service-level indicators should an MCP tool expose?

Start with the operation the caller needed

A host asks a tool for the current service owner’s contact. Receiving valid JSON proves that a response arrived; it does not establish that the contact is current, belongs to the requested service, or reached the host in time. Define the usable result before selecting a dashboard metric.

For a directory lookup, a good outcome could be a source-identified owner record within two seconds, or an explicit authoritative not_found. Those are local product choices. A fabricated contact, an unmarked stale record, and an unexplained timeout would not satisfy that promise.

Give each response layer its own classification

The MCP error model distinguishes protocol errors from execution errors within tool results. Preserve that distinction in instrumentation, then add the domain outcome rather than overloading a single success flag.

Use bounded categories: protocol response, expected denial, eligible completion, unavailable dependency, stale result, malformed result, and unknown terminal outcome. A valid policy-denied result may be healthy protocol behavior while lying outside eligible lookup availability. Conversely, a policy service outage for an otherwise eligible caller belongs inside the failure population.

Ten thousand requests produce three different rates

Consider a hypothetical one-hour review with 10,000 logical lookup requests. Of these, 300 correctly fail eligibility because their callers lack access. Of the remaining 9,700, 9,450 deliver fresh acceptable records, 120 deliver results marked too stale, 80 exceed the deadline, and 50 remain unclassified.

Suppose 9,900 of all 10,000 requests receive valid protocol responses. Protocol responsiveness is 99%. Eligible service success is 9,450 / 9,700, about 97.42%. Outcome classification coverage is 9,650 / 9,700, about 99.48%. These calculations describe different facts; none can replace the others.

Keeping the 50 unknowns in the eligible denominator prevents missing evidence from improving availability. Investigating them may later change the result, so the report also states when the measurement window was closed.

Make the denominator dictionary reviewable

The following author-designed dictionary is the artifact to adapt. Store definitions with a revision so policy or classification changes cannot silently rewrite the meaning of a trend.

Indicator	Numerator	Denominator	Primary owner
Protocol responsiveness	Valid protocol responses within deadline	All observed protocol requests	MCP runtime team
Eligible lookup success	Acceptable terminal records or authoritative absence	Eligible logical lookups, including unknowns	Directory service owner
Freshness adherence	Successful records meeting source-age requirement	Successful records requiring freshness	Data pipeline owner
Outcome coverage	Eligible operations with terminal classification	Eligible operations due for classification	Instrumentation owner
Expected-denial accuracy	Reviewed denials confirmed correct	Reviewed denial sample	Policy owner

Google’s SLO guidance provides the good-events/total-events foundation. The specific populations above are a local design proposal, not a protocol requirement or recommended target.

Avoid a latency win caused by fast refusals

If a broken policy update rejects useful work in twenty milliseconds, aggregate latency may improve. Calculate tool latency for comparable eligible outcome classes and retain the denial distribution beside it. Also distinguish machine service time from time spent waiting for a user decision.

For tools that return pending work, publish time to acceptance separately from time to the promised terminal result. That does not require this guide to define their state machine; it requires the metric to name which milestone it measures.

Connect a breach to an owner’s decision

Before adopting an objective, decide what happens when it is missed. Stale directory records may stop a data-pipeline release. Missing classifications may pause expansion because responders cannot explain failures. Expected denials may trigger policy review without being counted as runtime downtime.

Thresholds should reflect a supported workflow and observed baseline. A target copied from another API can make a dashboard precise while leaving its operational purpose vague. Keep severe boundary violations outside averages so a large number of ordinary successes cannot offset them.

Sample usefulness without hiding the sample

Freshness and schema checks still do not prove that the result answered the user’s question. Review a defined sample of requests against authoritative records, report the selection method and sample size, and retain corrections. Do not label that estimate as complete production correctness.

For the telemetry needed to join these records, use MCP calls across a gateway. For confirming external changes, use verification after HTTP 200.