# MCP Tool Readiness

## Evidence, policy and safe routing beyond discovery

Author: Jason Doyle

First published: 14 September 2026

> Disclosure: These views are my own and do not represent my current or any former employers. This paper uses only public sources and does not describe non-public product information.

## Executive summary

Model Context Protocol has made tools discoverable and callable across vendors. An agent can obtain a catalogue entry, learn a tool name, read an input schema, present credentials and issue a call, and the same code path works against servers written by people who have never spoken to each other. That is a real achievement, and it is the achievement the protocol set out to deliver.

Discovery and invocation interoperability are one layer of what a production agent needs. A runtime that selects a dependency at execution time also needs to know whether that particular tool, at that particular version, for that particular principal and tenant, in that region, for that class of input, is ready now. It needs to know who said so, when, on what evidence, and under whose policy. It needs a record afterwards showing how the dependency affected the work.

Readiness is therefore a vector rather than a flag. Its subject is the combination of endpoint, tool, server version, protocol version, schema digest, principal, tenant, region, input class and time. An endpoint can be ready at one layer while being unready at another, and a result can be valid at the transport layer while being useless to the task.

This paper contributes a layered readiness model and a standards-neutral operating model built on four separate artifacts:

1. provider declaration, which states intent and configuration;
2. observed evidence, which records what a named observer measured over a stated sample;
3. consumer policy, which encodes what this organisation will accept;
4. execution receipt, which records what was actually decided, called and achieved.

Collapsing those four into a single score is the mistake that makes readiness data unsafe to act on. Keeping them apart is what makes routing decisions auditable.

The empirical material is a frozen copy of a public probe export. On 14 September 2026, between 09:23:21Z and 09:25:04Z, Cracked Engineering recorded 986 probes of remote Streamable HTTP MCP server records drawn from its own synced catalogue. In that file, 975 records completed the probe's listing path and 659 completed one chosen unauthenticated call. Of the 975 that listed successfully, 316 did not complete that call.\[1\] Those numbers are reproducible from the frozen file, and the analysis script published beside this paper verifies its SHA-256 digest before calculating anything.

The correct description of that result is a one-night keyless probe completion funnel from one undisclosed vantage point. It is not an availability service level indicator, not a production service level objective, and not evidence that any server was unavailable, unusable or broken. In general, a 401 response is strong evidence that an endpoint was alive and enforcing access control. A rejected empty-argument call is evidence about the probe's chosen invocation. The gap between listing and call completion is interesting because it shows that catalogue presence and listing success answer a narrower question than an orchestrator needs answered.\[2\]

The Official MCP Registry is designed as a metaregistry of publisher-supplied metadata. Its own documentation states that it makes no quality judgement and offers no uptime guarantee, and it expects downstream aggregators to add ratings, scans and other enrichment.\[3\]\[4\] That is a coherent scope decision. The readiness layer this paper describes belongs in a subregistry, a private catalogue, a gateway, a deployment policy repository or a companion profile, and it requires no change to MCP core.

The strongest objection is that most production integrations are wired deliberately by engineers who already know their dependencies, and that those teams gain little from a public readiness layer. That objection is largely correct, and section 14 answers it proportionately. The model earns its cost where an agent selects among candidates at runtime, where the same tool is called under many identities and tenants, or where an organisation has to explain after the fact why a particular dependency was used.

## 1. Discovery is one layer of readiness

An agent orchestrator that is about to call a tool is answering a question with several parts. Is there a candidate? Can I reach it? Do we speak a common protocol version? Does this principal hold sufficient authority? Will this tool accept this input class right now? Is the result structurally valid? Is it semantically useful? Did it move the workflow forward? If it failed, can I recover without doing harm twice?

MCP answers some of those questions directly and deliberately leaves others to the deployment. The protocol defines how a client learns what a server offers, how schemas are expressed, how calls are made, how results and tool-level errors are returned, and how HTTP authorisation is discovered.\[6\]\[7\] It does not define a universal availability indicator, a production objective, a pricing model, fixed timeouts, a retry algorithm, health-weighted routing, semantic equivalence between two tools offered by different publishers, or contractual remedies. Those omissions are scope boundaries rather than defects. A wire protocol that tried to specify an operator's error budget would be the wrong kind of document.

The consequence is that something else has to answer the remaining questions. Historically that something else was a developer. A person read the documentation, obtained a key, tested the endpoint, decided the timeout, wrote the retry logic, chose whether a fallback was acceptable, and carried the knowledge that one provider's price lookup returns retail prices including tax while another returns trade prices excluding it. The integration was static, and the operational judgement lived in the engineer's head and in the code review.

Dynamic tool use moves that judgement to runtime. When a catalogue is large, when tools are loaded on demand to control context size, or when several publishers offer apparently equivalent capabilities, the selection is made by software during execution. Research on dynamic tool retrieval has shown that agents can scale to large tool populations by retrieving candidates semantically rather than preloading everything.\[20\]\[21\] Those systems optimise retrieval accuracy and context efficiency. They do not carry operational evidence about the endpoint behind the tool, and they are not designed to.\[23\]

So the practical gap is between two questions that look similar and are not. "Which tool matches this intent?" is a retrieval question. "Should this agent, acting for this principal, call this endpoint now, and what will we do when it fails?" is an operations question. The second question needs inputs the first one never collects.

This paper treats that as a layering problem. The protocol provides the interoperable substrate. A readiness layer sits above it, is owned by the consumer, is fed by evidence with provenance, and produces decisions that can be reviewed later. Nothing in that description requires MCP to change.

## 2. What the September probe measured

Empirical grounding matters, and it matters more that the grounding is described precisely than that it is described dramatically.

The dataset used here is a frozen local copy of a public export published by Cracked Engineering alongside its September 2026 report on public MCP servers. The copy is stored beside this paper as `mcp-probe-2026-09-14.csv` with the SHA-256 digest `4e84191c8feda3276fb9493f9f0b34644a90b88c634ca0a99b381c0e0b2475f7`. The upstream URL is regenerated after each nightly probe, so the digest, not the URL, is the research artifact.\[1\]

The sampled population must be stated in full. Cracked probed 986 records in its own synced catalogue that it classified as remote Streamable HTTP MCP servers with an open endpoint and no authentication requirement recognised by its filtering logic.\[2\] That population excludes local stdio servers, package-only registry entries, servers using other transports, entries its filter treated as authenticated, and any record absent from or delayed in its synchronisation. It is not every MCP server, not every public MCP server, not every record in the Official MCP Registry, and not a random sample of the ecosystem.

The keyless classification is not fully auditable from the export and admitted at least two URLs containing credential placeholders: `https://mcp.cardog.io/mcp?api_key={api_key}` and `https://mcp.aihomedesign.com/{connector_token}/mcp`.\[1\] One listed and failed the chosen call; the other completed it. This does not invalidate the funnel, and it shows that "keyless" describes the observer's filter rather than a property established for every record.

Every record carries a probe timestamp. The earliest is 2026-09-14T09:23:21Z and the latest is 2026-09-14T09:25:04Z, a wall-clock span of 103 seconds across 986 records. That span is consistent with substantial concurrency rather than sequential probing, and the effect of that concurrency on the latency figures is unknown.

The following figures are reproducible from the frozen file and are treated in this paper as measured facts about that file.

| Measure | Value | Denominator |
| --- | --- | --- |
| Records sampled | 986 | the frozen export |
| Unique server names | 986 | 986 records |
| `list_ok = true` | 975 | 986 records |
| Listing completion rate | 98.884 per cent | 986 records |
| `call_ok = true` | 659 | 986 records |
| Call completion rate, all records | 66.836 per cent | 986 records |
| Call completion rate among listed | 67.590 per cent | 975 listed records |
| Listed, then chosen call did not complete | 316 | 975 listed records |
| Records where the chosen call did not complete | 327 | 986 records |
| Median successful listing | 280 ms | 975 successful listings |
| Median successful call | 356 ms | 659 successful calls |
| Nearest-rank P95 successful call | 1,827 ms | 659 successful calls |
| Linearly interpolated P95 successful call | 1,741.5 ms | 659 successful calls |
| Successful calls at or above one second | 87 | 659 successful calls |
| Fastest successful call | 60 ms | 659 successful calls |
| Slowest successful call | 17,888 ms | 659 successful calls |
| Records with `streak` of three or more | 11 | 986 records |

The percentile convention is worth naming explicitly, because the two conventions differ by 85 ms on this sample. The published headline of 1.8 seconds is consistent with the nearest-rank value.

The distribution of the 659 successful calls is also reproducible:

| Band | Successful calls |
| --- | --- |
| under 250 ms | 201 |
| 250 to 499 ms | 222 |
| 500 to 999 ms | 149 |
| 1.0 to 1.9 seconds | 59 |
| 2.0 to 4.9 seconds | 19 |
| 5.0 to 9.9 seconds | 6 |
| 10 seconds or more | 3 |

The `streak` column records consecutive nights on which listing failed, and a record is withdrawn from the operator's active catalogue at three. The frozen file contains four records at three, two at five and five at thirteen.\[2\] Streaks above the withdrawal threshold show that withdrawal from an active presentation surface is not withdrawal from continued probing, and certainly not removal from the Official MCP Registry.

