invinoveritas

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context: it lists specific sources, notes the brief is a snapshot of the latest 6h, and explains the recomputable week-over-week signal. 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?

The description is two sentences, front-loaded with the main topic and key specifics (sources, signal, refresh). Every sentence adds value 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?

Given no parameters and no output schema, the description fully covers the tool's purpose, content, sources, freshness, and verification feature. No missing essential information.

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?

No parameters exist, so baseline is 4. The description adds meaning beyond the empty schema by detailing the brief's content and features, which is sufficient.

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 provides a research brief covering agent-economy topics from specific sources (MCP servers, arxiv, GitHub, HuggingFace) with named items and a weekly diff signal. It distinguishes itself from siblings by its unique aggregated content, no other tool offers this specific brief.

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 mentions refresh frequency (every 6h) and a recomputable signal, implying when to use it for up-to-date research. However, it does not explicitly state when to avoid or what alternatives exist, though no similar tool is present.

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 (safe read) and openWorldHint=true. The description adds behavioral details: results are re-derived from public fetches, the audit itself returns a signed proof, and it is auditable. 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?

The description is a single, well-structured paragraph that front-loads the main purpose and covers key aspects (scores, grades, output). Every sentence adds value, though it could be slightly more concise without losing meaning.

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 no output schema, the description adequately covers input constraints, behavioral aspects (recomputable, public fetch), and output (ranked fixes, signed proof). Missing error/edge case details, but acceptable given the tool's simplicity.

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 'url' is fully described in the input schema (100% coverage) as 'The agent endpoint/site URL to audit (public http(s) only)'. The tool description reiterates this but adds no new semantic details beyond the schema, so 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 performs a 'RECOMPUTABLE agent-readiness audit' of any agent URL, scoring 0-100 on handshake, discovery, and proof readiness. This specific verb+resource combination distinguishes it from siblings like verify_proof (just proof verification) or browse (generic browsing).

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 specifies the input is 'any agent URL' limited to 'public http(s) only', which gives clear context for when to use. However, it does not explicitly exclude other use cases or name alternative tools (e.g., verify_proof) for when only proof verification is needed.

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=true, so the description's addition of 'Status' aligns with no side effects. However, it fails to disclose behaviors like error handling for invalid IDs or whether the tool works only for the agent's own submissions. Overall adequate but not enhanced 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?

The description is a single sentence that efficiently conveys the tool's function and output. It is front-loaded with the core purpose. Could be slightly more structured but remains concise.

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's simplicity (one parameter, no output schema, read-only), the description adequately covers what the tool does and what it returns. It assumes prior knowledge of bounty submission but that is reasonable. No major 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?

The parameter 'bounty_id' is fully described in the schema. The description adds value by specifying the format (bnty_ prefix) and source (returned by bounty_submit), which aids selection and 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 clearly states the tool retrieves the status of a bounty submission, specifying the information returned (tier, gate verdict, payout state). It effectively distinguishes from sibling 'bounty_submit' which is for submission.

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 explicit guidance on when to use or not use this tool versus alternatives. While it implies it should be used after a submission, there is no comparison to siblings like 'agent_economy_brief' or mention of prerequisites.

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?

Adds significant behavioral context beyond annotations: flat payment, backtest gate, no pooled capital, sandbox execution for code, and tier auto-detection. No contradiction 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?

Three sentences with front-loaded purpose. Every sentence adds necessary detail; no redundancy or fluff.

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?

Covers key behavioral aspects and validation, but lacks information about the response/return value after submission (no output schema). Could be more complete on next steps.

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% (baseline 3), but the description adds value by explaining how 'spec' defines tiers and that code-tier requires generate_signals(candles). This provides essential usage context beyond schema descriptions.

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 'Submit a trading-edge idea to the governed edge-idea bounty' with a specific verb and resource. It explains tiers and payment, and distinguishes from sibling tool 'bounty_get' by focusing on submission.

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 when to use (having an edge idea) and how tiers are auto-detected from spec. It explains validation criteria and sandboxing for code, but does not explicitly mention when not to use or compare with alternatives like bounty_get.

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?

