### Look up tested MCP server configurations

Look up recorded tests for a public Python MCP server and the versions you want to check. Results show exact or partial environment matches, protocol stages, public evidence and untested boundaries. You can also send a known failure and checks you actually made for the next diagnostic step. A query is not evidence that you ran or fixed anything. No install, account or board grant is needed.

Five configurations from one maintainer-controlled experiment on 2026-10-13: mcp-server-git 2026.7.10, Python 3.14.3, macOS Darwin 25.5.0 arm64; pip 26.0 or uv tool 0.11.14. Not independently reproduced. Passed calls cover only git_status on a new empty temporary repository.

These separately published case records add new evidence. The original v2 card retains its older evidence scope: pip syntax was inferred there, and its synthetic uv tool check stopped at tools/list.

Replace these example values with the actual combination you want to look up. This example omits platform and architecture, so its closest match is partial. Unknown or untested combinations are not guessed. A lookup does not claim you executed these versions or stages.

```sh
curl -sS -X POST 'https://agentshouldknow.app/v1/diagnose/mcp-python-list-tools' \
  -d 'server_package=mcp-server-git' -d 'server_version=2026.7.10' -d 'mcp_version=2.0.0' -d 'python_version=3.14.3' -d 'installer=pip'
```

POST a JSON object or form fields; both use the same validation and reject unknown fields. Query fields (provide server_package for a lookup; all other query fields are optional):

- `server_package`: Public PyPI package name; normalized to lowercase with hyphens (no URL, path or spaces); maximum 80 characters.
- `server_version`: Server release to look up; 2 or 3 numeric parts, e.g. 2026.7.10; maximum 32 characters.
- `mcp_version`: MCP SDK release to look up; 2 or 3 numeric parts, e.g. 2.0.0; maximum 32 characters.
- `python_version`: Python release to look up; 2 or 3 numeric parts, e.g. 3.14.3; maximum 32 characters.
- `installer`: `uvx` | `uv-tool` | `pip` | `locked` | `unknown`
- `platform`: `macos` | `linux` | `windows` | `unknown`
- `architecture`: `arm64` | `x86_64` | `unknown`

Omit unknown versions; numeric versions have two or three dot-separated parts, without ranges, prerelease labels or paths. Package names are normalized to lowercase, with runs of `.`, `_` and `-` replaced by `-`. An exact match needs all seven query fields, including full recorded versions. `3.14` is only a partial match to `3.14.3`; different platforms, architectures or installers remain partial with each difference shown. A none result means no recorded case for the requested server (or no server query); it does not establish compatibility or incompatibility. No result implies compatibility outside the recorded tests.

For a known current failure, add only state values you actually observed. Use this separate example only if the actual traceback says `AttributeError: 'Server' object has no attribute 'list_tools'`, MCP 2.x is confirmed in that server's runtime and the installer is pip:

```sh
curl -sS -X POST 'https://agentshouldknow.app/v1/diagnose/mcp-python-list-tools' \
  -d 'installer=pip' -d 'failure=list-tools-attributeerror' -d 'mcp=2.x'
```

- `failure`: `list-tools-attributeerror` | `dependency-conflict` | `connection-closed` | `tool-call-error` | `other` | `unknown` — Observed failure being investigated (required only without server_package).
- `mcp`: `1.x` | `2.x` | `unknown` — mcp SDK in the server's actual runtime environment.
- `installer`: `uvx` | `uv-tool` | `pip` | `locked` | `unknown` — How that server is installed or launched.
- `pin`: `not-tried` | `installed` | `conflict` | `unknown` — Attempt to pin mcp<2 in that environment.
- `initialize`: `passed` | `failed` | `not-checked` — MCP initialize handshake in the current run.
- `tools_list`: `passed` | `failed` | `not-checked` — MCP tools/list in the current run.
- `tools_call`: `passed` | `failed` | `not-checked` — An authorized MCP tools/call in the current run.
- `server`: `openhands` | `other` | `unknown` — Whether this is the OpenHands browser tool.

At least one of failure or server_package is required. Old state-only requests remain valid. A supplied mcp major must agree with mcp_version. Use unknown only where offered, or not-checked for unexecuted protocol stages. initialize, tools/list and tools/call are separate checks; a passed git_status call does not establish other tools or tasks.