Two further points bound what these figures mean. First, the call in question is a single invocation of one tool chosen by the operator's heuristic as cheap and side-effect free, called with no arguments or trivially inferred arguments, under a 20-second timeout, with 12-second timeouts on setup and listing.\[2\] The most frequently selected tool names in the frozen file are `selftest` at 93 records, `get_recommended_action` at 75, `get_pricing` at 11, `scan_tops` at 8, `list_articles` and `list_categories` at 7 each, and `get_stats` and `ping` at 6 each. Second, the probe sequence used `initialize` and `notifications/initialized`, which belong to the session-oriented 2025-11-25 model rather than the current 2026-07-28 protocol.\[7\]\[6\] Section 5 returns to what that means.

The defensible summary is a single sentence. In one 103-second window on 14 September 2026, from one undisclosed vantage point, 98.9 per cent of 986 catalogued keyless remote endpoints completed the probe's listing path and 66.8 per cent completed one chosen unauthenticated call.

## 3. What the public data cannot establish

A twelve-column export can only carry twelve columns. The frozen file contains `server`, `title`, `url`, `website`, `tools`, `list_ok`, `call_ok`, `list_ms`, `call_ms`, `probed_tool`, `probed_at` and `streak`. Everything an operations team would want in order to act on a failure is absent.

There is no registry snapshot identifier, record version, publication or update timestamp, selected remote index, or registry cursor. Without those, the population cannot be reconstructed even by someone with full access to the Registry, because the Registry supports version selection, cursor pagination and deletion handling, and it changes while a crawl is running.\[3\]

There is no MCP protocol version, offered or negotiated. A record therefore cannot be read as evidence about current-specification conformance in either direction.

There are no call arguments and no tool-selection scores, only the chosen tool name. A successful call may show that a self-test method, a ping or a catalogue listing worked. It does not show that the server's consequential tools worked, that parameter-rich inputs were handled, or that anything was correct.

There are no HTTP status codes, no JSON-RPC error objects, no error text, no failure classes and no `isError` state. The published report describes failure categories such as authentication and payment walls and argument rejections. Those categories are report assertions supported by data that was not exported in this file, and this paper treats them as such rather than as measured facts.\[1\]

There are no category labels, descriptions or full tool lists, so the report's category analysis cannot be checked against the file.

There is no authentication declaration for the endpoint and no tenant context. There is no probe region, observer identity, concurrency setting, redirect policy or retry policy. There is no raw response and no repeat observation of the same endpoint, which is the specific absence that makes any availability language inappropriate: availability is a property of repeated eligible requests over a defined window, and this file holds at most one observation per endpoint.

The `tools` column deserves separate treatment because it illustrates how a public projection can differ from the record that produced it. In the frozen file, the maximum value is 100, thirteen records sit at exactly 100, and the column sums to 12,055. The published report cites a larger total and a largest catalogue well above 100 tools.\[1\] The straightforward reading is that the public column is capped at 100 and the report was produced from a richer internal record. A secondary detail supports that reading: the file contains 45 records in the 51-to-100 band, while the report cites 33 in that band and twelve catalogues above 100, and 33 plus 12 is 45. The median of six tools per record, the 39 single-tool records and the 333 records above ten tools are reproducible from the exported column. The eleven listing failures still carry non-zero catalogue counts, so those values were not observed by the 14 September listing call and should be treated as carried-forward catalogue data.

Finally, the upstream file is mutable. It is regenerated nightly and served from a stable URL, and the associated report has been revised in place as its underlying sample grew. Anyone citing it must freeze a copy and publish the digest, which is why the analysis script beside this paper refuses to run against a file whose SHA-256 does not match.

## 4. Reading the probe funnel correctly

Each stage of the funnel establishes something narrow and worth stating exactly.

A registry row is evidence that a publisher or aggregator supplied metadata that a catalogue accepted. Publisher verification in the Official Registry establishes control of a namespace or a linked package through GitHub organisation ownership, DNS proof or HTTP proof.\[5\] It is a claim about who controls a name. It does not establish that an endpoint is reachable, that the same party still operates the process behind the URL, that the server implements a protocol version the client supports, that access is available to any given principal, or that the tools behave correctly.

The `list_ok` column is evidence that, from the observer's vantage point and under the observer's protocol path, the endpoint completed enough transport, protocol and access steps to return a tool list inside a 12-second timeout. It does not establish compatibility with the current protocol, successful pagination of a long catalogue, authorised access to every listed tool, correctness of any result, or sustained availability.

The `call_ok` column is evidence that one heuristically selected unauthenticated call completed under the observer's success rule inside 20 seconds. The public methodology does not state whether a result with `isError: true` counts as `call_ok`, so 659 is an exact count for the exported field and an upper bound of unknown size on successful tool execution. It does not establish availability over time, success for a different tool, success with representative arguments, success under a real user's identity, output-schema validity unless that was separately checked, semantic correctness, workflow contribution, or safety of any side effect.

The failures need the same discipline.

A 401 response ordinarily means that the attempted identity did not present acceptable credentials, or that the endpoint required an authorisation flow the probe did not complete. A 401 accompanied by valid protected-resource metadata is positive evidence of two things at once: the resource is alive, and it is advertising a discoverable access path.\[8\] Classifying that as an endpoint failure discards information.

A 402 response ordinarily means the call met a payment or billing condition. That is a commercial state of the caller's relationship with the provider. It says nothing about general availability.

A tool result reporting that a key is required means the endpoint was operational enough to parse the request, route it to a tool and return an application-level access error. That is further through the stack than a listing success, not less far.

A rejected empty-argument call means the probe's chosen invocation did not satisfy the tool's contract. It does not show that a correctly parameterised call from an informed client would fail.

An MCP result carrying `isError: true` is the case that most often gets misfiled. The protocol deliberately separates protocol-level errors from tool-execution errors, so that a model can see and reason about a tool's own failure.\[6\] A transport success carrying a tool-execution error is simultaneously a protocol success and an invocation failure, and a readiness system that records only one of those two facts will mislead whoever reads it later.

Because of all this, the honest name for the September result is a one-night keyless probe completion funnel. It shows a substantial gap between catalogue presence, listing completion and completion of one chosen keyless call. It does not identify how many servers were unavailable, how many were unusable to authorised users, or how many were unsuitable as production dependencies. The phrase "66.8 per cent keyless probe completion" is supportable. Any phrase of the form "only 66.8 per cent were operational" is not.

## 5. Registry and protocol boundaries

Any proposal in this space has to respect what the Registry and the protocol already say about themselves.

The Official MCP Registry is a metaregistry. It holds publisher-supplied metadata pointing at packages and remote endpoints, and it does not host or execute servers. Its design documentation is explicit that it provides no quality ranking, no runtime certification, no availability judgement, no security guarantee and no uptime or durability guarantee, and that downstream aggregators are expected to persist the data and enrich it with ratings, security scans and classifications.\[3\]\[4\] Subregistries can expose that enrichment through the same API shape, which is the intended extension path for anything resembling operational metadata.\[4\]

The extension surface inside the Registry itself is deliberately small. The generic `server.json` format permits namespaced `_meta` blocks, while the Official Registry retains only the publisher-provided namespace and caps it at 4 KiB, and registry-managed lifecycle fields cannot be overridden by publishers.\[5\] A 4 KiB allowance is well suited to a versioned pointer and a digest referring to an operational profile held elsewhere. It is not suited to a longitudinal evidence history, and it should not be asked to become one. The namespaced extension pattern itself is familiar from interface description work, where optional vendor extensions carry no meaning until a separate schema defines them, and the same caveat applies here.\[11\]

On the protocol side, two versions matter in practice. The 2025-11-25 version is session-oriented. A client sends `initialize`, receives the negotiated protocol version, server identity and capabilities, and sends `notifications/initialized`. Tool listing is paginated, and `tools/call` takes a name and an optional arguments object. Tools may declare input and output schemas, and results may carry content, structured content and `isError`.\[7\]

The 2026-07-28 version is stateless at the protocol level. It removes `initialize` and `notifications/initialized`, removes the protocol-level session identifier, requires each request to carry the protocol version and client capabilities, and introduces `server/discover` for capability discovery. Listing gains cache metadata and deterministic-order guidance, calls support multi-round-trip input requirements, structured content may be any JSON value, and tasks moved to an opt-in extension.\[6\]

This has a direct bearing on the September dataset. The probe exercised the legacy handshake, so its results are evidence about an endpoint's behaviour on that legacy-era path. A server implementing only the current protocol could fail that path while being fully compatible with the specification that is current today. In this file, 975 records completed the legacy listing path, so protocol-era mismatch can affect at most the eleven listing failures and cannot explain the 316 records that listed and then failed the chosen call. Readiness evidence must still record the protocol era it exercised, or it will quietly misclassify some modern servers as unhealthy.

Two more boundaries matter for routing. First, `serverInfo` is self-reported and must not be treated as a verified security identity.\[6\] Second, tool annotations describing behaviour as read-only, destructive, idempotent or open-world are hints, and the specification says clients must treat them as untrusted unless the server itself is trusted.\[6\] Both are useful policy inputs from a party you have independently decided to trust. Neither is an enforceable contract.