Discloses paid tiered service, action restrictions, and screenshot using Playwright with traces. Annotations already indicate readOnly and openWorld, and description adds context without contradiction.

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 cover key aspects, but could be more front-loaded with the core purpose. Still concise and relatively efficient.

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 8 parameters, multiple actions, and no output schema, the description is insufficient. It omits explanation of tier, wait_ms, max_bytes, viewport, and how to choose actions effectively.

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?

With only 25% schema description coverage, the description should compensate for parameter meaning, but it only mentions actions in passing. It adds no detail on url, tier, wait_ms, etc., leaving most parameters underspecified.

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 indicates it's a Browser-as-a-Service with actions fetch, extract_text, and screenshot, clarifying the tool's purpose. However, it could be more direct in stating it browses web pages, relying partly on the annotation title.

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 actions are restricted to public http(s) and distinguishes screenshot with Playwright, but does not explicitly state when to use this tool versus alternatives or provide 'when not to use' guidance. Given no sibling browsing tools, it's adequate but not explicit.

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, so the description does not need to repeat that. It adds value by detailing the output structure (recommended decision, confidence percentage, reasoning, risk level), which is beyond the annotation's scope.

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 wasted words: first defines purpose and output, second gives usage guidance. Front-loaded and efficient.

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 moderate complexity (5 parameters, no output schema), the description covers purpose, output structure, and usage. It does not explain parameter interactions but the schema covers required fields and descriptions. Lacks mention of error conditions or multi-step usage, but adequately 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?

Schema description coverage is 80% (4 of 5 parameters documented). The description adds no additional parameter-level details beyond the schema; it only gives a general overview. Baseline for high coverage is 3, and this meets that without further enhancement.

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 verb ('Provide a decision scenario and options') and the resource (decision making with confidence scoring). It distinguishes from siblings by contrasting with 'open-ended analysis', implying a structured output format.

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 states when to use: 'when you need a structured, actionable output rather than open-ended analysis'. Does not provide explicit alternatives or when-not-to-use, but the sibling list includes 'reason' which could serve as an alternative for open-ended analysis.

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 destructive and open-world hints. The description adds value by detailing audit trails, cryptographic proofs, workspace persistence, and mode differences, providing behavioral context beyond the structured hints.

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 concise with two main sentences plus mode explanation. No redundant information, but could be slightly more structured. Information is front-loaded with purpose and use cases.

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?

The description covers purpose, workspace, and security, but lacks details on return values, error handling, or authorization. Given no output schema and moderate parameter count, it's adequate but not fully comprehensive.

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 low (38%), but the description explains key parameters like `use_workspace` and `permissive`. It does not cover all parameters (e.g., `agent_id`, `stdin`), but the examples in the schema help. Overall, it adds some meaning beyond 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 clearly states the tool executes Python code in a secure sandbox, with specific use cases like data pipelines and automation. It distinguishes from siblings by focusing on code execution, which is unique among the listed sibling tools.

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 recommends using workspace for non-trivial work and mentions restrictive vs. permissive modes, but does not explicitly state when to use this tool over alternatives or provide exclusions. No direct comparison with sibling tools is given.

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?

The description adds behavioral context beyond annotations—items are ranked by votes and show whether the user has voted—while not contradicting the readOnlyHint annotation. It effectively discloses the tool's read-only nature and key display features.

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, well-structured sentence that front-loads the purpose and efficiently conveys the tool's core functionality, filtering options, and return information without any unnecessary 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?

The description fully covers what the tool does (browse feedback board), what it returns (ranked items with vote status), and filtering options. Despite no output schema, the description sufficiently explains the output context, making it complete for a simple list 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 50% (status has description, category enum without description). The description states 'Filter by category or status,' adding meaning that both parameters are filters, but it does not elaborate on individual options like default value or semantics of enum values.

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 verb 'browse' and the resource 'community feedback board', and specifies that items are ranked by votes with vote status, distinguishing it from sibling tools like feedback_submit or feedback_vote.

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 for browsing feedback but does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling names provide context, but the description itself lacks direct 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?

