Check if an MCP server changed its tools: signed history, per-server coverage, offline proofs.
Scored across 5 tools
Each tool has a distinct key principle (registry id summary, global checkpoint, per-server history, offline bundle verification, URL-based live check), and descriptions clearly spell these out. However, check_mcp_server and get_server_changes both take a registry id and return history-derived data, and check_mcp_server vs verify_mcp_server both 'check a server' — an agent must read carefully to pick the right one.
All five tools follow a strict verb_noun snake_case pattern (check_, get_, verify_ + resource). The verb choice is semantically meaningful and consistent across the set.
Five tools is well-scoped for a verification/attestation service: summary, checkpoint, history, offline bundle verification, and URL check. Each tool covers a distinct step in the transparency-log workflow with no filler.
The surface covers the core lifecycle: fetch signed checkpoint, retrieve per-server history, generate/verify evidence bundles offline, and do a live URL comparison. Minor gaps remain, e.g. no way to enumerate or search servers in the log, no bulk/global change feed, and no explicit keyring retrieval tool separate from the bundle.
One-call summary for an MCP server registry id (e.g. "ai.alphaquantlabs/propertycheck"): tool-list fingerprint history observed by LEGION, last change, per-server coverage from the signed COVERAGE_V1 register (COMPLETE only if observed in every register cycle, UNKNOWN if partial), proof references and a command that verifies everything offline. Read-only. Unknown id -> state UNKNOWN (absence from the log is not a verdict). A change is not an attack; this log does not certify that a server is secure.
| Name | Required | Description | Default |
|---|---|---|---|
| server_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and open-world behavior, but the description adds substantial behavioral context: unknown ids resolve to UNKNOWN, absence from the log is not a verdict, coverage is COMPLETE only when observed in every cycle, and the log does not certify security. These disclosures go well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then packs in constraints and caveats efficiently. It is somewhat dense and runs as a single paragraph, but every clause appears to add useful information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description enumerates the expected return contents and explains key result semantics (COMPLETE vs UNKNOWN, unknown id behavior, non-certification). Given the annotations and single simple parameter, an agent has enough context to call and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It identifies the parameter as an MCP server registry id and supplies a concrete example format ('ai.alphaquantlabs/propertycheck'), which is useful. It does not describe validation rules or alternate id forms, so it is not complete enough for a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'One-call summary for an MCP server registry id.' It then enumerates the concrete contents of that summary (fingerprint history, last change, coverage, proof references, verification command), making the tool's purpose very clear. It does not explicitly name or differentiate itself from sibling tools like verify_mcp_server or get_server_changes, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'One-call summary for an MCP server registry id' and the read-only nature, but there is no explicit guidance on when to use this versus siblings such as get_server_changes or verify_mcp_server. The caveat about unknown ids adds useful context but not alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest signed tree head of the LEGION MCP transparency log. The signature is checked against the keyring,
anchored on the pinned root key fingerprint. Read-only. Returns tree_size, root_sha256, timestamp, signer and
signature_valid. For a trustless check, verify it yourself (see how_to_verify_yourself).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds meaningful behavior beyond that: the signature is validated against a keyring anchored on a pinned root fingerprint, and it enumerates the returned fields. It omits failure behavior (e.g., what happens on signature mismatch).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with what the checkpoint is, followed by trust anchoring and the verification alternative. Every sentence carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description compensates by naming the return fields (tree_size, root_sha256, timestamp, signer, signature_valid). For a zero-parameter read-only tool with full annotation coverage, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool applies. No misleading or missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('latest signed tree head of the LEGION MCP transparency log') and what is done with it (signature checked against keyring, anchored on pinned root fingerprint). It is readily distinguishable from the verify_*/check_* siblings, which perform verification rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when this is useful (obtaining a checkpoint for trustless verification) and explicitly routes the agent to `how_to_verify_yourself` for that follow-up. It does not, however, state when-not to use it or contrast against the verify_*/check_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Signed tool-list history of one MCP server as observed by LEGION (registry id, e.g. "xyz.signomy/civitae"),
newest first, at most limit (1-50) changes, plus an evidence bundle for the latest record (record + RFC 9162
inclusion proof + signed tree head + keyring) that verify_evidence_bundle checks offline.
A change is not a fault; history = what LEGION observed, not what other clients see.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| server_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly/idempotent/non-destructive/open-world, which already cover the safety profile), the description discloses ordering (newest first), the returned evidence bundle composition (record + RFC 9162 inclusion proof + signed tree head + keyring), and a semantic caveat about what 'history' means. That is meaningful added context for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, and the parenthetical detail on the evidence bundle is dense but information-bearing. It is a single long run-on paragraph rather than structured lines, so it is efficient but not maximally scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the return-value burden and does so (changes list plus evidence bundle), and annotations cover safety. Only minor gaps remain, such as whether repeated calls can page beyond the limit and how server_id relates to the inputs of the sibling verification tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it largely does: `limit` is bounded explicitly as 1-50 with newest-first truncation semantics, and server_id is illustrated with a concrete registry-id example establishing its format. It doesn't explain optionality/default behavior (limit defaults to 10) explicitly, keeping it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Signed tool-list history of one MCP server'), the source of truth (LEGION), the identifier format for server_id ('xyz.signomy/civitae'), ordering (newest first), and scope cap (1-50). It distinguishes itself from sibling verify_evidence_bundle by positioning that tool as the downstream verifier of the bundle this one returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear interpretive context ('A change is not a fault; history = what LEGION observed, not what other clients see') and names verify_evidence_bundle as the tool that checks the returned bundle offline, effectively routing the agent. It stops short of explicitly stating when to prefer this over check_mcp_server or verify_mcp_server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an evidence bundle OFFLINE (no network call): keyring chain from the pinned root fingerprint, record
signature and integrity, signed tree head, RFC 9162 inclusion proof. If approved_tools_sha256 is given, also
reports whether the signed tool list still matches the version you approved (UNAPPROVED_CHANGE if not).
Bundle = {record, proof, sth, keyring} as returned by get_server_changes (max 256 KB).
| Name | Required | Description | Default |
|---|---|---|---|
| bundle | Yes | ||
| approved_tools_sha256 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes further with non-obvious behavioral facts: verification is fully offline, the bundle is capped at 256 KB, and a specific result token (UNAPPROVED_CHANGE) is emitted on mismatch. It does not describe the success/failure result shape in general, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Information is front-loaded: the offline/no-network constraint and the list of checks come first, then the conditional parameter behavior, then the bundle shape. Sentences are dense but each carries distinct information. Minor packing of the UNAPPROVED_CHANGE detail mid-sentence slightly hurts scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does mention the UNAPPROVED_CHANGE outcome and the checks performed, plus the bundle input contract. What is missing is the general result shape on success (e.g., an OK/valid token or error list), which would fully close the loop for an agent interpreting the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: it defines the bundle's expected sub-fields ({record, proof, sth, keyring}), its provenance (get_server_changes), and its size limit. It also explains the semantic effect of approved_tools_sha256 rather than just naming it. The opaque nested object is not fully documented field-by-field, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (verify) and resource (evidence bundle) and immediately qualifies the scope with 'OFFLINE (no network call)'. It enumerates exactly what is checked — keyring chain from pinned root fingerprint, record signature/integrity, signed tree head, RFC 9162 inclusion proof — so an agent knows precisely what this tool does versus its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It ties the tool to its producer by stating the bundle is 'as returned by get_server_changes', and gives an explicit conditional for the optional parameter ('If approved_tools_sha256 is given, also reports whether...'). It does not explicitly contrast itself with verify_mcp_server or check_mcp_server, so the when-not guidance is incomplete, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an MCP server URL against LEGION's signed transparency log. Read-only. For each registry server at this
URL: latest signed tool definition (leaf index, date, tools_sha256), number of tool changes (total and 30 days),
date of the last change, RFC 9162 inclusion proof + signed tree head (re-verified here from the pinned root key),
an evidence bundle for verify_evidence_bundle, and — if live=true — whether the tool list served NOW differs from
the signed one (live check by LEGION: initialize + tools/list only, public addresses only, NOT signed).
A change is not a fault; history = what LEGION observed, not what other clients see.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| live | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, yet the description adds substantial behavior beyond them: proofs are re-verified locally from the pinned root key, live=true performs an initialize + tools/list against public addresses only, that live result is explicitly NOT signed, and history reflects only what LEGION observed. It also warns that a change is not a fault.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and the read-only guarantee in the first two short sentences, then a dense but organized inventory of returned artifacts. The enumeration is long, but with no output schema it earns its place as return-value documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by enumerating what is returned (leaf index, dates, tools_sha256, change counts, inclusion proof, signed tree head, evidence bundle, live diff). For a 2-parameter, non-destructive read tool this is sufficiently complete; only the url parameter's accepted form is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the parameters. It explains live=true meaningfully (compare currently served tool list against the signed list) and its default-on behavior is visible in the schema, but the required url parameter is never described (format, accepted public addresses, registry expectations). Half the parameters are clarified, half are left implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: checking an MCP server URL against LEGION's signed transparency log, and summarizes the returned evidence (leaf index, proof, tree head, evidence bundle). It is clearly not a generic lookup. However, it never distinguishes itself from its close sibling check_mcp_server, which an agent cannot disambiguate from this text alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the tool is read-only and tied to the transparency log, and it names verify_evidence_bundle as the downstream consumer of the evidence bundle. There is no explicit 'use this when / use check_mcp_server instead' guidance, so an agent must infer routing between the two server-checking siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_mcp_serverget_checkpointget_server_changesverify_evidence_bundleverify_mcp_serverCheck whether an MCP server answers, what its tools claim, and whether that claim has changed.
Independent trust scores, tool surfaces and change history for MCP servers.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Audit MCP servers for tool poisoning and shadowing. Scan a remote server by URL or paste its tools.
Add one secure layer between your agents and this server.