ECZ-ID Trust MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses authentication requirements, the required scope/app role, and important negative behaviors ('never verifies a target, never sends messages, absence of evidence is never rendered as unsafe'). It doesn't discuss idempotency or response behavior, but still provides substantial behavioral context.

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?

Two tightly written sentences with the critical authentication requirement front-loaded and the non-behaviors condensed into a clear list. Every sentence earns its place with no wasted words.

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?

Strong on purpose, authentication, and side-effect boundaries, but incomplete for a 6-parameter creation tool with no output schema. Required parameters like consent_mode and requested_evidence_category are unexplained, and there is no indication of return value or failure behavior.

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%, and the description provides no parameter-level meaning for target_type, target_descriptor, requested_evidence_category, consent_mode, resolver_ref, or idempotency_key. It only frames the overall request concept, leaving agents to guess formats and semantics for required fields.

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 action ('create'), a precise resource ('a neutral, shareable request for independently re-checkable ECZ-ID evidence'), and explicitly disclaims verification and messaging, which differentiates it from siblings like resolve_identity. The tool's role is clear and distinguishable.

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?

The description gives clear usage context: it is authenticated, requires a Microsoft Entra bearer token with a specific scope, and clarifies what the tool never does. It doesn't name sibling tools or provide explicit when-not-to-use conditions, but the boundary against verification and messaging serves as strong implicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does it well: it discloses determinism, the claims-safe renderer, the absence-of-evidence neutral wording, the 'never unsafe' guarantee, and the No-LLM behavior. It does not mention output format or errors, but for a simple read-only renderer the key behaviors are clearly surfaced.

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 three tight sentences with the core action front-loaded. Every sentence adds a distinct behavioral constraint, and there is no filler or redundant restating of the tool name.

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?

For a single-parameter renderer with no output schema, the description covers the essential behavior: what is rendered, how it is rendered, and what happens with absence of evidence. It stops short of enumerating possible status values or the exact neutral wording, but the agent has enough to invoke it 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 100%, so the baseline applies. The description does not add parameter-specific meaning beyond referencing ECZ-ID status; all usable semantic detail about ecz_id lives in the schema.

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 uses a specific verb and resource: 'Deterministically render the exact ECZ-ID status'. The clarification about VERIFIED and the 'No LLM' note help pin down the intended meaning, but it never names or contrasts a sibling tool, so differentiation is implied rather than explicit.

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?

The description implies when to use this tool: when an exact, deterministic, claims-safe status rendering is needed rather than an LLM-generated explanation. It does not explicitly state when to prefer a sibling or give exclusions, so usage guidance is present only by implication.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure, and it does usefully state that exactly one action is returned and that free/community routes take precedence when correct. It does not disclose the shape of the returned action, side effects, or failure behavior, leaving a transparency gap.

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 a single front-loaded sentence with no filler, and the key decision logic is placed first. It loses a point because terms like 'ECZ-ID product action' and 'narrow context flags' are used without explanation, which reduces clarity despite the good structure.

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?

This is a decision tool with nine boolean inputs, no annotations, and no output schema, so the one-sentence description is not enough for an agent to invoke it correctly. Missing details include how the flags map to specific product actions, what the returned action value looks like, and how neutral/edge cases are resolved.

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 compensate for the nine undocumented boolean parameters. It only labels them generically as 'narrow context flags' and provides no per-parameter meaning, combination rules, or examples, so the agent cannot infer how to set each flag.

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 uses a specific verb ('return') and resource ('ONE best next ECZ-ID product action'), and it explains the tie-breaking preference between free/community and public verification routes. It does not explicitly contrast with sibling tools, but the 'return a recommendation' framing distinguishes it from the more execution-oriented 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?

The opening phrase 'Given narrow context flags' establishes a clear input-based condition for when the tool is appropriate, and the routing policy explains how the decision should be made. However, it does not name alternative tools or state explicit exclusions, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the return scope (state, checked_at, Resolver link) and what it deliberately does not do (inference). However, it lacks mention of potential error conditions, authentication requirements, rate limits, or behaviors on invalid ECZ-IDs, which would be expected for a complete picture.

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?

A single sentence that front-loads the core purpose, specifies the exact data returned, and adds a caveat about what is excluded. Every clause earns its place, and the structure is immediately 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?

