explain_statusDeterministically render the exact ECZ-ID status using the claims-safe renderer (VERIFIED is an ECZ-ID state, not a Microsoft certification). Absence of evidence renders the approved neutral wording — never "unsafe". No LLM.
| Name | Required | Description | Default |
|---|---|---|---|
| ecz_id | Yes | ECZ-ID identifier, e.g. ECZ-GB-RBS1NW |
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.
Add one secure layer between your agents and this server.
Most tools are conceptually distinct, but get_current_state, resolve_identity, and explain_status all orbit the same status/render responsibility and could be misselected without careful reading. The descriptions reduce overlap, but the boundaries are still subtle.
Every tool follows a consistent verb_noun pattern: create_request_to_resolve, explain_status, find_product, get_current_state, get_install_instructions, get_resolver_link, resolve_identity. There is no mixing of conventions or vague ambiguous verbs.
Seven tools is a well-scoped set for an identity-trust utility server. Each tool covers a distinct operation area without bloat, and the count fits comfortably within the expected range.
The domain is covered well: resolution, state retrieval, status explanation, resolver links, request creation, product guidance, and install instructions. Minor gaps exist around request lifecycle management (e.g., checking or cancelling a request), but core workflows are not dead-ended.