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 burden and does so well: it declares deterministic rendering, claims-safe wording, that VERIFIED is an ECZ-ID state rather than a Microsoft certification, absence-of-evidence handling, and that no LLM is involved. It omits auth/permission requirements and rate/return behavior, keeping 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?

Roughly two dense sentences, front-loaded with the core action, with no filler. Each clause (determinism, VERIFIED semantics, neutral fallback, no LLM) contributes distinct information.

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 renderer with no output schema and no annotations, the description conveys the semantics of the output wording and its guarantees. It does not hint at the returned shape or any access prerequisites, leaving a small gap.

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 single ecz_id parameter already documents the parent/child forms and pattern. The description adds no parameter-level syntax or format detail, so the baseline 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 action (deterministically render/explain) on a specific resource (ECZ-ID status) via a named mechanism (the claims-safe renderer). An agent understands the intent, but the description never names a sibling such as get_current_state, so the boundary between 'explain' and 'get current state' is left to 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?

There is no explicit when-to-use / when-not-to-use guidance and no named alternative among the six sibling tools. Usage is only implied by the wording ('claims-safe', 'No LLM'), which an agent must interpret on its own.

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?

No annotations, so the description bears the full burden. It declares the operation is non-inferential (no risk/safety/compliance), which usefully sets expectations about output scope. But it doesn't state read-only explicitly, latency, auth requirements, or what happens for unknown/stale IDs — for a no-annotation tool, that leaves gaps.

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 tight sentences, front-loaded with the action and scope. The exclusion clause ('No risk/...') is the second sentence and earns its place by preventing the agent from over-reading the output.

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-param read tool with 100% schema coverage and no output schema, the description is largely sufficient. The main missing piece is disambiguation from get_resolver_link, which shares the 'Resolver link' surface and is not addressed.

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 100% — the ecz_id parameter is fully documented with a pattern and examples of parent vs child Passport IDs. The description adds nothing about parameters, which is acceptable given the schema does the work; baseline 3.

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 and resource ('Return the narrow current Resolver-derived state for an ECZ-ID') and enumerates the returned fields (state, checked_at, Resolver link). It's clearly a read of current state, distinguishing it from mutation siblings like create_request_to_resolve, though it doesn't explicitly name which sibling to use instead of get_resolver_link.

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's an implicit scope constraint ('narrow', 'No risk/safety/compliance inference'), which tells the agent what NOT to expect, but no explicit when-to-use guidance or named alternative. The closest sibling, get_resolver_link, overlaps on the 'Resolver link' concept and isn't disambiguated.

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 behavioral burden and does disclose two meaningful traits: the operation is deterministic and performs no network call, implying a safe, side-effect-free computation. It omits error behavior for malformed ECZ-IDs and any auth requirements, but the core behavioral profile is covered.

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 short sentences, zero filler, with the core action ('Return the ... URL for an ECZ-ID') front-loaded and the behavioral qualifier ('No network call') following it.

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 pure tool with no output schema, the description adequately conveys what is produced (a public Resolver proof/re-check URL). It could note the URL format or failure mode for invalid IDs, but nothing essential to calling 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?

Schema coverage is 100% and the single ecz_id parameter is fully described with a regex pattern, maxLength, and parent/child examples. The description adds nothing about parameter formatting beyond the schema, so the 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?

States a specific verb+resource: returns the public Resolver proof/re-check URL for an ECZ-ID, which is distinct from siblings like resolve_identity or create_request_to_resolve. It does not explicitly name a sibling or contrast itself with them, so the differentiation is inferential rather than stated.

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 phrase 'No network call' implicitly signals when this is preferable (cheap, offline link generation versus a live resolution), but the description never states when to use this over resolve_identity or create_request_to_resolve. Usage context is implied, not spelled out.

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. It usefully discloses the local-policy caveat and the explicit non-assertion of safety/approval/compliance, which is meaningful behavioral context. However, it says nothing about whether the lookup is read-only, its error modes (unresolvable IDs), rate limits, or latency/network dependence, so it is incomplete for a tool with zero annotation 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, front-loaded with the verb and resource, then the return shape and the caveat. Dense but no filler; the key constraint (no safety assertion) is placed at the end but still clearly stated.

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 does carry return-value burden; it names checked_at, a proof link, a re-check action, and the policy caveat, which is decent but not a full shape. Combined with absent usage guidance and no read-only/error behavior disclosure on a zero-annotation tool, the definition is adequate but has clear gaps.

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 100% and the single parameter includes a pattern, maxLength, and an example-rich description covering parent and child Passport forms. The description adds no parameter-level detail beyond the schema, so the baseline 3 for high coverage 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 (resolve) and resource (ECZ-ID via the public ECZ-ID Resolver) and describes the canonical output shape. It is distinct from siblings like get_current_state or get_resolver_link, though it doesn't explicitly contrast with them.

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 when-to-use or when-not-to-use guidance is given. With siblings such as get_current_state and get_resolver_link that could be confused with resolving an ID, the description leaves the routing decision entirely to the agent.

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