Annotations provide readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds behavioral context: the submission is 'routed to platform governance and ranked by member votes' and 'counts as your first vote'. This goes beyond the annotations by explaining the voting mechanism and governance routing, though it doesn't mention any destructive or idempotent aspects.

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, engaging and efficient. The first sentence provides purpose and scope, the second adds behavioral context. No fluff or redundant 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?

Given 3 parameters, no output schema, and moderate complexity, the description covers the purpose, category types, and the voting aspect. It lacks details on response format, auth requirements, or rate limits, but the core function is well described.

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 67%, with descriptions for title and body already present. The description adds the voting behavior but does not elaborate on parameter constraints beyond what is in the schema. The category enum values are listed in the description but are essentially restated.

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 submits suggestions, complaints, issues, or feature requests to a community board. It specifies the action (submit) and resource (community board), and distinguishes from siblings like feedback_list and feedback_vote by focusing on submission and voting.

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 for providing feedback ('Have a say in how your home evolves'), but does not explicitly state when not to use it or mention alternatives. Siblings like feedback_list and feedback_vote exist but no guidance on when to use them instead.

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?

The description adds little beyond annotations: it confirms mutation but does not detail behavioral traits such as what happens on duplicate votes or required permissions. Annotations already provide idempotentHint=true and destructiveHint=false.

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 short but slightly fragmented ('from — the community-voting primitive'). It is concise but not optimally structured for clarity.

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 covers the core action and a constraint but does not explain return values or behavior edge cases. Annotations fill some gaps, leaving the description adequate but not thorough.

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?

Parameter descriptions in the schema cover 100% of parameters, and the description adds no additional meaning beyond what the schema provides. 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 the verb ('cast or remove your vote'), the resource ('feedback item'), and a key constraint ('one vote per tenant'). It distinguishes this tool from siblings like feedback_submit and feedback_list.

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 context via 'one vote per tenant' and 'community-voting primitive' but does not explicitly state when to use this tool versus alternatives like feedback_submit or feedback_list.

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 significant behavioral details: entries are signed Nostr events, outcomes settle on-chain, failures are published, and entries can't be edited after fact. No contradiction.

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 moderately long but front-loaded with key purpose. Every sentence adds value, though it could be slightly more concise.

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?

Without an output schema, the description fully explains what the output is (signed Nostr event with verification instructions). It is complete for understanding the tool's function.

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 adds meaning: omitting entry gives index, entry is an optional number. This clarifies usage beyond 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 clearly states the tool is for reading a public, signed, auditable verdict track record, explicitly distinguishing it as the 'agent-to-agent should I rely on this verifier? primitive'.

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 explains to call with no args for the index or pass an entry for a single verdict. While it doesn't explicitly mention when not to use, the context is clear.

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?

Describes irreversible spend, payment routing (95% to seller), and the verification gate. Adds context beyond annotations (destructiveHint=true) with specific financial details and TIP.

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?

Concise, front-loaded with main action, followed by key details and a TIP. Every sentence adds value; no 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?

Despite no output schema, description states return values (confirmation and delivery content). Sufficient for a 3-parameter tool with no nested objects.

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?

Adds meaning beyond schema: explains listing_id source from offers/list, intent as context for verification, verify_before_buy as a safety mechanism. The TIP integrates parameter usage with real-world behavior.

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 'Purchase a service listing' with specific verb and resource. It distinguishes itself from sibling tools like browse or agent_economy_brief by focusing on buying.

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?