What MCP does not define is equally clear: no universal availability indicator, no production objective, no standard pricing model, no universal quota, no fixed timeout, no universal retry algorithm, no health-weighted routing, no semantic equivalence relation between two publishers' tools, no service-quality certification and no contractual remedy. HTTP authorisation is handled by pointing at protected-resource metadata and OAuth discovery, and the choice among multiple authorisation servers is left to the client.\[6\]\[8\] Every one of those gaps is a place where a consumer-owned layer has to supply an answer.

## 6. A layered readiness model

Readiness should be modelled as a vector whose subject is fully qualified. The minimum subject is the endpoint, the tool, the server version, the protocol version, the schema digest, the principal and tenant, the region, the input class and the time. Any readiness claim that omits part of that subject is being asserted more broadly than its evidence supports.

The layers below are cumulative in the sense that a failure at a lower layer usually makes higher layers untestable, and independent in the sense that success at a lower layer never implies success above it.

| Layer | Question | Evidence required | Suggested freshness |
| --- | --- | --- | --- |
| 0. Registry presence | Is there an identifiable published candidate with a known publisher? | Registry record, publisher verification, record version and digest | On each catalogue sync; recheck within 24 hours before first enrolment |
| 1. Endpoint reachability | Can this consumer resolve, validate TLS identity for and connect to the endpoint? | DNS resolution, TLS identity, connection and HTTP evidence from a relevant region | Seconds to five minutes for routing decisions |
| 2. Protocol compatibility | Can client and server complete the intended MCP version and methods? | Discovery or legacy negotiation, required metadata, listing and pagination results | Per release or version change, otherwise within 24 hours |
| 3. Access readiness | Can this principal obtain and present the required authority for this tool? | Protected-resource metadata, issuer binding, token, scopes, tenant entitlement, consent and billing state | Evaluated at call time |
| 4. Invocation readiness | Can this tool accept this input class now? | Tool and schema digest, argument validation, quota state, circuit state, safe canary where available | Quota and circuit at call time; active evidence normally under five minutes |
| 5. Result validity | Is the returned result structurally valid? | JSON-RPC result type, `isError`, output-schema validation, content decoding | Every result |
| 6. Semantic usefulness | Is the result correct, relevant, fresh and complete enough for this task? | Deterministic validator, source checks, domain rules, task-specific evaluation | Every result where feasible; aggregates must reflect data drift |
| 7. Workflow contribution | Did the dependency help complete the user's objective? | End-state predicate, downstream state, user acceptance, workflow evaluator | Every workflow, plus a rolling aggregate |
| 8. Recoverability | Can the system recover without duplicate harm or semantic drift? | Idempotency and retry tests, fallback tests, circuit behaviour, compensation and fault-injection results | Circuit state in seconds; tests per release and periodically |

The non-equivalence chain is the operational content of the table:

```text
registry presence        != endpoint reachability
reachability             != protocol compatibility
protocol compatibility   != authorised access
authorised access        != valid invocation
valid invocation         != valid result
valid result             != useful result
useful result            != successful workflow
successful past workflow != recoverability now
```

Each link has a concrete counterexample. A record can point at a domain whose DNS has lapsed. A reachable endpoint can refuse a protocol version. A protocol-compatible endpoint can return 401 to this principal while serving another tenant perfectly. An authorised caller can still send an input class the tool rejects. A tool can accept an invocation and return malformed structured content. It can return schema-valid content that is six months stale. It can return a useful answer that arrives after the user has abandoned the task. And a workflow that succeeded an hour ago tells you nothing about whether a lost response to a non-idempotent call can be reconciled now.

The freshness column matters as much as the evidence column. Evidence has a half-life that varies by layer. Registry metadata changes slowly. Circuit state changes in seconds. Treating a two-hour-old reachability observation as current is a category error, and the practical rule is that expired evidence becomes unknown rather than healthy. Unknown is a usable state. It permits a cautious call with a tight deadline, a consumer-classified read-only canary, or a request for human confirmation. Silently treating unknown as healthy removes the caution.

## 7. Four artifacts instead of one score

Most existing readiness surfaces publish a score. A score is a compression of several different kinds of statement into one number, and the compression destroys exactly the information a consumer needs in order to decide whether to trust it. The alternative is four artifacts with a common subject identifier and explicit provenance.

### 7.1 Provider declaration

A provider declaration is controlled by the provider, may be signed, and states intent and configuration. It is a useful policy input from a party you have chosen to trust. It is never treated as observed truth, because a signature proves who made an assertion rather than that the assertion is true.

Useful fields include owner and operator identity, server and endpoint identifiers, supported protocol versions, authentication methods and authorisation servers, required scopes and tenant model, provider-declared side-effect class, human-confirmation requirements, idempotency semantics and key scope and retention, quota units and partition keys, regions and residency, recommended total and per-attempt timeouts, retryable conditions, pricing source and unit and currency, data handling and retention, deprecation dates, incident contacts, status page, and profile version with issue and expiry times.

```yaml
declaration:
  subject:
    server: com.example.invoices/invoices-mcp
    endpoint: https://mcp.example.com/mcp
    serverVersion: 4.2.1
  protocolVersions: ["2026-07-28", "2025-11-25"]
  auth:
    scheme: oauth2
    authorizationServers: ["https://auth.example.com"]
    requiredScopes: ["invoices.read", "invoices.write"]
    tenantModel: per-organisation
  tools:
    - name: get_invoice
      sideEffect: read-only
    - name: create_invoice
      sideEffect: state-changing
      idempotency:
        supported: true
        keyHeader: Idempotency-Key
        keyRetention: PT24H
      humanConfirmation: required-above-value
  residency: ["eu-west"]
  timeouts:
    recommendedTotal: PT8S
    perAttempt: PT4S
  profile:
    version: 3
    issuedAt: 2026-09-01T00:00:00Z
    expiresAt: 2026-12-01T00:00:00Z
```

### 7.2 Observed evidence

Observed evidence is produced by a named observer, is time-bounded, and describes a method as well as a result. It should record the observer identity and software version, the exact subject including server version and schema digest, the protocol version and path exercised, the observation region and network class, the authentication, tenant and principal classes, the measurement window, the sample size and the eligible denominator, the probe or traffic method, the input class, the success definitions used, the rates for each layer, a latency distribution rather than a single average, the error taxonomy, quota observations, manifest drift, freshness and expiry, coverage and known blind spots, and a digest of the underlying receipts.

```yaml
evidence:
  subject:
    endpoint: https://mcp.example.com/mcp
    tool: get_invoice
    schemaDigest: sha256:1b9d...
  observer:
    id: internal-canary
    software: canary/2.4.0
  method: synthetic
  authClass: service-principal
  tenantClass: internal-test
  region: eu-west-1
  protocolVersion: "2026-07-28"
  window:
    start: 2026-09-13T00:00:00Z
    end: 2026-09-14T00:00:00Z
  sample:
    attempted: 2880
    eligible: 2874
    excluded: {clientAbort: 6}
  rates:
    reach: 0.9997
    list: 0.9993
    invoke: 0.9961
    schemaValid: 0.9998
    semanticValid: 0.981
  latencyMs: {p50: 210, p90: 480, p95: 690, p99: 1840}
  freshness:
    observedAt: 2026-09-14T00:05:00Z
    expiresAt: 2026-09-14T00:20:00Z
  blindSpots: ["no coverage of write tools", "single region"]
```

The label on the method is not decoration. A keyless synthetic probe and authorised production traffic answer different questions, and mixing them in one rate produces a number that describes neither.

### 7.3 Consumer policy

Consumer policy is local. It belongs to the organisation or the user and should not be dictated by a public monitor, because the acceptable answer depends on what the organisation is doing, what it is liable for, and what it can tolerate.

It should state approved owners and endpoints, accepted evidence issuers, maximum evidence age by layer, minimum sample size and confidence, supported protocol versions, required authentication and issuer constraints, permitted scopes, consumer-assigned or consumer-ratified side-effect classes, human-approval rules, cost and quota ceilings, latency and deadline budgets, residency and data-classification rules, minimum semantic-validation level, retry conditions and attempt limits, idempotency requirements, fallback equivalence rules, circuit thresholds and incident-owner requirements. A provider's annotation can inform the classification. It cannot become the enforced classification without consumer review or independent validation.

```yaml
policy:
  version: 2026-09-01.3
  inventory: approved-mcp-catalogue
  acceptedEvidenceIssuers: ["internal-canary", "internal-passive"]
  maxEvidenceAge:
    reachability: PT5M
    protocolCompatibility: P1D
    invocation: PT5M
    semanticValidation: PT15M
  minSampleSize: 200
  protocolVersions: ["2026-07-28"]
  requiredAuth:
    scheme: oauth2
    issuers: ["https://auth.example.com"]
  sideEffectPolicy:
    assignmentSource: consumer-review
    permitted: ["read-only", "state-changing"]
  humanApproval:
    stateChanging: required
  residency: ["eu-west"]
  deadlineBudgetMs: 6000
  retry:
    consumerClassifiedReadOnly: {maxAttempts: 3}
    stateChanging: {requiresIdempotencyKey: true, maxAttempts: 1}
  fallback:
    equivalenceClass: invoice-lookup-eu
    requiresApproval: true
```