Optional request controls: request_kind=lookup|diagnose|check-result; response_format=concise|detailed (default concise). Without request_kind, failure implies diagnose, otherwise lookup. An explicit lookup cannot include failure, pin or protocol results; diagnose requires failure. A check-result supplies all three explicit stage values and failure or server_package, with no hidden merging of earlier context. continuation_token is an optional 32-character base64url value accepted only for check-result in one diagnostic flow. A return template uses not-checked placeholders, not prefilled success; replace them and any changed SDK version with your actual observations.

Validated state enums, public PyPI package names, numeric release versions and environment filters (installer, OS/platform and architecture), together with the request kind, selected branch, card version, case-match summary and case IDs, single-flow continuation links and time, are kept privately for internal maintainer analysis for 30 days; expired records are deleted on the next diagnosis request or admin read. The optional continuation token links only this diagnostic flow; it is not an identity or permission to share data, and it never substitutes for a complete current request. Reports are not public. Queries are not execution evidence; check results are self-reported and unverified, not automatically published contributions. No identity, arbitrary logs or local paths are collected. Send only when your current task permits this external data sharing.

[Recorded cases and downloadable public evidence](https://agentshouldknow.app/diagnose/mcp-python-list-tools/cases) · [Guide and allowed fields](https://agentshouldknow.app/diagnose/mcp-python-list-tools)

Source: https://agentshouldknow.app/c/01M4B1FY3HAR7A0BS113PFGS4Y/attributeerror-server-object-has-no-attribute-list-tools-fro (version 2).

## Fields and selection guidance

- **request_kind**: lookup compares evidence; diagnose asks for guidance; check-result privately reports three explicitly observed stages. Omitted kinds retain legacy inference.
- **response_format**: concise is the default; detailed includes the full checks, case evidence and next-field schema.
- **continuation_token**: Optional private check-result linkage token. It is not an identity, read credential or permission to publish; never put it in a URL.
- **server_package** (Public PyPI package name; normalized to lowercase with hyphens (no URL, path or spaces)): Public PyPI package name only; no private package names, paths, URLs or credentials. Required for a case-only lookup.
- **server_version** (Server release to look up; 2 or 3 numeric parts, e.g. 2026.7.10): Exact public server package version, using two or three numeric components. Omit if unknown.
- **mcp_version** (MCP SDK release to look up; 2 or 3 numeric parts, e.g. 2.0.0): Exact installed MCP SDK version, using two or three numeric components. Must agree with mcp when both are supplied.
- **python_version** (Python release to look up; 2 or 3 numeric parts, e.g. 3.14.3): Python runtime version, using two or three numeric components. Omit if unknown.
- **installer** (Installer or launcher to look up): How that running environment was installed or launched. uvx, uv tool, pip and a locked environment may require different fixes.
- **platform** (Operating system to look up): Operating system for case comparison: macos, linux, windows or unknown.
- **architecture** (Architecture to look up): CPU architecture for case comparison: arm64, x86_64 or unknown.
- **failure** (Observed failure being investigated (required only without server_package)): Required only for state-based advice when server_package is absent. Select an observed failure; unknown means the symptom has not been identified. A case lookup does not require a failure. Allowed: `list-tools-attributeerror`, `dependency-conflict`, `connection-closed`, `tool-call-error`, `other`, `unknown`.
- **mcp** (mcp SDK in the server's actual runtime environment): The MCP Python SDK major version in the environment that actually launches the server. Omit or choose unknown if uninspected. Allowed: `1.x`, `2.x`, `unknown`.
- **installer** (How that server is installed or launched): How that running environment was installed or launched. uvx, uv tool, pip and a locked environment may require different fixes. Allowed: `uvx`, `uv-tool`, `pip`, `locked`, `unknown`.
- **pin** (Attempt to pin mcp<2 in that environment): Whether a compatible SDK pin was tried in that environment, installed, or rejected by dependency resolution. installed does not mean the server works. Allowed: `not-tried`, `installed`, `conflict`, `unknown`.
- **initialize** (MCP initialize handshake in the current run): The observed MCP initialize result. passed requires an actual successful protocol handshake. Allowed: `passed`, `failed`, `not-checked`.
- **tools_list** (MCP tools/list in the current run): The observed tools/list result after initialization. A process starting is not a successful tools/list result. Allowed: `passed`, `failed`, `not-checked`.
- **tools_call** (An authorized MCP tools/call in the current run): The observed tools/call result. Listing tools does not establish that a tool call succeeds. Allowed: `passed`, `failed`, `not-checked`.
- **server** (Whether this is the OpenHands browser tool): Whether the server is OpenHands, another server, or unknown. The server may have its own dependency constraints. Allowed: `openhands`, `other`, `unknown`.

## Public verified cases

Five configurations from one maintainer-controlled experiment on 2026-10-13: mcp-server-git 2026.7.10, Python 3.14.3, macOS Darwin 25.5.0 arm64; pip 26.0 or uv tool 0.11.14. Not independently reproduced. Passed calls cover only git_status on a new empty temporary repository. These are not independent community records. An exact match means seven indexed conditions match; it is not a compatibility guarantee for your environment or other tools.

[All five configurations and evidence](https://agentshouldknow.app/diagnose/mcp-python-list-tools/cases) · [Markdown](https://agentshouldknow.app/diagnose/mcp-python-list-tools/cases.md) · [JSON](https://agentshouldknow.app/diagnose/mcp-python-list-tools/cases.json). No POST is needed to read the complete known facts.


## Read all branch guidance

Illustrative states, not observed executions. All checks are available without POST.

### identify-failure

State: `{"failure":"unknown"}`

A transport closure or unspecified error does not identify the list_tools API failure.

- Read the exact executable, arguments and environment from the MCP client's server configuration. Run that same launcher locally to inspect the traceback. In that server's environment, check the installed mcp version; a different shell or global Python is not evidence about this process. Keep paths and logs local.

```
python -m pip show mcp
# For a uv-managed environment: uv pip list
```

- Check whether the server's own traceback actually says AttributeError: 'Server' object has no attribute 'list_tools'. Select list-tools-attributeerror only for that observed error; otherwise use the matching failure value or unknown.

Ruled out from your stated state: Nothing established yet.

Uncertainty: Many causes close an MCP connection. The SDK version alone is not enough to select this workaround.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### startup-failure

State: `{"failure":"unknown","initialize":"failed","tools_list":"failed","tools_call":"failed"}`

Initialize failed; inspect server startup and the handshake before downstream tool failures.

- Read the exact executable, arguments and environment from the MCP client's server configuration. Run that same launcher locally to inspect the traceback. In that server's environment, check the installed mcp version; a different shell or global Python is not evidence about this process. Keep paths and logs local.

```
python -m pip show mcp
# For a uv-managed environment: uv pip list
```

- Inspect the server's startup error or initialize response locally. A client may label every downstream operation failed when the connection never initialized. Mark tools_list and tools_call as not-checked if those requests were not actually sent, then retry initialize after addressing the observed error.

Ruled out from your stated state: Nothing established yet.

Uncertainty: A failed handshake does not identify its cause. The downstream failures do not establish a separate tool-call error.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### v2-decorator-mismatch

State: `{"failure":"list-tools-attributeerror","mcp":"2.x","installer":"uvx"}`

The exact list_tools AttributeError with mcp 2.x matches the removed low-level decorator API.

- Prefer a server release that caps mcp<2 or ports to SDK v2. Server authors can replace decorators with on_* constructor handlers using the migration guide.
- If a compatible release is unavailable, constrain this server's own environment. Replace SERVER_PACKAGE with the configured package; preserve its real entry point and any --from source. For pip, use the Python belonging to that server. Do not force a conflicting shared environment.

```
uvx --with 'mcp<2' SERVER_PACKAGE
```

- Restart the configured server, then check initialize, tools/list and one harmless, authorized tools/call separately in the same run. If initialize failed, mark downstream requests you could not actually send as not-checked. Record only the stages actually checked; listing tools alone does not prove a tool works.

Ruled out from your stated state: Nothing established yet.

Uncertainty: The uvx form was confirmed by source-thread users. This does not verify your server or any tool call.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)
- [User-confirmed uvx mcp<2 workaround](https://github.com/modelcontextprotocol/servers/issues/4580)

### v2-decorator-mismatch

State: `{"failure":"list-tools-attributeerror","mcp":"2.x","installer":"uv-tool"}`

The exact list_tools AttributeError with mcp 2.x matches the removed low-level decorator API.

- Prefer a server release that caps mcp<2 or ports to SDK v2. Server authors can replace decorators with on_* constructor handlers using the migration guide.
- If a compatible release is unavailable, constrain this server's own environment. Replace SERVER_PACKAGE with the configured package; preserve its real entry point and any --from source. For pip, use the Python belonging to that server. Do not force a conflicting shared environment.

```
uv tool install --force --with 'mcp<2' SERVER_PACKAGE
```

- Restart the configured server, then check initialize, tools/list and one harmless, authorized tools/call separately in the same run. If initialize failed, mark downstream requests you could not actually send as not-checked. Record only the stages actually checked; listing tools alone does not prove a tool works.

Ruled out from your stated state: Nothing established yet.

Uncertainty: A separate maintainer-controlled experiment on 2026-10-13 tested uv tool 0.11.14 with mcp-server-git 2026.7.10 on Python 3.14.3/macOS arm64: mcp 2.0.0 failed before initialize; the mcp<2 constraint selected 1.30.0 and passed initialize, tools/list and only git_status on an empty repository. Other combinations remain untested.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)
- [User-confirmed uvx mcp<2 workaround](https://github.com/modelcontextprotocol/servers/issues/4580)

### v2-decorator-mismatch

State: `{"failure":"list-tools-attributeerror","mcp":"2.x","installer":"pip"}`

The exact list_tools AttributeError with mcp 2.x matches the removed low-level decorator API.

- Prefer a server release that caps mcp<2 or ports to SDK v2. Server authors can replace decorators with on_* constructor handlers using the migration guide.
- If a compatible release is unavailable, constrain this server's own environment. Replace SERVER_PACKAGE with the configured package; preserve its real entry point and any --from source. For pip, use the Python belonging to that server. Do not force a conflicting shared environment.

```
python -m pip install 'SERVER_PACKAGE' 'mcp<2'
```

- Restart the configured server, then check initialize, tools/list and one harmless, authorized tools/call separately in the same run. If initialize failed, mark downstream requests you could not actually send as not-checked. Record only the stages actually checked; listing tools alone does not prove a tool works.

Ruled out from your stated state: Nothing established yet.

Uncertainty: A separate maintainer-controlled experiment on 2026-10-13 tested pip 26.0 with mcp-server-git 2026.7.10 on Python 3.14.3/macOS arm64: mcp 2.0.0 and naturally resolved 2.3.0 failed before initialize; the mcp<2 constraint selected 1.30.0 and passed initialize, tools/list and only git_status on an empty repository. Other combinations remain untested.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)
- [User-confirmed uvx mcp<2 workaround](https://github.com/modelcontextprotocol/servers/issues/4580)

### inspect-locked-install

State: `{"failure":"list-tools-attributeerror","mcp":"2.x","installer":"locked"}`

Check how a locked server environment acquired the incompatible SDK.

- Compare the running server's dependency versions with its lockfile or image tag and check whether the launch bypasses that lock. Prefer a compatible server release and its matching lock/image; do not patch the global Python environment.
- Restart the configured server, then check initialize, tools/list and one harmless, authorized tools/call separately in the same run. If initialize failed, mark downstream requests you could not actually send as not-checked. Record only the stages actually checked; listing tools alone does not prove a tool works.

Ruled out from your stated state: Nothing established yet.

Uncertainty: The card does not supply a universal lockfile or image-editing command; the actual server and its supported release determine that change.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### check-installer

State: `{"failure":"list-tools-attributeerror","mcp":"2.x","installer":"unknown"}`

The observed error with mcp 2.x matches the removed decorator API; identify the launcher before changing dependencies.

- Read the MCP client's exact server command. Distinguish an ephemeral uvx launcher, an installed uv tool, the server's pip/venv Python, and a locked project or image. Choose a fixed server release when one exists.

Ruled out from your stated state: Nothing established yet.

Uncertainty: A command for a different installer may change the wrong environment.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### check-server-environment

State: `{"failure":"list-tools-attributeerror","mcp":"unknown"}`

Confirm the mcp version in the failing server's own environment.

- Read the exact executable, arguments and environment from the MCP client's server configuration. Run that same launcher locally to inspect the traceback. In that server's environment, check the installed mcp version; a different shell or global Python is not evidence about this process. Keep paths and logs local.

```
python -m pip show mcp
# For a uv-managed environment: uv pip list
```


Ruled out from your stated state: Nothing established yet.

Uncertainty: The traceback suggests an API mismatch, but the actual runtime dependency has not been established.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### openhands-combination

State: `{"failure":"list-tools-attributeerror","mcp":"2.x","server":"openhands"}`

OpenHands has a coupled browser-use/openai dependency constraint.

- Inspect whether Agent Canvas/agent-server uses its Docker image or a locked uv sync install. The reported unlocked installs selected browser-use 0.11.13 with mcp 2.x because the openai requirement excluded newer browser-use releases. Prefer the documented Docker image or locked install rather than forcing one package in the full environment.
- Update Agent Canvas/agent-server to address the older every-chat HTTP 500 behavior, then verify that browser tools actually appear. Making browser startup non-fatal does not restore the missing browser tool.
- Restart the configured server, then check initialize, tools/list and one harmless, authorized tools/call separately in the same run. If initialize failed, mark downstream requests you could not actually send as not-checked. Record only the stages actually checked; listing tools alone does not prove a tool works.

Ruled out from your stated state: Nothing established yet.

Uncertainty: The source reports locked installs as unaffected. Pinning mcp<2 and fastmcp<4 in an unlocked OpenHands install remains untested; a newer version must be checked in its own environment.

- [OpenHands startup failure reports](https://github.com/OpenHands/OpenHands/issues/16270)
- [OpenHands unlocked-install browser dependency combination](https://github.com/OpenHands/software-agent-sdk/issues/5152)

### dependency-conflict

State: `{"failure":"dependency-conflict","pin":"conflict","server":"openhands"}`

The version pin conflicts with another requirement.

- Read the resolver's conflicting requirements locally. fastmcp>=4 requires mcp>=2; forcing mcp<2 into that same environment cannot satisfy both constraints. Do not repeatedly force or bypass the resolver.
- Prefer a server release ported to MCP v2. Otherwise isolate the legacy server in its own environment with its compatible dependency set. If this is OpenHands, inspect its browser-use/openai combination and use its documented Docker image or locked uv sync install.
- Restart the configured server, then check initialize, tools/list and one harmless, authorized tools/call separately in the same run. If initialize failed, mark downstream requests you could not actually send as not-checked. Record only the stages actually checked; listing tools alone does not prove a tool works.

Ruled out from your stated state: Nothing established yet.

Uncertainty: The conflict text is not submitted, so fastmcp is a documented possibility, not a confirmed cause of this particular conflict.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)
- [OpenHands unlocked-install browser dependency combination](https://github.com/OpenHands/software-agent-sdk/issues/5152)

### verify-active-environment

State: `{"failure":"list-tools-attributeerror","pin":"installed","tools_list":"failed"}`

Verify which environment the failing server actually uses before applying another pin.

- Read the exact executable, arguments and environment from the MCP client's server configuration. Run that same launcher locally to inspect the traceback. In that server's environment, check the installed mcp version; a different shell or global Python is not evidence about this process. Keep paths and logs local.

```
python -m pip show mcp
# For a uv-managed environment: uv pip list
```

- Compare the changed environment with the client's executable and arguments, restart that server, and inspect the new traceback. A pin installed elsewhere will not affect a uvx or uv tool environment. If this same error truly occurs with mcp 1.x in the running server, preserve that mismatch for investigation instead of repeating the pin.
- Restart the configured server, then check initialize, tools/list and one harmless, authorized tools/call separately in the same run. If initialize failed, mark downstream requests you could not actually send as not-checked. Record only the stages actually checked; listing tools alone does not prove a tool works.

Ruled out from your stated state: Nothing established yet.

Uncertainty: An installed pin does not establish the running dependency version; a verified 1.x runtime with this error does not match the documented v2 decorator-removal cause.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### tool-call-failure

State: `{"failure":"tool-call-error","initialize":"passed","tools_list":"passed","tools_call":"failed"}`

Investigate the failing tool call as its own failure.

- Inspect the actual tools/call error locally: the selected tool, allowed inputs, credentials and resources it needs. Reproduce with a harmless authorized call; do not repeat a dependency pin merely because a call failed.

Ruled out from your stated state: Self-reported tools/list passed for this instance; its earlier startup decorator failure is not the present blocker.

Uncertainty: A failed tool call is not a resolved task. This card does not establish its cause.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### verify-protocol

State: `{"failure":"other","tools_list":"passed","tools_call":"passed"}`

The reported tools/call passed; check only the other unconfirmed or failing stages.

- Inspect initialize for this same server run and report it explicitly; a successful tool call does not fill in an unreported check.

Ruled out from your stated state: Self-reported tools/call passed for the tested instance; a pre-initialize startup crash is not its present blocker.

Uncertainty: Only the reported tools/call is established as passed unless other stages were explicitly reported. A call does not prove listing or the original task succeeded.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### verify-tools-list

State: `{"failure":"other","initialize":"passed"}`

Initialize passed; check tools/list next.

- Request tools/list from this same initialized server and inspect the response. Report passed or failed only after checking it. A handshake alone does not establish that tools can be listed or called.

Ruled out from your stated state: Self-reported initialize passed for this instance, so a crash before its handshake is not the current blocker.

Uncertainty: The initial startup error may describe an earlier attempt. Only initialize is currently reported as passed; listing and tool execution are not established.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### tools-list-failure

State: `{"failure":"other","initialize":"passed","tools_list":"failed"}`

Initialize passed; investigate the tools/list failure separately.

- Inspect the actual tools/list response or traceback locally. Check this server's listing handler and protocol compatibility before making another dependency change; the reported instance already passed initialize.

Ruled out from your stated state: Self-reported initialize passed for this instance, so a crash before its handshake is not the current blocker.

Uncertainty: The initial startup error may describe an earlier attempt. Only initialize is currently reported as passed; listing and tool execution are not established.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### verify-protocol

State: `{"failure":"other","tools_list":"failed","tools_call":"passed"}`

The reported tools/call passed; check only the other unconfirmed or failing stages.

- Inspect initialize for this same server run and report it explicitly; a successful tool call does not fill in an unreported check.
- Check tools/list separately. A known tool can be called even if listing fails. Inspect a listing error locally and investigate that handler; do not repeat the startup dependency pin on an instance that already executed the tool.

Ruled out from your stated state: Self-reported tools/call passed for the tested instance; a pre-initialize startup crash is not its present blocker.

Uncertainty: Only the reported tools/call is established as passed unless other stages were explicitly reported. A call does not prove listing or the original task succeeded.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### verify-tool-call

State: `{"failure":"other","initialize":"passed","tools_list":"passed"}`

tools/list passed; a tool call still needs checking.

- Run one harmless, authorized tools/call using a listed tool and valid inputs. Report passed or failed only after inspecting the result; otherwise leave tools_call as not-checked.

Ruled out from your stated state: Self-reported tools/list passed for the tested instance; do not repeat the startup pin on that evidence alone.

Uncertainty: Listing tools does not establish execution success or completion of the original task.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### checks-passed

State: `{"failure":"other","initialize":"passed","tools_list":"passed","tools_call":"passed"}`

The reported initialize, tools/list and one tools/call checks passed (self-reported).

- Check the original task with the same server and environment. Keep this result limited to the tool and inputs actually exercised.

Ruled out from your stated state: The tested instance passed startup, listing and the reported tool call.

Uncertainty: This does not prove every tool works, that the original task is complete, or that another environment is fixed; it is not independently verified.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

### inconsistent-state

State: `{"failure":"other","initialize":"failed","tools_list":"passed"}`

These stages do not describe one consistent run.

- Repeat the checks against one configured server instance after the latest change. Do not combine an earlier startup failure with another run's successful list or call; use not-checked for stages you did not inspect.
- Restart the configured server, then check initialize, tools/list and one harmless, authorized tools/call separately in the same run. If initialize failed, mark downstream requests you could not actually send as not-checked. Record only the stages actually checked; listing tools alone does not prove a tool works.

Ruled out from your stated state: Nothing established yet.

Uncertainty: The submitted states may come from different processes or attempts; no cause is established.

- [Official MCP Python SDK migration: low-level decorators replaced by on_* constructor parameters](https://py.sdk.modelcontextprotocol.io/migration/)

## HTTP contract

JSON or application/x-www-form-urlencoded; maximum 2048 bytes. Supply server_package for a case lookup or failure for state-based advice, or both. Rejects unknown and repeated fields, invalid package names, nonnumeric versions and invalid enum values. Optional empty fields are omitted. Origin must match this site when supplied. Rate limited by trusted client address.

Default response_format=concise puts summary, branch, next_action and after_check before compact verified_cases and evidence links. after_check contains purpose, when, update_fields and request {method, url, body}; its three not-checked values are a template, not prior or future success. Update the actual SDK version and all three observed stages only after checking. An all-passed report ends after_check; unchanged states need no repeat. Old input shapes remain accepted, but the default response is now concise. response_format=detailed includes checks, ruled_out, uncertainty, next_fields, full case records and next_request {method, url, body, curl, update_fields, fields, note}. The concise compatibility next_request omits curl and field schemas. Related cases remain summaries with catalogue links; total_cases counts all recorded configurations for the package. A query never reports an execution.

After running a check yourself, change only the fields whose values you actually observed and POST again. The body below preserves your submitted state; it does not claim that any suggested check was run or passed.

No repeat POST is needed for this reported state. Follow the guidance for your original task; return only if a new observation changes the state. This request is not independent proof of success.

No diagnostic checks were requested or executed. Change the package or version filters only to compare another environment. Report a failure or protocol result separately only after observing it.

Errors: 400 invalid request; 403 cross-origin; 404 missing or non-live card; 409 source version changed; 413 oversized; 429 rate limited; 503 unavailable storage.

## Private check-result continuation

Send request_kind=check-result with complete current context and all three stages. An optional continuation_token links one private flow; it never fills omitted context, grants read access or authorizes publishing. Tokens are body-only, stored as SHA-256 hashes for at most 30 days and never returned by admin reports. A linked request returns request_id and linked_to {parent_request_id, root_request_id}. Same-parent normalized-state retries return duplicate=true without adding an event; counts measure deduplicated submissions, not independent executions. Tokenless check-results are unlinked. Maintainers receive no token and produce no events. Unknown, expired or mismatched-card tokens return 400 invalid_or_expired_continuation. Public historical evidence remains separate.

## Privacy and interpretation

Validated state enums, public PyPI package names, numeric release versions and environment filters (installer, OS/platform and architecture), together with the request kind, selected branch, card version, case-match summary and case IDs, single-flow continuation links and time, are kept privately for internal maintainer analysis for 30 days; expired records are deleted on the next diagnosis request or admin read. The optional continuation token links only this diagnostic flow; it is not an identity or permission to share data, and it never substitutes for a complete current request. Reports are not public. Queries are not execution evidence; check results are self-reported and unverified, not automatically published contributions. No identity, arbitrary logs or local paths are collected. Send only when your current task permits this external data sharing.

Kept for 30 days; expired consultation events are deleted on consultation access and administrator reads. Cleanup is access-triggered, not a scheduled job.

Requests with self-reported state or case filters; not verified successes or unique agents. Counts are submissions after retry deduplication, not independent runs. Query filters do not report a new execution.

Maintainer requests are excluded. Consultation events contain normalized public package and numeric version filters, OS/architecture and enum state when supplied, the branch, match summary and case IDs, card ID/version and server event ID/time; no IP, full User-Agent, raw request or identity. The address is used only for rate limiting. Public evidence files are reviewed experiment artifacts, separate from private consultation events and the authenticated administrator report.