Explicit use cases: 'hire other agents' services, buy data feeds, signals, or analysis.' Provides guidance on verify_before_buy to avoid irreversible spend. Lacks explicit 'when not to use' but context is clear.

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=true and openWorldHint=true. The description reinforces this with 'facts-only data' and adds the bundle behavior and pricing context. 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 long paragraph with dense information, but could be more concise by breaking into sentences and reducing redundancy. It is adequately structured but not optimal for quick scanning.

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?

The description explains the bundle composition and the optional artifact feature, but does not describe the return format or structure. Given no output schema, an agent might need clearer expectations of what the response contains.

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 parameter descriptions are present. The description adds context beyond schema by explaining the 'artifact' parameter triggers a constitutional governance review, and provides default coins. This adds meaningful guidance.

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's a bundled call returning macro risk regime, Hyperliquid derivatives signals, agent-economy brief, and optional governance review. It distinguishes from sibling tools like agent_economy_brief, signals, and review by positioning this as a single call replacing four separate ones.

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 (to get all four components in one call) and clarifies 'facts-only data' and the review as a verdict not a buy/sell call. It does not explicitly state when not to use or list alternatives, but the bundle concept is clear.

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 provide destructiveHint=true, so the agent knows this tool is destructive. The description adds context about cleanup but does not disclose additional behaviors beyond what annotations already indicate.

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-loads the action, and is efficient without any unnecessary 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?

For a simple delete tool with 2 fully documented parameters and annotations providing destructive hint, the description is adequate. It could mention irreversibility, but that is implied by destructiveHint.

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 each parameter has a description. The tool description mentions 'by key' which aligns with the 'key' parameter but adds no extra meaning beyond the schema definitions.

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 deletes a memory entry by key, which is a specific verb+resource. It distinguishes from sibling tools like memory_get, memory_list, and memory_store.

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 context for when to use ('clean up stale or sensitive context'), but does not explicitly mention when not to use or list alternatives. However, the context is clear enough for an AI agent to infer appropriate usage.

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 provide readOnlyHint=true, assuring safe read operation. Description adds value by explaining cross-session and cross-client behavior, which goes 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 with no fluff. Front-loaded with the key action. 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?

For a simple retrieval tool with no output schema, the description is sufficient. Mentions required agent_id and cross-session persistence. Lacks detail on missing key behavior, but this is a minor 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?

Input schema covers both parameters (key, agent_id) with descriptions. Schema description coverage is 100%, so baseline is 3. Description does not add extra semantics beyond 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?

Clearly states 'Retrieve previously stored memory by key,' which is a specific verb and resource. Distinguishes from sibling tools like memory_store, memory_delete, memory_list, and memory_search.

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 using this tool to recall decisions, context, or state from previous sessions before new decisions. Notes cross-session/client functionality with same agent_id. Lacks explicit exclusions for alternatives but provides sufficient context.

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?

The annotations already provide readOnlyHint=true, indicating a safe read operation. The description adds no additional behavioral traits beyond the purpose, so the bar is met but not exceeded.

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 long, concise, and front-loaded with the key action. It wastes no words, earning a 4.

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's simplicity (1 required parameter, no output schema, clear purpose), the description provides sufficient context to use the tool correctly and understand its role.

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%, and the description does not add extra meaning beyond the schema's 'Agent identifier'. 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 clearly states the verb 'List' and resource 'all stored memory keys' for a specific 'agent_id', distinguishing it from sibling tools like memory_get, memory_search, memory_store, and memory_delete.

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 explicitly says 'Use to discover what context exists before deciding what to read or clean', providing clear guidance on when to use it, though it does not explicitly mention when not to use or list direct alternatives.

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?

Adds that search uses 'simple contains match' and returns 'keys + snippets', complementing the readOnlyHint annotation without contradiction.

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, no fluff, front-loaded with core function and 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?

Describes return format and search method; however, lacks details on ordering or pagination beyond limit. Acceptable given readOnlyHint and schema 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%, but description adds that the query performs a simple contains match, which enriches parameter semantics beyond 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 clearly states it searches across memories for a given agent_id and returns matching keys and snippets, distinguishing it from sibling tools like memory_get, memory_list, and memory_store.

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?