Hard filters run before ranking. Authority, side-effect class, residency and protocol compatibility are eligibility questions, and a candidate that fails them is removed rather than penalised.

### 7.4 Execution receipt

An execution receipt records one decision and one invocation. It should carry request and workflow identifiers, the candidate set considered, the evidence snapshots and policy version used, rejection reasons for excluded candidates, the selected endpoint and server version and tool and schema digest, the protocol version, the principal and tenant and region classes, the provider-declared and consumer-assigned side-effect classes and approval state, the deadline and timeout, the attempt count, the idempotency key or deduplication reference, timestamps and latency, transport and MCP status, `isError` state, schema-validation outcome, semantic-validation outcome, fallback or circuit action, actual cost and quota effect, the workflow outcome, a trace identifier and a redacted result or result digest.

Receipts should minimise sensitive data by default. Tokens, raw prompts and full tool output do not belong in routine telemetry, and a redaction test belongs in the conformance suite.

The value of the four artifacts is that a reader can ask which one a given statement came from. "P95 is 900 ms" is a declaration. "P95 was 1,827 ms over 659 successful probes from one region on one night" is evidence. "We will not use candidates whose P95 evidence is older than fifteen minutes" is policy. "We called this endpoint, it returned in 412 ms, the schema validated and the workflow completed" is a receipt. None of these is interchangeable with the others.

These structures are illustrative. They are written in the shape a working implementation would need, and they are not a standard, not a submission and not an interoperability profile that anyone else has agreed to.

## 8. Declared objectives, observed evidence and guarantees

Reliability vocabulary is already precise, and borrowing it loosely causes avoidable confusion. Site reliability practice distinguishes a service level indicator, which is a quantitative measure of a service level; a service level objective, which is a target value or range for that indicator; and a service level agreement, which is an explicit contract containing consequences for missing the objective.\[9\]

Those three sit in different columns of the same table as the artifacts above.

| Class | Example statement | What it establishes |
| --- | --- | --- |
| Provider declaration | "Our P95 target is 900 ms and retries are safe up to three attempts" | Intent, advice or configuration |
| Observed evidence | "P95 was 1,827 ms across 659 successful probes in one region on 14 September 2026" | What a named observer measured over a stated sample |
| Contractual guarantee | A service level agreement with a formula, exclusions, remedy and claims process | A commercially or legally enforceable undertaking |

This is why the phrase "SLO contract" should be avoided. An objective is a target. A contract is an agreement with consequences. A provider can publish an objective and miss it without breaching anything, and an independent observer can publish a measured indicator without creating any obligation on the provider. Collapsing the two invites a consumer to rely on something that carries no remedy.

OpenSLO is useful prior art here because it shows what a vendor-neutral declaration of objectives looks like: indicators, targets, time windows and error budgets expressed as data rather than as dashboard configuration.\[10\] It describes objectives and how to measure them. It does not, and does not claim to, tell a consumer what attainment was actually observed, which is precisely the artifact the routing layer needs.

Service-health practice supplies the rest of the prior art. Kubernetes separates readiness, which gates traffic, from liveness, which triggers restarts, and from startup probes, which gate both, and it is explicit that the meaning of each probe is defined by the application.\[12\] gRPC health checking gives a per-service serving state that clients use to gate traffic, and that state is provider-controlled.\[13\] Envoy combines active health checks with passive outlier detection, ejects failing hosts and re-admits them gradually with hysteresis.\[14\] Each of these has been load-bearing in production for years, and each of them assumes a homogeneous fleet under one operator's control. None judges whether two different publishers' tools mean the same thing.

## 9. Safe routing

Routing among candidates is where readiness data turns into action, and it is where a naive implementation does damage. Nine hazards deserve explicit policy.

Stale evidence. A healthy observation can expire before the next call. Deployments, DNS records, certificates, quotas and upstream dependencies change in seconds. Every evidence item needs an observation time, a window and an expiry, expired evidence must degrade to unknown, and any version or schema drift should invalidate tool-specific evidence rather than carrying it forward.

Correlated failures. Endpoints that look independent may share a cloud region, a model provider, an upstream API, a database, a DNS provider, a package, an operator or an OAuth issuer. Failing over among them may move no risk at all. Record operator and dependency classes where they are known, limit retries across correlated routes, and prefer failure-domain diversity over candidate count.

Non-idempotent retries. A timeout does not prove that the operation was not applied. HTTP semantics are explicit that a client should not automatically retry a non-idempotent request unless it knows the semantics are idempotent or knows the original request was not applied.\[15\] The same rule applies to MCP tools that create tickets, send messages or move money. Require verified idempotency semantics or a deduplication key before any automatic retry of a state-changing call, record the key's scope and retention, and use reconciliation or compensation when the outcome is ambiguous. The Idempotency-Key header draft is a reasonable design reference for the mechanics, while remaining an expired Internet-Draft rather than a standard.\[16\]

Semantic change under fallback. Two tools with similar names may differ in data source, jurisdiction, freshness, authority, account, update semantics, default filters, side effects, conflict resolution or units. Equivalence classes must be approved by the consumer, a model's similarity score is not sufficient evidence of equivalence, and any fallback that changes the authority of the answer or the side effects of the call needs explicit approval.

Self-reported spoofing. Signed provider metadata proves authorship. Tool annotations are hints the specification tells clients to treat as untrusted unless the server itself is trusted.\[6\] Keep declarations and observations in separate fields, weight independent evidence by method and coverage and freshness, and surface conflicts between declaration and observation instead of averaging them into a single figure.

Cold starts. A low-volume endpoint on scale-to-zero infrastructure can look slow or unavailable on a first call and be perfectly healthy thereafter, while a continuously warm synthetic canary can understate real user latency. Separate cold and warm distributions where the data allows, avoid optimising only the median, and preserve deadline-exceeded and tail-latency rates as first-class signals.

Authentication and tenant context. A keyless public probe says very little about OAuth users, enterprise tenants, user-specific scopes, delegated authority, paid plans or resource-specific consent. Evidence must be labelled by authentication class, success must not be transferred across principals or tenants without justification, and access readiness must be evaluated at call time rather than inherited from a catalogue.

Residency and privacy. A fast fallback can move data into an unauthorised region or a provider outside the approved processor list. Residency and data classification are hard filters, latency scoring must never override them, and the selected region belongs in the receipt.

Correctness over latency. The fastest answer may be stale, partial or unauthoritative. A defensible decision order is:

```text
1. eligibility
2. trust and authority
3. security and residency
4. semantic suitability
5. side-effect safety
6. current health
7. deadline and cost
8. latency optimisation
```

Latency belongs at the end of that list. It is the easiest property to measure and the least important to get right when the alternatives differ in authority.

One framing point underpins all nine. Routing begins from an approved organisational inventory. The candidate set is a list of dependencies an organisation has reviewed, contracted for where necessary, and accepted responsibility for. It is not an arbitrary set of public endpoints discovered at runtime. Everything in this section assumes that filter has already been applied, and none of it is a licence to let an agent select production dependencies from an open catalogue.

## 10. From tool-call success to workflow success

A tool call can succeed at several layers and still leave the user's objective unmet. Attributing failure to the correct layer is what makes the resulting evidence usable.

Transport. The connection was established, TLS identity validated, and bytes exchanged within the deadline. Failures here are network, DNS, certificate and capacity problems, and they are the only class that ordinary uptime monitoring detects reliably.

Protocol. The request and response conformed to the MCP version in use, capabilities matched, and the method existed. A modern-only server failing a legacy handshake is a protocol-era mismatch rather than an outage, which is exactly why the September probe's use of the legacy sequence has to be recorded alongside its results.\[7\]\[6\]

Access. The principal presented sufficient authority for this tool and tenant. A 401 with valid protected-resource metadata is an access failure inside a working endpoint, not an outage, and should remain separate from protocol and invocation results.\[8\]

Tool execution. The server routed the call to the tool and the tool ran. A result carrying `isError: true` is a tool-execution failure inside a successful protocol exchange, and the specification keeps that distinction deliberately so that the model can see the tool's own error.\[6\]

Schema validation. The result matched the declared output schema, structured content decoded, and required fields were present. This layer catches the common integration failure where a provider changes a field type and every downstream consumer silently degrades.

Semantic usefulness. The content was correct, relevant, fresh and complete enough for the task. This is the layer that infrastructure monitoring cannot reach, because correctness is defined by the task and not by the response code. A schema-valid price from a stale cache passes every earlier layer and fails here.

Workflow contribution. The dependency moved the user's objective forward. A tool can return a perfectly good answer that the agent then ignores, or return an answer so late that the plan has already branched. Recording whether the result was used is a different measurement from recording whether it was valid.

Recoverability. When something fails, the system can recover without duplicate harm or a silent change in the meaning of the answer.

