Is It Trust Ready — agent-trust-readiness scanner

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to cover these. It adds useful context about the content (public identity and trust state) and the tool's authoritative nature ('accountable record'). It does not describe error behavior or rate limits, but given the annotations, the added context is sufficient without being redundant.

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, well-structured sentence that is front-loaded with the core functionality ('Look up an agent's public identity and trust state by ID') and then enriches with the purpose ('the accountable record other agents and humans can rely on'). 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?

This is a simple read-only tool with one parameter, strong annotations, and a likely output schema (not shown). The description covers the tool's niche and value proposition. It does not mention the behavior for non-existent agent IDs, but the output schema and annotations make the description adequate for a tool of this 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 schema already provides 100% coverage for the single parameter agent_id, including an example format ('e.g. smolt-abc123'). The description only states 'by ID', which aligns with the schema but adds no new parameter-specific meaning. Since the schema is detailed, the baseline of 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 clearly states the tool's purpose: 'Look up an agent's public identity and trust state by ID'. It specifies the exact resource (agent identity) and the type of information (public identity and trust state). The phrase 'the accountable record other agents and humans can rely on' distinguishes this from sibling tools like get_reputation or verify_reputation, which focus on reputation or verification.

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 provides clear context for when to use this tool: when you need the authoritative identity and trust state of an agent. It positions this as the reliable source ('accountable record'), which implies it should be used over other tools for canonical agent lookups. However, it does not explicitly mention exclusions or alternatives, such as 'for reputation scores, use get_reputation'.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it is free and public, and explains the concept of a 'portable reliability signal' and the role of the 'visibility' field, providing context beyond the structured 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?

Two sentences, no wasted words. Information is front-loaded with the core action, followed by brief clarification. Every sentence adds value.

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?

Given the tool has only one parameter, full annotations, and an output schema (present but not shown), the description is complete. It explains the rating concept and does not need to detail return values as the output schema covers that.

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% with one parameter 'agent_id' described as 'Agent identifier'. The description adds minimal extra meaning (implies agent registration), but the schema already defines it adequately. 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 specific verbs ('Look up') and identifies the resource ('AI agent's published Trust Rating'). It clearly distinguishes from siblings like 'get_agent' or 'get_reputation_badge' by focusing on the rating and its technical factors.

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 states the tool is 'Free, public, read-only', which implies safe usage. However, it does not explicitly contrast with alternatives like 'verify_reputation' or 'search_reputation_directory'. Given the sibling count, more explicit when-to-use guidance would improve clarity.

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?

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint, so the description need not restate safety. It adds value by detailing the output (badge URL, Markdown, HTML snippets), which is not fully covered by the output schema. No contradictions with 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?

Single sentence efficiently delivers purpose and output details with no superfluous words. Front-loaded with the action and resource.

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 single-parameter tool with an output schema, the description provides sufficient high-level understanding of what is returned. No missing information given the low complexity and annotation coverage.

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% with a clear description for agent_id. The tool description adds no further detail beyond the schema, 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?

Description clearly states the tool retrieves an embeddable Trust Rating badge, specifying it returns a badge image URL along with Markdown and HTML snippets. This differentiates it from sibling tools like get_reputation (which likely returns data) and verify_reputation (which likely verifies claims).

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 when an embeddable badge is needed, but provides no explicit guidance on when to use this tool versus alternatives like get_reputation or verify_reputation. No exclusions or context about prerequisites are mentioned.

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?

Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true. The description adds behavioral context: it is 'zero-auth' (no authentication required) and describes the dual behavior with an optional token for a 'dojo briefing'. No contradictions.

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, dense sentence that front-loads key information: 'Zero-auth, no-args orientation'. Every part serves a purpose, listing the content and headline tools without waste.

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?

Given the tool is an orientation, the description fully covers its purpose, the optional token behavior, and what the output contains. An output schema exists to document return values. It is complete for an entry-point tool.

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% with a single optional 'token' parameter described. The description adds meaning by explaining the two modes (public vs. token-gated) and what each returns, providing context beyond the schema's parameter description.

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 clearly states the tool provides a 'zero-auth, no-args orientation' covering 'who Mnemom is, the surface map, how to authenticate and what it unlocks, and the value tools to try right now'. It specifically highlights 'scan_trust + the reputation reads', distinguishing it from sibling tools that are more specific actions.

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 this is the entry point for new users, as it says 'orientation' and lists what it provides. It mentions an optional token for token-gated content but does not explicitly state when to use versus alternatives. However, the context is clear: use this first to understand the system before using other tools.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds caching behavior, rate-limits on fresh scans, proxy to SSRF-locked scanner, Ed25519 signature preservation, and rubric link – substantial value beyond 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?

Two sentences: first covers core purpose, second adds caching, fresh, proxy, signature, and rubric details. Efficient but packs many details into one sentence; could be slightly better structured.

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?

Tool has 2 params with 100% schema coverage, an output schema, and rich annotations. Description covers purpose, caching, fresh flag, proxy, signature, and rubric reference, making it complete for the tool's 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?

Schema description coverage is 100%. Description adds context on caching and fresh flag behavior (e.g., rate-limited) that complements schema descriptions, but schema already explains parameters well.

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 clearly states the tool scans a website for agent-trust-readiness and returns a signed scorecard with Trust and Access axes. It distinguishes from sibling tools like verify_scan or get_reputation by focusing on scanning trust readiness.

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?

Provides clear usage context: zero-auth, caching up to 24h, check cached/scannedAt fields, pass fresh:true for re-scan. Does not explicitly exclude alternatives or mention when not to use, but context is sufficient.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it is zero-auth and only searches public reputation agents, providing context beyond 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?

Two concise sentences that front-load essential information: purpose, scope, usage flow. No superfluous content.

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?

Given output schema exists, annotations present, and parameter descriptions complete, the description covers purpose, usage, and next steps adequately. No 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 description does not add additional parameter details beyond the schema descriptions. Baseline 3 applies as no extra value.

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?

Uses verb 'resolve' and specifies converting name/id-prefix to agent_id. Distinguishes from siblings by stating it's the entry point to discover agent_id for subsequent calls to get_reputation/verify_reputation.

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?

Explicitly advises to use this tool to discover a concrete agent_id, then call get_reputation/verify_reputation. Also notes zero-auth and public visibility, clarifying when it is appropriate.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds valuable context that this is a chain-integrity attestation and not a signature check, which prevents misuse. No contradictions.

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 core action and output, no unnecessary words. The contrast with verify_scan is efficiently stated. Ideal conciseness and 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?

Given the output schema exists (covers return values), annotations provide safety profile, and the description explains purpose and exclusions, the description is fully complete for this tool's context.

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% (only one parameter, agent_id, with description). The description does not add new information beyond the schema's parameter description, so baseline score of 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 clearly states it attests an agent's trust rating by returning a Merkle-root + hash-chain attestation, and explicitly distinguishes it from verify_scan for website scorecards. Verb 'attest' plus specific resource 'Trust Rating' is unambiguous.

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 includes an explicit when-not: 'NOT an in-band Ed25519 signature check (that parity is verify_scan)'. However, it does not mention when to use this vs get_reputation or get_reputation_badge, which are sibling tools for reputation retrieval. The guidance is present but not exhaustive.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond these by adding 'Zero-auth' (authentication requirements) and 'IN-BAND (verify, don't trust)' (trust model), as well as the specific public key source at mnemom://iitr/jwks. This enriches the behavioral context without contradicting 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 two sentences, front-loading the core purpose and return shape before providing supplementary links. It contains no filler or fluff; every clause adds value (e.g., 'Zero-auth', 'IN-BAND'), and the spec/rubric links are useful without bloating the text.

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?

Given the rich output schema and the presence of annotations, the description is largely complete: it covers input modes, the verification target, authentication requirements, and the key source. It could be slightly more complete by explicitly distinguishing from verify_reputation, but that is a minor gap given the tool's name and the context provided by the schema.

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 provides 100% parameter coverage with detailed descriptions for both `scan` and `url`, including the oneOf relationship and expectation that `scan` is passed verbatim from scan_trust. The description's 'Pass a `scan` ... or a `url` to re-scan' merely restates what the schema already documents, adding no new semantic meaning for 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 and resource: 'Verify a website scan scorecard's Ed25519 signature IN-BAND (verify, don't trust).' This clearly states what the tool does and distinguishes it from sibling tools like verify_reputation, which likely handles reputation certificates rather than scan scorecards. The reference to scan_trust further anchors the tool's role.

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: pass a `scan` (a scorecard from scan_trust) or a `url` to re-scan, which tells the agent when this tool is appropriate. However, it does not explicitly contrast with verify_reputation or state any exclusionary conditions, though the 'scan scorecard' phrasing implies the boundary. The provided spec links offer additional guidance.

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