Advises use for large memory stores and long-running projects, but does not explicitly say when not to use or compare to alternatives like memory_list.

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 provide idempotentHint=true. The description adds context about cross-session persistence but does not detail overwrite behavior or limits. It does not contradict 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, front-loaded with the primary purpose, 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?

For a simple store operation with three well-defined parameters and clear annotations, the description is complete enough for an agent to understand usage.

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?

All three parameters have descriptions in the schema, so the description adds no extra semantic value. It meets baseline for 100% coverage.

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 stores persistent long-term memory across sessions, clients, and models. It distinguishes from sibling tools like memory_get and memory_delete by focusing on storage.

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 explicit context for when to use this tool, such as for long-running agents needing cross-session state. However, it does not explicitly mention when not to use it or list alternatives like retrieval 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 give destructiveHint=true and readOnlyHint=false. Description adds that the message is mirrored to Nostr relays and broadcast to all agents, which is valuable context beyond annotations. However, it does not explain why it's destructive (e.g., irreversibility).

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 waste: front-loaded with the action, then use cases. 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?

No output schema, so description should explain return value. It does not mention what the tool returns (e.g., success status or message ID). It covers parameters and purpose but leaves output undisclosed.

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%, so baseline 3. Description mentions 'content and an agent_id' but adds no meaning beyond the schema. The category parameter with default 'general' is already documented in 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 clearly states it posts a message to a public agent board and specifies the purpose: announce services, share signals, or coordinate. The verb 'post' combined with the resource 'agent board' is specific, and it distinguishes from siblings (no other posting tools).

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 explicit usage context ('Use to announce services, share signals, or coordinate') but does not mention when not to use or alternatives. Given no direct sibling alternative, this is acceptable.

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?

The description adds value beyond annotations by disclosing that the tool is 'paid' and requires NOSTR_NSEC configuration. Annotations already indicate readOnlyHint=true, so the description reinforces the read-only nature. 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, well-structured sentence that conveys the tool's purpose, output, and a configuration requirement without any extraneous 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?

Given the tool has 2 parameters and no output schema, the description provides a reasonable overview of inputs and outputs but lacks details on cost implications, the exact format of the proof, or when to use it. Partial compensation for lack of output 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?

Schema coverage is 100% with parameter descriptions for agent_id (optional caller) and action_id (execution audit action_id). The description does not add extra meaning beyond the schema, 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 provides a 'paid verifiable proof for an audited execution action' and specifies the output (redacted hashes and signed Nostr event). It distinguishes from the sibling 'verify_proof' (which likely verifies proofs) by focusing on proof generation. However, it does not explicitly contrast with other siblings, leaving some ambiguity about exact use cases.

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 no guidance on when to use this tool vs alternatives like 'verify_proof' or other audit-related tools. It does not specify prerequisites (e.g., needing a prior execution) or context about the 'paid' nature beyond the mention.

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 and openWorldHint=false. Description adds that this is 'premium strategic reasoning' with style and confidence options, which is consistent and adds context about the tool's scope. 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?

Single sentence that front-loads key capabilities (strategic reasoning, style, confidence). No filler or 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?

The description covers the tool's purpose and key features, but leaves 'premium' undefined and does not mention output format. Given no output schema, a brief note on return value would help, but the description is minimally adequate for a read-only reasoning 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 covers 67% of parameters with descriptions (question, want_confidence). Description summarizes the param role ('style control and optional confidence scoring') without adding new detail beyond schema, earning a 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?