Research supports the separation while stopping short of the operational layer. Work on agent reliability separates consistency, robustness, predictability and safety, and evaluates agents under injected faults including timeouts, rate limits, server errors, network failures and malformed responses.\[19\] That is laboratory evaluation under controlled faults rather than longitudinal evidence about particular endpoints, and the authors do not present it as the latter. Dynamic tool selection research optimises retrieval accuracy, candidate loading and context efficiency, and treats tool descriptions as static.\[20\]\[21\]\[23\] Tool-use benchmarks measure correctness, policy adherence and multi-step completion in controlled environments, including some with real execution failures.\[22\]\[24\]\[25\] Fault-focused benchmarks distinguish transient from permanent failures and reward replanning over blind retry, which is close to the recoverability layer, while remaining a synthetic fault graph rather than live service evidence.\[26\]

Taken together, this literature establishes that the layers are real and separately measurable. It does not supply persistent per-endpoint evidence, provenance for that evidence, or a consumer-owned routing policy, and none of those papers claims to.

## 11. A practical operating model

The model below is deliberately mundane. Most of it is work an experienced integration team already does by hand, written down so that a runtime can do it consistently and so that the reasoning survives in a receipt.

Pre-selection. Start from the approved organisational inventory. Resolve the requested capability into a consumer-defined equivalence class rather than a name match. Verify owner, endpoint, protocol version and schema digest against the record you enrolled. Apply hard policy for authority, scopes, side effects, residency, cost and evidence freshness. Remove candidates with open circuits or incompatible protocol versions. Rank what remains using fresh, context-matched observations. Preserve every rejection and ranking reason, because a decision you cannot explain later is a decision you cannot review.

Pre-call. Confirm token issuer, audience, scopes, tenant and expiry against policy rather than assuming a cached token still applies. Check current quota and local budget, using rate-limit hints where a provider supplies them while remembering that hints reserve nothing.\[17\] Calculate one end-to-end deadline for the whole operation and derive per-attempt timeouts from it. Decide in advance whether retry or fallback is safe for this specific tool. Allocate or reuse an idempotency key where the provider supports one. Obtain human confirmation where the side-effect class requires it. Bind the call to the exact tool and schema digest you evaluated.

During the call. Enforce the total deadline and the per-attempt timeout. Avoid retry amplification across layers, which is the mechanism by which one slow dependency becomes an outage. Respect `Retry-After` and other server pushback.\[15\] Do not hedge state-changing calls. Record the endpoint and protocol version actually used, since a redirect or a load-balanced pool can change either. Cancel abandoned work where the protocol supports it. Treat a timeout that occurred after the request was sent as an ambiguous outcome rather than a failure.

Post-call. Distinguish HTTP status, JSON-RPC status and tool-execution status. Check `isError`. Validate the output schema. Apply semantic and freshness checks appropriate to the task. Confirm intended side effects where an inexpensive confirmation exists. Attribute the failure to the correct layer, since misattribution poisons every aggregate that follows. Update passive evidence and circuit state. Emit a redacted receipt.

Workflow level. Evaluate the final user-visible end state rather than the last tool result. Record whether the dependency actually contributed. Detect divergence introduced by a fallback, particularly in units, jurisdiction and freshness. Reconcile ambiguous side effects rather than leaving them for a customer to discover. Track recovery cost and attempt counts as a first-class metric, because a system that always recovers expensively is failing quietly. Feed results into rolling evidence only when the denominator and context are compatible. Assign incident ownership to a named team, including for third-party dependencies.

Telemetry can carry much of this. The OpenTelemetry semantic conventions for MCP define attributes for method, protocol version, duration, status and tool-call details, which is the natural transport for evidence and receipts in an organisation that already runs tracing. They carry development status at the time of writing, and telemetry is a record of what happened rather than a routing policy or a cryptographic assurance.\[27\]

## 12. Indicators and denominators

Every rate needs a named denominator and an eligibility rule. A rate without those is a number that cannot be compared with anything, including its own value last week.

Discovery and compatibility: registry-record freshness, endpoint-resolution success rate, TLS identity-validation rate, protocol-version compatibility rate, complete-listing rate, pagination-completion rate and schema-drift rate. DNS-based service discovery has always distinguished presence and weight from health, and the same caution applies to registry records.\[18\]

Access: authorisation-metadata discovery rate, token-acquisition success rate, scope-sufficiency rate, tenant-entitlement success rate and billing-readiness rate. Each of these is a per-principal measure, and aggregating them across principals hides the failures that matter most.

Invocation: call completion rate segmented by tool, input class and authentication class; deadline-exceeded rate; rate-limit rate; tool-level `isError` rate; and ambiguous-outcome rate. The last of these is usually missing from dashboards and is the one that predicts duplicate side effects.

Result: output-schema-valid rate, non-empty-result rate where a non-empty result is expected, semantic-validation rate, freshness-compliance rate and authoritative-source rate.

Workflow: workflow completion rate, tool contribution rate, recovery success rate, fallback divergence rate, compensation rate, human-escalation rate, cost per successful workflow and latency per successful workflow.

Evidence quality: evidence age, sample size, coverage by region and authentication class, observer diversity, version-match rate and unknown-state rate. An organisation whose unknown-state rate is rising is losing the ability to make the decisions this model describes, regardless of what its health percentages say.

A production availability indicator should be derived from repeated eligible requests representing the intended user population over a defined window.\[9\] One keyless call per endpoint, taken once, is not such an indicator, and the September dataset should never be cited as one.

## 13. Conformance and resilience tests

A readiness layer that has not been tested against deliberately hostile behaviour will fail in the way its designers did not imagine. The following matrix is a starting set, executable against a test double that can be instructed to misbehave.

| Phase | Test | Expected behaviour |
| --- | --- | --- |
| Profile | Validate profile schema and version | Unknown fields handled per versioning rules |
| Provenance | Alter a signed declaration or observation | Signature or digest verification fails |
| Freshness | Supply expired health evidence | Candidate becomes unknown or ineligible |
| Identity | Redirect to an endpoint with the wrong TLS identity | Candidate rejected |
| Protocol | Exercise both the 2025-11-25 and 2026-07-28 paths | Supported era recorded explicitly |
| Listing | Return a paginated tool list | Client follows pagination or records partial coverage |
| Access | Return 401 with valid protected-resource metadata | Classified as access-not-ready, not endpoint-down |
| Access | Return 401 with an issuer mismatch | Candidate rejected |
| Arguments | Reject an empty-argument call | Classified as invocation-not-ready, not unavailable |
| Result | Return HTTP 200 carrying a JSON-RPC error | Protocol failure recorded correctly |
| Result | Return HTTP 200 carrying `isError: true` | Tool-execution failure recorded correctly |
| Schema | Return malformed structured content | Result-invalid, with no downstream use of the payload |
| Semantic | Return schema-valid but stale or irrelevant data | Semantic validation fails |
| Timeout | Apply the effect, then withhold the response | Ambiguous outcome, no unsafe automatic retry |
| Idempotency | Repeat the same key and payload | Prior result or documented duplicate behaviour |
| Idempotency | Reuse a key with a different payload | Request rejected |
| Rate limit | Return 429 with `Retry-After` | Backoff honoured without a synchronised retry storm |
| Retry | Return a transient 5xx for a read-only tool | Bounded retry or safe fallback |
| Fallback | Substitute a semantically different provider | Blocked unless explicitly permitted by policy |
| Circuit | Produce repeated live failures | Circuit opens with hysteresis |
| Recovery | Return a healthy canary after ejection | Gradual re-entry rather than immediate full load |
| Residency | Make the only fast candidate violate a region rule | Candidate remains ineligible |
| Receipt | Include a secret token in emitted telemetry | Redaction test fails the implementation |
| Workflow | Tool succeeds while the final objective fails | No false workflow-success attribution |

Two of these tests are worth singling out. The ambiguous-timeout case is the one most likely to cause real customer harm, because the failure is invisible until a duplicate appears somewhere downstream. The residency case is the one most likely to be quietly defeated by a well-meaning optimisation, because the violating candidate is by construction the attractive one.

## 14. The strongest counterargument

The honest case against this paper is strong enough to state at full strength.

It adds complexity. Four artifacts, nine layers, provenance, freshness windows and receipts are a great deal of machinery to place in front of a call that often works. Teams that struggle to maintain a status page will not maintain an evidence store.

Evidence goes stale immediately. The window in which an observation predicts the next call is short, sometimes shorter than the time required to fetch and evaluate it. A system can spend more effort establishing readiness than the call itself costs.

Samples are small. Sparse probing produces wide confidence intervals, and small numerators move percentages around in ways that look like signal. The September dataset is an extreme example: one observation per endpoint supports no rate over time at all.

Publisher burden is real. Asking providers to maintain declarations covering idempotency, residency, quota partitions and deprecation dates is asking for work that many small publishers will not do, and partial adoption produces a catalogue where the careful publishers look worse than the silent ones.

Self-reported metadata can mislead. Declarations describe intent, tool annotations are explicitly untrusted hints, and a provider with an incentive to appear reliable can say whatever it likes.\[6\]

Objective bureaucracy is a genuine hazard. Organisations that adopt formal objectives without the discipline to act on them end up with dashboards that nobody uses and a monthly meeting that changes nothing. Reliability practice has warned about exactly this outcome for a decade.\[9\]

Equivalence is uncertain. The claim that two tools are interchangeable is hard to verify and easy to get wrong, and the failure mode is silent: the workflow completes with a different meaning.