For a simple getter with one parameter and no output schema, the description names the three returned fields and the scope boundary, which is sufficient for an agent to call it correctly. While it does not specify error behavior or output format beyond field names, the absence of an output schema means the description does not need to explain return values in depth.

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 100%, so the schema already fully documents the 'ecz_id' parameter. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.

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 ('Return') and resource ('current Resolver-derived state for an ECZ-ID') and enumerates the exact fields returned (state, checked_at, Resolver link). Explicitly scopes out risk/safety/compliance inference, which distinguishes it from siblings like resolve_identity or explain_status that likely perform inference.

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?

The description implies usage: it returns a 'narrow' state and explicitly notes 'No risk/safety/compliance inference', suggesting that tools like explain_status should be used when inference is needed. However, it does not name alternative tools or describe specific scenarios where this tool is the right choice versus a sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does disclose useful behavior: results are deterministic, only canonical URLs are returned, and planned Microsoft surfaces yield no URLs. However, it does not describe the output structure, error behavior, or explicitly confirm there are no side effects, though 'Return' implies a read-only operation.

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 a single efficient sentence with a parenthetical for edge-case clarification. Every element earns its place: the action, the object, the canonical-URL constraint, and the planned-surface exception.

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?

For a one-parameter read-like tool with no output schema, the description is mostly complete: it states what is returned and the important special case. The only real gap is that it does not specify the exact response structure, but that is a minor omission given the low complexity.

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 single parameter 'product' is already fully described in the input schema, including the allowed slug values and pattern, so schema coverage is 100%. The description adds no additional parameter-level semantics beyond the phrase 'ECZ-ID product or surface', which is not needed for correct invocation.

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 uses a specific verb ('Return') and a clear resource ('official install/discovery routes for an ECZ-ID product or surface'), plus scoping details ('canonical URLs only; planned Microsoft surfaces carry no URLs'). This makes it clearly distinct from sibling tools like get_resolver_link or find_product without needing to inspect their schemas.

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?

There is no explicit guidance about when to use this tool versus its alternatives. The description never mentions sibling tools or conditions that would route an agent away from this tool. Usage is only implied by the name and the general purpose statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does well: 'deterministic' implies stable output, 'public' suggests no auth barrier, and 'No network call' signals a pure computation with no side effects. It doesn't describe URL format or failure behavior, but for a simple link generator this is solid coverage.

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?

Two sentences with no filler. The main purpose is front-loaded, and the key behavioral caveat ('No network call') is placed in the second sentence without redundancy.

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?

For a one-parameter tool with 100% schema coverage and no output schema, the description is mostly complete: it states what is returned, for what input, and that no network call occurs. The main gap is that it doesn't explicitly position the tool relative to the sibling operations that may appear similar.

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 100%: the ecz_id parameter already includes a pattern, maxLength, and an example. The description does not add parameter-specific semantics, but no additional guidance is required; this matches the baseline for fully schema-documented parameters.

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 opens with a specific verb ('Return'), names the exact resource (ECZ-ID), and specifies the output type (proof/re-check URL). It also adds a distinguishing property, 'No network call,' which separates it from resolution-style siblings like resolve_identity or create_request_to_resolve.

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?

'No network call' gives useful context for choosing this tool, but the description does not explicitly say when to use this tool versus sibling tools or when not to use it. Usage guidance is therefore implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It does well by enumerating the returned fields and adding a meaningful caveat: 'Never asserts safety, approval or compliance.' It does not mention potential errors or rate limits, but for a simple one-parameter lookup this is reasonably transparent.

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?

A single, information-dense sentence front-loads the operation and then lists key return components and a caveat. There is no filler or repetition of schema details.

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?

For a tool with one required parameter and no output schema, the description covers the essential return contract and a behavioral caveat. It could elaborate on what 're-check action' and 'local-policy caveat' mean, but the core calling context is sufficiently complete.

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 input schema already provides 100% parameter coverage, including type, pattern, max length, and an example. The description adds no new parameter-level semantics beyond referring to 'an ECZ-ID', so baseline 3 is appropriate.

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 uses a specific verb ('Resolve') with a clear resource ('an ECZ-ID') and specifies the exact output ('canonical state with checked_at, Resolver proof link, re-check action and the local-policy caveat'). It also distinguishes itself from siblings by stating it goes through the public ECZ-ID Resolver and explicitly disclaims safety/compliance assertions.

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?

The implied usage is clear: use this tool when you need the resolved canonical state plus proof and caveat details. However, it does not explicitly name alternatives like get_resolver_link or get_current_state, nor does it state when not to use this tool versus those siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.