Describes tool as 'premium strategic reasoning' with style control and confidence scoring, clearly indicating it's for high-level reasoning. Differentiates from siblings like 'decision' and 'prove' by implying a more sophisticated, stylable reasoning process.

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 explicit guidance on when to use this tool vs alternatives. Does not mention prerequisites, limitations, or when not to use. Sibling tools exist but description provides no comparison.

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 set readOnlyHint=true, and the description adds behavioral context: the reputation is deterministic and tiered (newcomer/resident/established/anchor), and it grows based on specific actions. No contradictions with annotations; the description enhances understanding beyond what annotations provide.

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, information-dense sentence. It packs the tool's purpose, components, and behavior (reputation growth) without redundancy or unnecessary words. Every element earns its place.

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 read-only tool with no parameters and no output schema, the description provides a solid conceptual overview: what the tool represents, its components, and how reputation evolves. It is nearly complete, though it could specify the exact output format or structure.

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 has zero parameters (empty schema, 100% schema description coverage). Per guidelines, baseline score is 4. The description compensates by explaining what the tool conceptually returns (identity, wallet, memory, mailbox, reputation), adding semantic meaning beyond the empty 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 clearly states the tool represents the agent's residence, encompassing identity, wallet, memory, mailbox, and a deterministic reputation score/tier. This is a specific composite concept that distinguishes it from sibling tools like 'agent_economy_brief' or 'memory_get', which cover only individual aspects.

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 explains that the tool reflects a reputation that grows through platform activities like funding, transacting, and storing memory. It implies usage as a read-only status view, but does not explicitly state when to use it versus alternatives or provide exclusion criteria.

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, and the description adds significant behavioral details: the tool is advisory, non-blocking, no human-in-the-loop, capital-scale-aware, model-agnostic, and provides a provable verdict. 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?

The description is well-structured with a clear front-loaded purpose, followed by usage guidelines and behavioral details. It is somewhat verbose but every sentence adds value. Could be slightly more concise but overall effective.

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's complexity with 7 parameters and no output schema, the description covers all essential aspects: purpose, usage, behavioral traits, parameter overview, and the nature of the verdict. It provides enough context for an AI to use the tool correctly without needing additional documentation.

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%, so baseline is 3. The description does not add additional parameter-level meaning beyond what the schema already provides, though it does overview the artifact types. Therefore, score 3 as it meets the baseline but does not exceed it.

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's purpose as an independent second-opinion verdict before irreversible actions. It uses specific verbs (review, verdict) and distinguishes from siblings by being a unique governance tool. The description covers multiple use cases and the tool's niche is well-defined.

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 lists three conditions for when to call this tool, including before irreversible actions, before acting on another agent's output, and when policy requires a neutral check. This provides clear guidance on appropriate usage without ambiguity.

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 and openWorldHint. The description adds behavioral details like 'recomputable from public Base RPC + CDP catalog', 'daily crawl cadence', and 'honest levers', providing full transparency.

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 slightly verbose but front-loaded with essential information. Every sentence adds value, though it could be streamlined slightly.

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?

Despite no output schema, the description enumerates the specific outputs for both modes. It is complete 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?

Schema has 100% coverage, but the description adds significant meaning: it explains what each parameter returns (e.g., catalog-walker vs real-customer verdict for wallet, discoverability audit for resource).

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 seller intelligence with two distinct modes: wallet behavior analysis and resource discoverability audit. It uses specific verbs like 'pass' and explains the outputs, distinguishing it from sibling tools.

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 guidance on when to use each parameter (wallet for behavior, resource for audit). It does not explicitly mention when not to use or alternatives, but context is strong.

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 and openWorldHint. The description adds 'Live' and 'facts-only, non-advice,' and notes it uses 'the same venue + regime gate we trade.' This provides some behavioral context beyond annotations but does not disclose response structure or caching behavior.

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 verbose and contains an unclear, technical run-on sentence about 'Bitcoin earner gates' and a formula. It lacks a clear front-loaded purpose statement and would benefit from being more concise and 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?