Routing instability is a risk that the routing layer itself creates. Health-weighted selection can oscillate, synchronise retries across clients and turn a degraded dependency into an outage. Passive ejection with hysteresis exists because the naive version of this idea misbehaves.\[14\]

Latency cost is direct. Policy evaluation, evidence lookup, token checks and schema binding all sit on the request path, and an agent workflow that makes twenty tool calls pays that cost twenty times.

And the largest objection: most production integrations are wired by engineers who already know their dependencies. They chose the provider, read the contract, obtained the credentials, tuned the timeout and wrote the fallback. They do not need a public readiness layer, and adding one would give them nothing they do not already hold in their code and their runbooks.

The proportionate answer accepts most of this and narrows the claim.

The model is worth its cost in three situations. The first is runtime selection, where software rather than a person picks the dependency and no human judgement is present at the moment of choice. The second is multi-principal and multi-tenant use, where the same tool behaves differently for different callers and a single global health figure is guaranteed to be wrong for someone. The third is accountability, where the organisation must later explain why a particular dependency was used for a particular piece of work, which is a receipt problem rather than a monitoring problem.

Outside those three situations, the correct implementation is a subset. A team with three carefully integrated dependencies can keep discovery static while still checking protocol compatibility, access, invocation, result validity, semantic usefulness and recoverability, and keeping receipts for consequential calls. The layered model is a vocabulary for deciding what to leave out as much as a specification for what to build.

On staleness and small samples, the answer is to state uncertainty rather than hide it. Unknown is a legitimate readiness state, and a policy that says what to do when evidence is unknown is more useful than a percentage computed from six observations.

On publisher burden, the answer is that declarations are optional inputs and absence is not a penalty. A consumer whose policy rewards declarations over observations has built the system backwards.

On routing instability and latency, the answer is that most decisions are cacheable for the life of a workflow, hard filters are cheap, and hysteresis and jitter are established mitigations rather than open research questions.\[14\]

## 15. What this paper does not claim

MCP is not deficient for omitting service level objectives. A protocol that specified operator error budgets would be exceeding its remit, and the separation of concerns here is correct.

The Official MCP Registry is not intended as a certification authority, and nothing in this paper asks it to become one. Its documentation states plainly that it makes no quality judgement and provides no uptime guarantee, and treating that as a gap to be closed by the Registry itself would misread its design.\[3\]\[4\]

The September sample is not every MCP server. It is 986 records from one operator's synced catalogue, filtered to remote Streamable HTTP endpoints that its logic classified as keyless, observed once.\[2\]

Call failures in that sample are not downtime. A 401, a 402, an argument rejection and a tool-level error each describe a specific outcome, and several of them are evidence that the endpoint was working.

One call is not availability. Availability requires repeated eligible requests over a defined window from a population that represents intended use.\[9\]

The measured latency is one vantage point, in one short window, mixing warm and cold paths, under concurrency generated by the observer. It is not a user-experienced latency distribution.

Declared objectives are not proof of attainment. A published target and a measured result are different classes of statement, and only the second is evidence.\[10\]

Semantic equivalence cannot be inferred from model similarity alone. Two tools that describe themselves identically can differ in source, jurisdiction, freshness and side effects, and equivalence classes have to be approved by the consumer.

Dynamic routing is not always desirable. A single well-understood dependency with a contract and a named owner is frequently the better engineering choice, and this paper does not argue otherwise.

No novelty is claimed for the general observation that service discovery is not service health. That distinction is decades old in service infrastructure.\[12\]\[13\]\[14\] Several operators are already working in this specific space. AgentStatus publishes a layered methodology separating reach, protocol negotiation, catalogue listing, invocation and functional outcome, with a 30-day window, P95 latency, sample-size shrinkage and explicit modern-versus-legacy protocol evidence.\[28\] MCP Queen describes an observation pipeline, an evidence store, probe history, grades and trust receipts; those receipts attest to its observation pipeline rather than to a consumer's routing decision and workflow outcome.\[29\] MCPLookup separates provenance, maintenance, safety, adoption and coverage, and states explicitly that sparse observations are not continuous uptime while labelling authentication-gated surfaces as unverifiable.\[30\] Each is a direct operational competitor to any claim that layered readiness is new.

Policy and gateway work is also established. ToolHive, IBM ContextForge and Microsoft MCP Gateway combine various forms of curated inventory, identity, routing, retries, telemetry and lifecycle management, while Open Policy Agent is a mature general-purpose consumer-owned policy engine.\[32\]\[33\] Those systems do not provide one portable separation of provider declaration, observed evidence, consumer policy and execution receipt over the fully qualified readiness subject used here. The contribution is that composition and its review model, not the discovery of monitoring or policy enforcement.

Public endpoints are not automatically appropriate production dependencies. Presence in a catalogue, a green indicator and a fast response together establish far less than a procurement review, and the routing model in this paper begins after that review rather than replacing it.

## Conclusion

MCP made tools discoverable and callable across an ecosystem that did not previously have a common way to do either. The remaining work sits above the protocol and belongs to the consumer.

A production agent needs to know whether a specific tool, at a specific version, for a specific principal and tenant, in a specific region, for a specific class of input, is ready now. That question is answered by evidence with provenance and freshness, filtered by policy the consumer owns, and recorded in a receipt that connects the decision to the outcome. Keeping provider declaration, observed evidence, consumer policy and execution receipt as four separate artifacts is what makes the answer auditable, and collapsing them into a score is what makes it unusable.

The September probe data is a useful illustration precisely because of how narrow it is. One keyless call per endpoint, taken once, from one vantage point, on a legacy protocol path, produced a large and genuine gap between catalogue presence and call completion. The gap is informative. The temptation to describe it as availability is the error this paper exists to prevent.

## Appendix A: Agent tool readiness profile template

The template holds four artifacts under one subject identifier. Every field group carries provenance and freshness. An absent field is recorded as unknown rather than as a pass.

```text
# Subject
  subject id
  server name and registry record version
  endpoint URI
  server version
  tool name
  tool input and output schema digests
  protocol versions applicable
  principal class, tenant class, region, input class
  time of assertion

# Artifact 1: Provider declaration
  Provenance
    issuer identity and verification method
    signature algorithm and key reference
    declaration version, issuedAt, expiresAt
    source URI and retrieval digest
  Content
    owner and operating entity
    supported protocol versions
    authentication methods and authorisation servers
    required scopes and tenant model
    provider-declared side-effect class per tool
    human-confirmation requirements
    idempotency semantics, key scope and key retention
    quota units and partition keys
    regions and data residency
    recommended total and per-attempt timeouts
    retryable conditions
    pricing source, unit, currency and effective interval
    data handling, retention and sub-processors
    deprecation and end-of-life dates
    support and incident contacts, status page URI

# Artifact 2: Observed evidence
  Provenance
    observer identity and software version
    independence statement relative to the provider
    method: synthetic, passive production, or mixed
    protocol version and path exercised
    observation region and network class
    authentication class, tenant class, principal class
    signature or attestation over the evidence record
  Freshness
    window start and end
    observedAt and expiresAt
    supersedes: prior evidence identifier
  Content
    per-rate sample size, eligible denominator and exclusion reasons
    success definition used at each layer
    reach, list, invoke, schema-valid, semantic-valid rates
    latency distribution at p50, p90, p95, p99
    error taxonomy with counts
    quota and rate-limit observations
    manifest and schema drift observed
    coverage statement and known blind spots
    confidence calculation method
    digest of underlying receipts or traces

# Artifact 3: Consumer policy
  Provenance
    owning organisation and policy owner
    policy version and effective dates
    approval record reference
  Content
    approved owners, endpoints and inventory reference
    accepted evidence issuers and required independence
    maximum evidence age per readiness layer and minimum sample size
    minimum confidence level
    supported protocol versions
    required authentication scheme and permitted issuers
    permitted scopes
    consumer-assigned side-effect class and assignment evidence
    provider-declared side-effect class retained separately
    human-approval rules by value and reversibility
    maximum cost and permitted quota consumption
    latency and end-to-end deadline budgets
    residency and data-classification rules
    minimum semantic-validation level per input class
    retry conditions, attempt limits, idempotency requirements
    fallback equivalence classes and approval requirements
    circuit-opening and re-entry thresholds
    named incident owner per dependency

# Artifact 4: Execution receipt
  Provenance
    receipt identifier, emitter identity, emitter version
    redaction policy version applied
    emittedAt
  Content
    request identifier and workflow identifier
    candidate set considered
    evidence snapshot identifiers used
    policy version applied
    rejection reason per excluded candidate
    selected endpoint, server version, tool, schema digest
    protocol version actually used
    principal class, tenant class, region
    provider-declared and consumer-assigned side-effect classes
    approval state
    deadline, per-attempt timeout, attempt count
    idempotency key reference or deduplication reference
    start time, end time, measured latency
    transport status, JSON-RPC status, isError state
    output-schema validation outcome
    semantic validation outcome and validator version
    fallback or circuit action taken
    actual cost and quota effect
    workflow outcome and contribution flag
    trace identifier
    redacted result or result digest
```

## Appendix B: Routing, retry and dependency review checklist

Inventory and enrolment

- Is every callable dependency in an approved inventory with a named owner?
- Is the registry record version and endpoint recorded at enrolment?
- Is publisher verification recorded separately from any operational claim?
- Is the supported protocol era recorded for each endpoint?
- Are tool and schema digests captured, and is drift detected?
- Is there a documented review for adding a public endpoint as a dependency?

Evidence

- Does every evidence record carry an observer identity, method and region?
- Is the authentication class of the evidence labelled?
- Are synthetic and production observations kept in separate series?
- Does every rate state its denominator and eligibility rule?
- Does every evidence item carry an observation time and an expiry?
- Does expired evidence become unknown rather than healthy?
- Is unknown a state your policy has an answer for?
- Is evidence invalidated when the server version or schema digest changes?

Policy

- Is policy owned by the consuming organisation and version-controlled?
- Do hard filters run before any ranking?
- Are residency and data-classification rules enforced as hard filters?
- Are permitted side-effect classes stated per tool rather than per server?
- Who assigned each side-effect class, and is it recorded separately from the provider's declaration?
- Is maximum evidence age set per layer rather than globally?
- Are accepted evidence issuers listed explicitly?
- Is there a minimum sample size below which a candidate is unknown?

Access

- Is token issuer, audience, scope, tenant and expiry checked before each call?
- Is a 401 classified as access-not-ready rather than endpoint-down?
- Is an issuer mismatch treated as a rejection rather than a retryable error?
- Is billing or quota state checked where a provider exposes it?

Invocation and retry

- Is there one end-to-end deadline from which per-attempt timeouts derive?
- Is retry safety decided per tool rather than per server?
- Is automatic retry of state-changing calls blocked without an idempotency key?
- Is a timeout after send treated as ambiguous rather than failed?
- Is `Retry-After` honoured, with jitter to avoid synchronised retries?
- Is retry amplification across layers bounded and tested?
- Are state-changing calls excluded from hedging?

Fallback

- Are equivalence classes approved by a human and version-controlled?
- Is a fallback that changes authority, jurisdiction or units blocked by default?
- Is fallback divergence measured after the fact?
- Are correlated dependencies identified so failover moves real risk?

Results

- Are transport, protocol and tool-execution statuses recorded separately?
- Is `isError` checked on every result?
- Is the output schema validated before the result is used?
- Are semantic and freshness checks defined for each consequential input class?
- Is failure attributed to the correct layer before it enters any aggregate?

Receipts and review

- Is a receipt emitted for every consequential call?
- Does it record rejected candidates and the reason for each?
- Does it record the policy version and evidence snapshots used?
- Is redaction tested, including for tokens and tool output?
- Can a reviewer reconstruct a decision months later from receipts alone?
- Is there a named incident owner for every third-party dependency?
- Are the conformance tests in section 13 run against the live system after changes?

## Appendix C: Probe reproduction note

Artifact

```text
filename:       mcp-probe-2026-09-14.csv
sha256:         4e84191c8feda3276fb9493f9f0b34644a90b88c634ca0a99b381c0e0b2475f7
retrieved:      14 September 2026
rows:           986 data rows plus one header row
columns:        server,title,url,website,tools,list_ok,call_ok,list_ms,
                call_ms,probed_tool,probed_at,streak
upstream:       https://cracked.ai/datasets/mcp-probe.csv
```

Cracked's datasets page, retrieved on 14 September 2026, states that the file is available under the Creative Commons Attribution 4.0 International licence, with attribution to Cracked.\[1\]\[31\] The upstream file is regenerated after each nightly probe, so the copy stored here is identified by digest rather than by URL. The frozen copy is available at [./mcp-probe-2026-09-14.csv](./mcp-probe-2026-09-14.csv) and the analysis script at [./analyze_probe.py](./analyze_probe.py).

Reproduction

The analysis requires Python 3, uses only the standard library, reads the CSV from its own directory, and verifies the digest and the column header before calculating anything. From the directory containing both files:

```text
python analyze_probe.py
```

The digest can be checked independently with the standard library alone:

```text
python -c "import hashlib,sys;print(hashlib.sha256(open(sys.argv[1],'rb').read()).hexdigest())" mcp-probe-2026-09-14.csv
```

The script exits with a non-zero status and an explanatory message if the file is missing, if the digest differs, or if the column header differs.

Reproducible from the frozen file

986 records; 986 unique server names and endpoint URLs; 975 records with `list_ok = true`, a rate of 98.884 per cent; 659 records with `call_ok = true`, a rate of 66.836 per cent over all records and 67.590 per cent over the 975 listed records; 316 records that listed and then did not complete the chosen call; 327 records in which the chosen call did not complete; the probe date 2026-09-14 with first timestamp 09:23:21Z, last timestamp 09:25:04Z and a span of 103 seconds; median successful listing 280 ms over 975 observations; median successful call 356 ms over 659 observations; nearest-rank P95 successful call 1,827 ms and linearly interpolated P95 1,741.5 ms using the N-minus-one convention; 87 successful calls at or above one second; fastest successful call 60 ms and slowest 17,888 ms; the seven latency bands of 201, 222, 149, 59, 19, 6 and 3; 11 records with `streak` of three or more, comprising four at three, two at five and five at thirteen; `tools` column sum 12,055 with a maximum of 100, thirteen records at 100, median six, 39 records with one tool, 333 records above ten tools and 45 records in the 51-to-100 band; 13 records with no `probed_tool`, of which two listed successfully; 675 distinct probed tool names; 180 blank `website` values; four blank `list_ms` values; and 16 blank `call_ms` values.

Report assertions not reproducible from this file

The published report's failure taxonomy, including counts of authentication and payment walls, argument rejections and other tool errors; its category analysis and per-category rates; its uncapped catalogue statistics, including a total tool count above the file's sum, a largest catalogue above 100 tools and a count of servers above 100 tools; its exact population definition and exclusion decisions; and the exact arguments used for each call. These rest on data that is not present in the twelve exported columns or on separately published, mutable per-server records. This paper treats them as report assertions and does not cite them as measured facts.\[1\]

Limitations

One observation per endpoint, gathered inside a 103-second window from one undisclosed vantage point with substantial apparent concurrency. The effect of that concurrency on latency is unknown. The probe path used the legacy `initialize` and `notifications/initialized` sequence rather than the current stateless protocol, so results are evidence about that legacy-era path.\[7\]\[6\] The chosen call was one heuristically selected tool invoked without meaningful arguments under a 20-second timeout, with 12-second timeouts on setup and listing.\[2\] No protocol version, HTTP status, error text, `isError` state, argument set, tenant context or raw response is preserved. The sample is one operator's synced catalogue of keyless remote Streamable HTTP endpoints and is not a representative sample of MCP servers. Nothing in this file supports an availability figure, a service level objective, a statement that any server was unavailable or broken, or a conclusion about any server's behaviour under authorised production use.

## About the author