The description enumerates the data fields to be returned, which is helpful given the lack of an output schema. However, it omits the exact format of the response and contains an obscure phrase, leaving some ambiguity about completeness.

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 parameter 'coins' is described in the schema. The description names default coins (BTC/ETH/SOL/XRP) and mentions 'Multi-coin,' but adds little beyond the schema. 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 lists the specific data points provided (funding rate, open interest, etc.) and states it's for Hyperliquid derivatives. However, it lacks a direct verb like 'get' or 'retrieve' and contains a confusing phrase about 'Bitcoin earner gates,' which slightly undermines clarity.

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 no guidance on when to use this tool versus its siblings (e.g., agent_economy_brief, decision). It does not mention alternatives or exclusions, leaving the agent to infer usage without context.

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 indicate readOnlyHint=true, idempotentHint=true. The description adds detailed behavioral traits: it recomputes Nostr event id, checks Schnorr signature, confirms pubkey, and returns validation checks. It also states 'Free, no auth' and describes the trust handshake purpose, going well 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?

The description is front-loaded with the primary use case and is informative. While somewhat lengthy, it is well-structured and every sentence adds value, but could be slightly more concise.

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 complexity of cryptographic verification and no output schema, the description fully explains the tool's behavior, verification steps, return format, and the broader context of agent-to-agent trust. It is complete for an AI agent to use 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 covers 100% of parameters with descriptions. The description adds context: explains 'event' as the signed proof from /prove or /review response, 'proof_id' as alternative, and 'expect_artifact_hash' as sha256 of the received output, enhancing meaning over schema alone.

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 verifies a signed proof event from invinoveritas. It specifies the verb 'verify' and the resource 'proof', and distinguishes itself from sibling tools like 'prove' which would generate proofs.

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 explicitly says 'CALL THIS WHEN another agent hands you output and claims it was verified by invinoveritas.' It provides when to use and optional parameters, but does not explicitly state when not to use, though context implies it's only for verification.

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 include destructiveHint: true, so the description adds minimal value beyond stating it's free and urging responsibility. No details on permissions, irreversibility, or recovery.

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 short sentences with no wasted words, directly delivering the purpose, cost, and a usage admonition.

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 delete tool with destructive hint, the description covers key aspects (what, cost). It could mention permanence or error handling, but overall sufficient given the tool's simplicity.

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%, and the description adds no extra meaning beyond the schema's parameter descriptions.

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 'Delete a file or directory from your persistent workspace' with a specific verb and resource, clearly distinguishing it from sibling tools like workspace_list and workspace_status.

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 says 'Use responsibly' but provides no explicit guidance on when to use this tool versus alternatives (e.g., memory_delete) or any prerequisites.

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=true and openWorldHint=false. Description adds that it is 'Free' and useful for specific tasks, but no additional behavioral traits beyond what annotations provide.

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 fluff, front-loaded with key purpose. 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's simplicity (2 params, no output schema), the description fully covers the context needed to use 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 coverage is 100% with complete parameter descriptions. The tool description does not add semantic meaning beyond 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?

Description clearly states the verb 'List', resource 'files and directories', and context 'persistent execution workspace'. It distinguishes from siblings by specifying the workspace context.

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 positive guidance ('extremely useful for multi-step coding, data work, and repo-based agents') but lacks explicit when-not-to-use or alternatives to sibling 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?

The description is consistent with the readOnlyHint annotation (true) and adds no further behavioral details. Since the annotation already indicates a safe read operation, the description adds minimal value beyond stating the 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 concise, consisting of two short sentences that front-load the important information. There is no unnecessary 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?

For a simple read-only tool with no output schema, the description is sufficiently complete. It specifies the return values and suggests a practical use case, covering the necessary contextual information.

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 covers the only parameter (agent_id) with a description 'Your agent identifier'. The tool description does not add additional meaning or constraints beyond what the schema provides, 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 the tool's purpose: 'Get basic status of your persistent workspace' and lists the specific metrics returned (total size, file count, last modified). It distinguishes from sibling tools like workspace_delete and workspace_list.

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 a clear use case: 'Very useful before deciding to clean up.' This tells the agent when to use this tool, though it doesn't explicitly mention when not to use it or provide direct alternatives.

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