Jason Doyle writes about reliable software, observability, incident leadership, applied AI, and practical controls for systems that influence human and organisational decisions. He publishes at [jasondoyle.ie](https://jasondoyle.ie) and can be contacted at [contact@jasondoyle.ie](mailto:contact@jasondoyle.ie).

## References

1. Cracked Engineering, *The state of public MCP servers, September 2026*, with
   the public probe export and datasets licence page, report published
   2 September 2026 and figures revised through 14 September 2026, accessed
   14 September 2026,
   [https://cracked.ai/reports/state-of-mcp-servers-2026-09](https://cracked.ai/reports/state-of-mcp-servers-2026-09)
   and
   [https://cracked.ai/datasets/mcp-probe.csv](https://cracked.ai/datasets/mcp-probe.csv)
   and
   [https://cracked.ai/datasets](https://cracked.ai/datasets).
   The export is operator-published, served from a rolling URL, and omits error
   text, failure classes and category labels while capping the tool count column.
2. Cracked Engineering, *Methodology*, probe section, accessed 14 September 2026,
   [https://cracked.ai/methodology](https://cracked.ai/methodology). Documents
   the probe sequence, the 12-second setup and listing timeouts, the 20-second
   call timeout and the dead-streak rule. The named implementation files are not
   published, and the tool-selection and argument heuristics are not specified.
3. Model Context Protocol project, Official MCP Registry design principles,
   ecosystem vision and API documentation, living documentation, accessed
   14 September 2026,
   [https://github.com/modelcontextprotocol/registry/blob/main/docs/design/design-principles.md](https://github.com/modelcontextprotocol/registry/blob/main/docs/design/design-principles.md)
   and
   [https://github.com/modelcontextprotocol/registry/blob/main/docs/design/ecosystem-vision.md](https://github.com/modelcontextprotocol/registry/blob/main/docs/design/ecosystem-vision.md)
   and
   [https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/official-registry-api.md](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/official-registry-api.md).
   The Registry is a metadata and discovery service; its documentation is living
   and the service carries preview status.
4. Model Context Protocol project, *Registry aggregators*, living documentation,
   accessed 14 September 2026,
   [https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/registry-aggregators.mdx](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/registry-aggregators.mdx).
   Describes downstream persistence and enrichment and states that no uptime or
   durability guarantee is provided. It describes an intended ecosystem rather
   than the quality of any actual aggregator.
5. Model Context Protocol project, *Official registry requirements for
   `server.json`* and *Authentication*, living documentation, accessed
   14 September 2026,
   [https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/server-json/official-registry-requirements.md](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/server-json/official-registry-requirements.md)
   and
   [https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/authentication.mdx](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/authentication.mdx).
   Namespace control and package linkage do not verify runtime behaviour.
6. Model Context Protocol, specification version 2026-07-28, including the tools
   and authorization sections, 28 July 2026,
   [https://modelcontextprotocol.io/specification/2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28).
   Deployed servers may support older versions unevenly.
7. Model Context Protocol, specification version 2025-11-25, including lifecycle
   and tools, 25 November 2025,
   [https://modelcontextprotocol.io/specification/2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25).
   Superseded as the current version and still widely deployed.
8. Michael B. Jones, Phil Hunt and Aaron Parecki, *RFC 9728: OAuth 2.0 Protected
   Resource Metadata*, IETF, April 2025,
   [https://www.rfc-editor.org/rfc/rfc9728](https://www.rfc-editor.org/rfc/rfc9728).
   Declares access configuration rather than health or entitlement.
9. Chris Jones, John Wilkes, Niall Murphy and Cody Smith, *Service Level
   Objectives*, and Marc Alvidrez, *Embracing Risk*, in *Site Reliability
   Engineering*, Google, 2016,
   [https://sre.google/sre-book/service-level-objectives/](https://sre.google/sre-book/service-level-objectives/)
   and
   [https://sre.google/sre-book/embracing-risk/](https://sre.google/sre-book/embracing-risk/).
   Organisational guidance rather than a machine-readable schema.
10. OpenSLO, *OpenSLO specification*, accessed 14 September 2026,
    [https://github.com/OpenSLO/OpenSLO](https://github.com/OpenSLO/OpenSLO).
    Expresses objectives, indicators, windows and error budgets as data; it does
    not record observed attainment.
11. OpenAPI Initiative, *OpenAPI Specification v3.2.0*, specification extensions
    section, 19 September 2025,
    [https://spec.openapis.org/oas/v3.2.0.html](https://spec.openapis.org/oas/v3.2.0.html).
    Namespaced extension support is optional and carries no meaning without a
    separate schema.
12. Kubernetes, *Configure liveness, readiness and startup probes*, living
    documentation, accessed 14 September 2026,
    [https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
    Probe meaning is application-defined and may be shallow.
13. gRPC project, *Health checking*, updated 20 May 2024,
    [https://grpc.io/docs/guides/health-checking/](https://grpc.io/docs/guides/health-checking/).
    Serving state is provider-controlled and is not independent evidence.
14. Envoy project, *Health checking* and *Outlier detection*, living
    documentation, accessed 14 September 2026,
    [https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/health_checking](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/health_checking)
    and
    [https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/outlier](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/outlier).
    Protocol-agnostic and unable to judge semantic equivalence.
15. Roy T. Fielding, Mark Nottingham and Julian Reschke, editors, *RFC 9110:
    HTTP Semantics*, IETF, June 2022,
    [https://www.rfc-editor.org/rfc/rfc9110.html](https://www.rfc-editor.org/rfc/rfc9110.html).
    HTTP method semantics do not automatically describe MCP tool effects.
16. Jayadeba Jena and Sanjay Dalal, *The Idempotency-Key HTTP Header Field*,
    IETF Internet-Draft, revision 7, 15 October 2025,
    [https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/](https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/).
    An Internet-Draft rather than a published RFC at the time of writing.
17. Roberto Polli, Alejandro Martinez Ruiz and Darrel Miller, *RateLimit header
    fields for HTTP*, IETF Internet-Draft, 23 May 2026,
    [https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/](https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/).
    Work in progress; hints do not reserve capacity or guarantee acceptance.
18. Arnt Gulbrandsen, Paul Vixie and Levon Esibov, *RFC 2782: A DNS RR for
    specifying the location of services*, IETF, February 2000, and Ben Schwartz,
    Mike Bishop and Erik Nygren, *RFC 9460: Service Binding and Parameter
    Specification via the DNS*, IETF, November 2023,
    [https://www.rfc-editor.org/rfc/rfc2782](https://www.rfc-editor.org/rfc/rfc2782)
    and
    [https://www.rfc-editor.org/rfc/rfc9460](https://www.rfc-editor.org/rfc/rfc9460).
    DNS presence and weight are not current health evidence.
19. Stephan Rabanser et al., *Towards a Science of AI Agent Reliability*,
    arXiv:2602.16666, 18 February 2026, revised 2 June 2026, ICML 2026,
    [https://arxiv.org/abs/2602.16666](https://arxiv.org/abs/2602.16666).
    Controlled fault injection in a laboratory setting rather than longitudinal
    endpoint evidence.
20. Gaurav et al., *Dynamic ReAct: Scalable tool selection for large-scale MCP
    environments*, arXiv:2509.20386, 22 September 2025,
    [https://arxiv.org/abs/2509.20386](https://arxiv.org/abs/2509.20386).
    Optimises retrieval accuracy and context size, not service health.
21. Xiang Fei, Xiawu Zheng and Hao Feng, *MCP-Zero: Active tool discovery for
    autonomous LLM agents*, arXiv:2506.01056, 1 June 2025, revised 24 June 2025,
    [https://arxiv.org/abs/2506.01056](https://arxiv.org/abs/2506.01056).
    Treats tool descriptions as static and leaves endpoint health outside its
    evaluation.
22. Shiyi Fan, Ding Ding, Yuhao Zhang and Yuchen Mo, *MCPToolBench++: A large
    scale AI agent model context protocol MCP tool use benchmark*,
    arXiv:2508.07575, 11 August 2025,
    [https://arxiv.org/abs/2508.07575](https://arxiv.org/abs/2508.07575).
    Includes real execution failures; does not produce persistent endpoint
    profiles or a routing policy.
23. Yao et al., *ACE-Router*, originally published as ToolACE-MCP,
    arXiv:2601.08276, 13 January 2026, renamed 19 April 2026,
    [https://arxiv.org/abs/2601.08276](https://arxiv.org/abs/2601.08276).
    History-aware semantic routing over the current trajectory rather than
    persistent endpoint history.
24. Shunyu Yao, Noah Shinn, Pedram Razavi and Karthik Narasimhan, *tau-bench: A
    benchmark for tool-agent-user interaction in real-world domains*,
    arXiv:2406.12045, 17 June 2024, ICLR 2025,
    [https://arxiv.org/abs/2406.12045](https://arxiv.org/abs/2406.12045).
    Simulated tools in two domains.
25. Jiarui Lu et al., *ToolSandbox: A stateful, conversational, interactive
    evaluation benchmark for LLM tool use capabilities*, Findings of NAACL 2025,
    [https://aclanthology.org/2025.findings-naacl.65/](https://aclanthology.org/2025.findings-naacl.65/).
    A benchmark environment rather than endpoint operations.
26. Zhu et al., *ToolMaze: When tools fail*, arXiv:2606.05806, 4 June 2026,
    [https://arxiv.org/abs/2606.05806](https://arxiv.org/abs/2606.05806).
    Distinguishes transient and permanent tool faults using a synthetic fault
    graph rather than live service evidence.
27. OpenTelemetry, *Semantic conventions for Model Context Protocol*,
    development status, accessed 14 September 2026,
    [https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/mcp.md](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/mcp.md).
    Development status; telemetry is a record rather than a routing policy or a
    cryptographic assurance.
28. Carmel Labs, *AgentStatus public MCP methodology*, accessed 14 September
    2026,
    [https://agentstatus.dev/mcp-methodology](https://agentstatus.dev/mcp-methodology).
    Operator-defined composite scoring; safe public probing cannot exercise
    authenticated or state-changing contracts.
29. MCP Queen, *Architecture*, accessed 14 September 2026,
    [https://mcpqueen.com/architecture](https://mcpqueen.com/architecture).
    Operator-published and not an interoperable routing standard.
30. Fano Holdings, *MCPLookup methodology*, accessed 14 September 2026,
    [https://mcplookup.com/methodology](https://mcplookup.com/methodology).
    Score weights are private, and the operator states that sparse checks are
    not continuous uptime.
31. Creative Commons, *Attribution 4.0 International (CC BY 4.0) legal code*,
    accessed 14 September 2026,
    [https://creativecommons.org/licenses/by/4.0/legalcode](https://creativecommons.org/licenses/by/4.0/legalcode).
    Governs reuse of the probe export cited in reference 1.
32. Stacklok, *ToolHive*; IBM, *ContextForge*; and Microsoft, *MCP Gateway*,
    project documentation accessed 14 September 2026,
    [https://github.com/stacklok/toolhive](https://github.com/stacklok/toolhive),
    [https://github.com/IBM/mcp-context-forge](https://github.com/IBM/mcp-context-forge)
    and
    [https://github.com/microsoft/mcp-gateway](https://github.com/microsoft/mcp-gateway).
    These projects combine different subsets of curated inventory, identity,
    routing, retries, telemetry and lifecycle management; none is evidence that
    every deployment implements the full model described here.
33. Open Policy Agent, *Documentation*, accessed 14 September 2026,
    [https://www.openpolicyagent.org/docs](https://www.openpolicyagent.org/docs).
    A mature general-purpose policy engine rather than an MCP-specific
    readiness or evidence specification.