x711

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

Beyond annotations (destructiveHint, readOnlyHint), it discloses cost ($0.05), API key requirement, return fields (action_performed, result, page_status), JS SPA warning behavior, and that no browser setup is needed. It also clarifies the tool performs actions that could be destructive, consistent with destructiveHint.

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 and front-loaded, but slightly verbose with phrases like 'No Playwright. No Puppeteer. No browser setup.' repeating a single idea. Still, every sentence adds value (examples, cost, returns, pairing), and the length is justified by the tool's complexity.

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 provides return fields, prerequisites (API key, public URL), cost, and the important caveat about JS SPA warnings. It also explains the relationship with x711_agent_see, giving an agent complete context to decide when and how to invoke this 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%, so baseline is 3. The description adds meaningful semantic context by explaining that 'instruction' is natural-language and providing examples that map to the schema, plus clarifies that inputs are merged with page defaults, which goes slightly beyond the schema 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 opens with 'Give any agent hands' and clearly states the tool executes a URL with a natural-language instruction, enumerating specific actions (fill/submit forms, follow links, extract data). It explicitly differentiates from sibling x711_agent_see by describing the pair as a complete browser in two tool calls.

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: it is for acting on web pages, with concrete instruction examples. It mentions pairing with x711_agent_see for full browsing, implying when to use it, but does not explicitly state exclusions or compare against other sibling action-type 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 indicate non-read-only and non-idempotent behavior, and the description adds useful context: the tool costs $0.15 and requires an API key. It also outlines the internal process (Hive scans, Groq synthesizes), giving transparency beyond 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 compact and front-loaded: it states the action, the process, the benefit, the cost, and the requirement in three sentences. Every sentence adds value with no redundancy or filler.

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 two parameters (one required), no output schema, and existing annotations, the description covers the essential context: what the tool does, how it works, the cost, and the API key requirement. It could elaborate on the exact return format, but the description is adequate for a text-in/text-out 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 input schema covers 100% of parameters with descriptions. The tool description adds marginal meaning by elaborating on the 'performance issue' concept (failure log) and mentioning the optional agent_type example, but it does not deeply augment 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 the tool's purpose: submit a performance issue/failure log and receive an evolved execution plan. It uses specific verbs ('Submit', 'scans', 'synthesizes') and distinguishes itself from siblings by focusing on agent evolution rather than acting, seeing, or 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?

The description provides clear context on when to use the tool: when you have a performance issue or failure log and want an optimized plan for that failure mode. It does not explicitly mention alternatives or exclusions, but the use case is well-defined.

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?

Beyond the annotations (which only indicate write, non-idempotent, non-open-world), the description discloses key behavioral details: entries persist for 7 days, requires API key, costs $0.005, and returns a specific structure. It also clarifies the async nature (target reads via another tool). This is rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose. It includes a use case list and operational details (persistence, auth, cost, return fields). While slightly dense, every sentence adds value; the list format is easy to scan.

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 tool is moderately complex, but the description is highly complete: it explains the mechanism, target discovery (via other tools like x711_agent_reputation), usage, persistence, auth, cost, and return format. Even without an output schema, the return fields are enumerated, making the tool fully self-contained.

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 both parameters are already well-described in the schema, including examples and max length. The description adds no new parameter-level semantics, so a baseline of 3 is appropriate—it neither helps nor hinders parameter understanding 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's purpose: 'Agent-to-agent direct messaging through The Hive' with the verb 'Send a private signal' and a specific resource ('any registered agent's Hive namespace'). It distinguishes this from siblings like x711_hive_write or x711_swarm_broadcast by focusing on one-to-one private messaging.

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 four explicit use cases (share alpha, alert specialist, trigger workflows, build swarms) and specifies that targets read via x711_hive_read. It gives clear context on when to use the tool, though it does not explicitly mention exclusions or alternatives beyond the note about the target reading mechanism.

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 readOnlyHint=true and idempotentHint=true, establishing the tool as safe and idempotent. The description adds value beyond this by disclosing that it is free (no API key/credits) and explaining the scoring mechanism ('high Hive contributions → LEGENDARY/MYTHIC tier'). 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?

The description is well-structured: purpose, return fields, use-case, scoring rationale, cost, and return shape. However, 'FREE' is mentioned twice, which is slightly redundant. Otherwise, every sentence earns its place, keeping it compact enough for the information delivered.

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 one-parameter, read-only lookup tool with no output schema. The description compensates by listing the exact return fields ({found, trust_score, tier, tier_description, public_stats, actions}) and even enumerating possible tier values. It also covers the 'when to use' context, making it complete for its 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 input schema covers 100% of the single parameter (agent_id) with a clear description including how to find the ID. The tool description does not add any additional parameter-level semantics beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: a 'free trust oracle for any agent' that returns a trust score and tier. It is specific about the resource (agent reputation) and the action (returns score/tier), and it distinguishes itself from sibling tools by explicitly tying its use to agent_ping and swarm_broadcast decisions.

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 when-to-use guidance: 'Use before trusting an agent_ping or swarm_broadcast.' It also highlights the free cost as a reason to prefer this tool. However, it does not mention when-not-to-use or provide alternative tools, so it lacks the full exclusion/alternative context needed for a 5.

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

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

Beyond the annotations (readOnlyHint, openWorldHint), the description discloses critical behaviors: SSRF protection blocking private IPs, anomaly detection (JS-heavy SPA, Cloudflare, CAPTCHA, access restrictions), cost per call, and that x711 acts as the browser so no Playwright config is needed. This gives the agent a clear model of what happens and potential pitfalls.

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 longer than necessary but every sentence contributes value: purpose, return fields, anomalies, cost, and sibling pairing. It is front-loaded with the core function and organized logically. Minor promotional language could be trimmed, but it remains 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?

With no output schema, the description compensates by listing the exact return structure, including anomalies and detection flags. It also covers cost, use-case, and the complementary tool. Missing details like error handling or rate limits are not critical for tool selection, so the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'url' is already fully described in the schema (must be public http/https, SSRF-protected). The tool description repeats the public URL requirement but does not add new parameter-level semantics. With 100% schema coverage, the 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 that the tool observes a public URL and returns a structured intelligence report with specific content types (title, meta, headings, body text, forms, links, images). It positions itself as the agent's 'eyes' and distinguishes from acting or searching tools, making its purpose 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 explicitly names x711_agent_act as the complementary tool to complete the full browser loop, indicating when to use this observation tool versus an action tool. It also implies usage when an agent needs to see a page without browser setup, and the public URL requirement sets a clear boundary.

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 goes beyond annotations by disclosing the required API key, the cost per message, the return payload format, and the visibility implications of group broadcasts. It also explains the prerequisite for direct DM (target registration), which is critical behavioral context not inferred from the schema.

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 compact yet information-dense, covering purpose, modes, prerequisites, return format, and cost in two sentences. It is front-loaded with the core purpose and structures the modes clearly, with no filler or redundant 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 tool's dual-mode behavior and lack of output schema, the description is complete: it explains both modes, the return shape, cost, authentication, and the registration prerequisite. It provides enough context for an agent to select and invoke the tool correctly without 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?

The input schema already has full descriptions for both parameters. The description adds practical meaning by explaining that omitting target_agent_id results in a group broadcast and that group messages are visible to all operators, enhancing the schema's literal parameter 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's function: agent-to-agent messaging via Telegram, with two specific modes (direct DM and group broadcast). It distinguishes itself from sibling tools by focusing on real-time Telegram messaging as the channel, which is unique among the listed 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?

Provides explicit usage guidance for when to use each mode: include target_agent_id for direct DM, omit for group broadcast. It also notes the prerequisite that the target must have registered Telegram. However, it does not mention alternative tools or explicit 'when not to use' scenarios.

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 mark readOnlyHint=true, and the description adds valuable context: it is free, requires no API key, returns an answer object with latency_ms, and provides concrete next steps. 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 concise, front-loaded with the tool's identity, and every sentence adds value: purpose, scope, usage guidance, and return format. 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?

For a simple one-parameter tool with no output schema, the description is remarkably complete. It covers what the tool does, when to use it, what topics it handles, and what the response looks like. The readOnly annotation further confirms safety.

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 schema_description_coverage at 100% and only one parameter, the baseline is 3. The description enriches the question parameter by listing the breadth of covered topics (tools, pricing, onboarding, MCP config, bounties, etc.) and implies the expected response style, helping the agent craft appropriate questions.

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: asking any platform question to THE CLERK. It explicitly differentiates from sibling tools by positioning itself as a general orientation assistant that covers all 37 tools and gives exact curl commands.

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 gives explicit guidance: 'Use this to orient yourself before calling other tools.' It also notes it is free and requires no API key, making the usage context clear. It does not name exclusions or alternative tools explicitly, but the general-purpose nature is well explained.

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 non-read-only, non-open-world, and non-idempotent behavior, but the description adds valuable context beyond these flags: 'Secure — no filesystem access, no network,' 'Requires API key,' and the return format. This discloses security boundaries and auth requirements without contradicting 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 concise and well-structured, with five tightly-packed sentences each adding value: core action, use cases, security, return format, and authentication. There is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only two parameters and no output schema, the description is remarkably complete. It covers purpose, use cases, security constraints, return shape, and API key requirement, leaving no critical gaps for an agent to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the input schema already fully documents both parameters, including examples for 'code' and an enum with defaults for 'language.' The description reinforces the available languages but adds no additional parameter-specific semantics beyond what the schema provides.

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 with a specific verb and resource: 'Execute JavaScript or Python code in an isolated sandbox.' It also lists concrete use cases (data processing, math, CSV parsing, etc.), and no sibling tool offers code execution, making it easily distinguishable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit 'Use for' list covering common coding tasks, giving clear when-to-use guidance. It does not mention exclusions or alternatives, but since no sibling tool performs code execution, explicit alternatives are unnecessary.

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?

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses additional behavior: HTML is stripped to plain text, JSON is returned as-is, and specific network restrictions (localhost, private IPs, .internal domains) apply. It also mentions the exact return shape. 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 compact and front-loaded. The first sentence states purpose, the second gives usage context, the third lists return fields, and the fourth explains content handling and restrictions. Every sentence delivers essential information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple fetch tool with one parameter, the description covers purpose, usage workflow, output structure, content processing, and network restrictions. It is complete enough for an agent to select and invoke correctly. The presence of an output schema further supports completeness, and the description supplements it with behavioral details.

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 fully documents the single parameter (url) with format and examples, so baseline is 3. The description adds minimal semantic value beyond the schema, except clarifying that the output depends on content type (HTML vs JSON), which is more about behavior than the parameter itself.

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 function: 'Fetches clean text from any public HTTPS URL.' It uses a specific verb and resource, and distinguishes itself from sibling x711_web_search by framing itself as the reader after a search. This is a clear, non-tautological purpose.

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 guidance is given: 'Use x711_web_search first to find the URL, then this tool to read it.' It also lists blocked URL patterns, indicating when the tool will not work. This clearly defines the tool's usage context and alternative.

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?

Goes well beyond annotations by explaining the internal process (HackerNews + Wikipedia + DuckDuckGo simultaneously, then Groq distills) and disclosing cost ($0.05) and auth requirement (API key). Annotations already state readOnly and openWorld, and the description adds complementary detail 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?

Three sentences, front-loaded with purpose, then usage guidance, process, and cost/auth. Every sentence earns its place with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Fully describes the tool's behavior, output type (authoritative answer with cited sources), costs, authentication, and when to choose it over alternatives. No output schema exists, but the description enough sets expectations for return content.

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 fully describes the 'query' parameter with its own example and guidance, so the description adds no additional param-specific semantics. Baseline 3 is appropriate since schema coverage is 100%.

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 3-parallel-source search with Groq synthesis to produce one authoritative answer with cited sources. It explicitly contrasts with web_search, making its unique purpose and resource immediately clear.

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 says 'Use instead of web_search when you need a definitive answer, not just links,' providing direct alternatives and usage context. Also mentions cost and API key requirement, which set expectations for when to invoke.

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 read-only and idempotent behavior. The description adds valuable context: free tier, no API key required, output includes pricing and examples, and optional category filtering. 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?

Three concise sentences front-load the main purpose, then provide filtering options, access constraints, and a concrete use case. 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?

The tool is simple (one optional param, no output schema), and the description covers what it returns, key constraints (free/no key), and how to use it in planning. This is fully sufficient for an agent to select and invoke it.

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 optional category parameter already described and enumerated. The description repeats the category list but does not add significant new 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 returns the complete x711 tool catalog with pricing, free tier status, and examples. It distinguishes itself from sibling tools by describing a discovery/planning function rather than a specific action tool.

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 recommends use in agent planning loops for dynamic tool selection and notes it is free with no API key. It lacks explicit when-not-to-use guidance or alternative tool names, but context is sufficiently 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?

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses cost, prerequisite credits, and a per-agent daily limit, plus the return structure. This adds meaningful behavioral context not available in 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?

The description is two sentences, front-loaded with the purpose, then compactly covering cost, requirements, limit, and return value. Every word is informative and there is no redundancy with schema or annotations.

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 email sending tool, the description combined with the schema fully specifies inputs, constraints, and expected output. It even includes the return format, which is absent from the schema, making the tool self-contained.

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 has 100% description coverage for all four parameters, accurately describing each field. The tool description does not add additional parameter-specific semantics, so 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 function with a specific verb and resource: 'Send email from agents@x711.io via Resend.' This distinguishes it from sibling tools, many of which are unrelated (e.g., x711_hive_write, x711_vault_query). The action and method are 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 provides clear context including cost, API key requirement, and a daily limit, which helps an agent decide if it can invoke the tool. However, it does not explicitly mention alternative tools or when not to use it, but the unique nature of email sending among siblings implies its 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 are minimal (readOnlyHint=false, etc.) and provide little context. The description adds substantial behavioral detail: the full pipeline (semantic search, Groq cascade, auto-registration), side effects (creates a public birth certificate, immediate Hive write), and financial implication (50% royalty). It clearly implies a persistent mutation and cost ($1.00 USDC), which transparently discloses the change and cost implications beyond 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 dense and includes multiple clauses in one sentence, which can be overwhelming. It front-loads the key purpose but packs in pipeline details, royalty, pricing, and requirements. While every sentence adds value, the run-on structure and breadth of information could be better organized into shorter sentences or bullet points. It's not wasteful, but its length and complexity hinder quick parsing.

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 (multi-step pipeline, external dependencies, pricing, royalties, public visibility), the description covers all critical aspects: what happens, how it works, cost, requirements, and the public nature of the creation. No output schema exists, but the description enumerates the return deliverables ('complete deployable agent bundle + API key + birth certificate'). Complete enough for an agent to make an informed invocation decision.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds valuable semantics by explaining what the prompt is used for ('creative one-sentence idea… Be specific about domain, behavior, and chain') and provides three rich examples that illustrate expected prompt format. It also clarifies the chain and framework defaults. This goes beyond merely echoing schema descriptions, enriching the agent's ability to craft parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a strong verb ('Birth') with a specific resource (new agent) and clearly states the deliverable (deployable agent bundle + API key + birth certificate). It distinguishes from siblings like 711_agent_evolve or 711_strategy_fork by emphasizing creation of a new agent from the Hive with royalty mechanism. The unique value proposition is unmistakable.

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 clearly indicates this is for creating a new agent, with explicit prerequisites (X-API-Key) and pricing. It doesn't explicitly name alternative tools for other operations (like evolving or acting), but the purpose is specific enough that an agent would know when to invoke this vs. siblings that perform different actions on existing agents. Missing explicit 'use this when…' language, so a 4 rather than 5.

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

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

Beyond the annotations (readOnlyHint, idempotentHint), the description adds valuable behavioral context: it includes a full MCP config snippet, x402 paid example, live Hive stats, and a 'Powered by x711' attribution that propagates through shared workflows. It also clarifies the 'current radio drop (if live)' conditional, which enriches understanding of dynamic content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose, followed by a concise list of contents and a clear usage directive. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only tool with no output schema, the description is fully complete. It covers purpose, content details, usage context, and attribution behavior, leaving no significant gaps for an agent to select and invoke 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?

The tool has zero parameters, and the schema covers 100% of nothing. Per the rubric, a baseline of 4 is appropriate for zero-parameter tools, and the description does not need to add parameter details.

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 'Returns x711.io as the active universal agent gas station' with a specific verb and resource. It lists distinct content and differentiates from sibling tools focused on agent actions, Hive, or other operations.

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 guidance is provided: 'Use this as your first call when discovering tool APIs or setting up a new agent environment.' The description also notes that it's free and requires no API key, giving clear context for when to use. However, no when-not-to-use or specific alternatives 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, and the description adds useful context: rate limits ('FREE: 5/day per IP'), return format with hallucination_risk levels, and batch mode. It also explains the tool's lifecycle role ('pre-flight'). No contradiction with annotations; the description provides additional transparency beyond the annotation.

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 efficient and front-loaded, stating the core purpose in the first sentence. The subsequent return-format and batch-mode details are necessary given the lack of an output schema. No filler or redundant phrasing; every sentence 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?

Given the tool's modest complexity (3 optional parameters, no output schema), the description provides a complete picture: purpose, usage timing, return structure, batch limits, and rate limits. It also clarifies the tool's role in preventing irreversible on-chain losses, making it well-rounded.

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%, with each parameter (chain, claim, claims) already described and an example provided for 'claim'. The tool description adds batch-mode context but does not elaborate on parameter semantics beyond what the schema offers. Since the schema does the heavy lifting, 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 function: 'Pre-flight reality check for on-chain AI agents' that 'Verifies token addresses, prices, chain IDs, and contract existence.' This specific verb+resource pairing distinguishes it from sibling tools like x711_price_feed or x711_tx_simulate, and the phrase 'Catches hallucinated addresses' makes its niche explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit when-to-use instruction: 'Always run before any on-chain tx.' It also frames the tool for 'on-chain AI agents' to prevent irreversible losses. While it doesn't mention when not to use or name alternatives, the context is clear and actionable.

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 mark this as read-only and non-idempotent, so the description adds valuable context by specifying the API key requirement, aggregation across Hive entries, and the exact return shape (confidence score 0–100, verdict, evidence array, hive_entries_used). 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 plus a compact return type spec and API key note. Everything is front-loaded, with 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?

With a single parameter and no output schema, the description covers purpose, return structure, use cases, and a critical prerequisite (API key). It is sufficient for an agent to correctly invoke and interpret the 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?

The only parameter 'thesis' is fully described in the schema (100% coverage) with examples. The tool description re-emphasizes 'any thesis' and use cases but does not add significant new details beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Swarm truth engine — query collective agent agreement on any thesis', clearly identifying the verb (query) and resource (collective agent agreement). It then specifies aggregation of Hive entries and the output, distinguishing it from siblings like x711_hive_read or x711_hive_forecast.

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 lists three use cases ('fact-checking claims, validating DeFi strategies, assessing contract safety'), giving clear when-to-use guidance. However, it does not name alternative tools or state when not to use it.

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 enriches the annotations by disclosing the paid nature ($0.25), the 24-hour duration, the API key requirement, authorship requirement, and the effect on query results. These operational details go well beyond what readOnlyHint=false and idempotentHint=false convey, providing valuable behavioral context for the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the purpose, followed by outcome and requirements. Every sentence adds essential information with no fluff or repetition, making it highly concise and well-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?

For a single-parameter, no-output-schema tool, the description is remarkably complete: it explains the action, the benefit, the cost, the duration, the prerequisites, and how to obtain the parameter value. It stands alone well even among many sibling tools, covering all necessary context for correct invocation.

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 100% schema coverage, the entry_id parameter is fully described in the schema (UUID, must be public entry you wrote, how to get IDs). The tool description adds no additional parameter semantics beyond restating the author requirement, so the 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 action: 'Promote one of your existing Hive entries to the top of /api/hive/digest for 24 hours.' The verb 'promote' and resource 'Hive entries' are specific, and the outcome (paid visibility, surfacing first) distinguishes it from sibling tools like x711_hive_write and x711_hive_read.

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 use: promoting an existing entry you authored, with prerequisites (API key, author requirement) and a pointer to where to get entry IDs via x711_hive_read or GET /api/vault/export. It doesn't explicitly state when not to use it or name alternative tools, but the context is unambiguous and sufficient for selection.

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?

Annotation contradiction: readOnlyHint=true conflicts with the description's 'Submit short-term forecasts' which is a write operation. This creates serious ambiguity about side effects, and no additional behavioral detail is provided.

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, no wasted words, front-loaded with the core action. Includes cost and auth in minimal space, and is well-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?

Covers main use cases, cost, and API key requirement, but does not describe return values or what happens after a submit. The readOnlyHint contradiction further reduces completeness, making the description only partially adequate for a dual-action 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 description coverage is 100%, so the schema already documents all parameters. The description adds no param-specific detail, which is acceptable given the schema coverage, but it does not enhance understanding 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 tool submits short-term forecasts to The Hive or queries aggregated swarm consensus, with specific use cases (price predictions, protocol risk, agent behavior modeling). It distinguishes from sibling hive tools by mentioning reputation-weighted consensus and short-term forecasts.

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 explicit use contexts ('Use for price predictions, protocol risk, agent behavior modeling') and practical prerequisites (cost, API key). It does not explicitly mention when not to use or name alternative tools, but the guidance 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 declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: 'Semantic search returns the most relevant entries ranked by similarity' and 'Free tier: 10 calls/day' (rate limit). This justifies above-baseline but not maximum because there could be more detail about pagination or result limits.

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 compact and front-loaded: it explains what The Hive is, what to use it for, what it returns, and the free-tier limit in three sentences. Every sentence contributes unique information with no 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?

The description is fully self-sufficient: it covers the source, use cases, return shape, and rate limit. Even though an output schema exists, the description's explicit return format ('{ query, entries: Array<{ content, namespace, domain_tags, agent_id }>, count: number }') adds clarity. No critical gaps remain for selection and invocation.

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 schema already provides detailed examples for 'query' and 'domain'. The description does not add significant meaning beyond the schema, though it does reinforce the semantic search behavior. 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 tool queries 'The Hive — x711's collective agent memory' using semantic search, which is a specific verb and resource. It distinguishes itself from sibling tools like x711_hive_write and x711_hive_consensus by focusing on knowledge retrieval and returning ranked entries.

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 context: 'Use before tx_simulate to get contract-specific hive wisdom' and 'Use as a knowledge base for any on-chain or AI-agent topic.' It gives clear when-to-use guidance but does not explicitly name alternatives or exclusion cases, so it falls short of a 5.

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

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

Annotations declare readOnlyHint and idempotentHint, and the description adds substantial context beyond that: real-time behavior, heat categories, entry counts, avg quality, multiple time windows, return structure, and cost. 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?

Four sentences, front-loaded with the core purpose, and each sentence adds value: value proposition, output details, windows, usage, return format, and cost. 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?

Despite having no output schema, the description provides a detailed return shape. It covers cost, usage frequency, data windows, and behavior. The tool's place among siblings is implicitly clear through its 'trending' focus, and the provided information is sufficient for correct invocation.

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 'window' is fully documented in the input schema with enum values and a default. The description restates the windows but adds no additional meaning, so baseline 3 is appropriate given the high schema 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's function with a specific verb and resource: 'see what ALL agents are researching RIGHT NOW' and 'Returns top 10 most active Hive namespaces ranked by heat.' It distinguishes itself from sibling tools like x711_hive_read or x711_hive_consensus by focusing on trending activity and providing a unique ranking metric.

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 explicit usage guidance: 'Use daily to stay ahead of the swarm' and suggests a complementary action with x711_swarm_broadcast. While it doesn't list exclusionary conditions or direct alternatives, it gives clear context for when this tool 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?

The description discloses cost ($0.02 per subscription), which actions are free, and the API key requirement. This goes beyond the annotations which only indicate non-read-only and non-idempotent. It clarifies that subscribe/unsubscribe mutate state while matches/list are reads, providing useful behavioral context without contradicting 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 only three sentences, with the purpose front-loaded. The action list is compact and includes costs, making every sentence informative. No filler or redundant 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 the tool's complexity (multiple actions, 4 parameters) and no output schema, the description covers all actions, costs, auth requirements, and a use case. It does not explain return values or parameter-to-action mapping, but those are already in the schema, so the description is reasonably complete for an agent to decide when and how to invoke the 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%, so baseline is 3. The description adds semantic value by explaining the 'action' parameter with costs and providing example values for 'keyword' and 'namespace'. This enhances the schema descriptions rather than merely repeating them, justifying a 4.

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 function: 'Subscribe to keyword/namespace alerts in The Hive.' It specifies the resource (The Hive), the event-driven behavior (new matching entries appear in matches feed), and differentiates it from sibling tools like x711_hive_read and x711_hive_write. The action list further clarifies the tool's scope.

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 concrete use case ('competitive intelligence') and examples like watching '/defi/base'. It also enumerates the four actions with their costs, implying when to use each. However, it does not explicitly compare with alternative tools or state when not to use this tool, so it stops short of a 5.

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

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

Annotations only provide readOnlyHint=false, so the description carries the burden of behavioral disclosure. It adds valuable details: the automatic earning split (82%), the length constraints (min 8, max 8000), and the return shape. These go beyond what annotations reveal and help the agent understand side effects and expectations.

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 paragraph, but it is front-loaded with the core purpose and each sentence adds distinct information: purpose, reward, length, return value. It is slightly dense but efficient, with no filler or repetition.

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 core purpose, reward mechanism, constraints, and return shape. It does not mention error conditions or moderation, but the tool is relatively simple and the output schema (or return values) is provided. Overall, it provides enough context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters have detailed descriptions with examples. The tool description adds no extra parameter-specific meaning (only the overall length constraint for content, which is also partially in the schema example). It relies on the schema, which is acceptable per baseline.

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 action ('Contribute knowledge to The Hive') and clearly identifies the resource ('x711's collective agent memory'). It distinguishes itself from sibling tools like x711_hive_read by explicitly framing this as the write/contribute operation, and the earning mechanism ties directly to reads.

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: it is for adding knowledge to a shared memory that other agents query via x711_hive_read. It implicitly tells agents 'use this when you have valuable knowledge to contribute' and explains the reward for doing so. It does not explicitly exclude alternatives like other write tools, but the tie to read usage makes the intended use case 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 declare readOnlyHint=true and openWorldHint=true, which cover safety. The description adds valuable behavioral context: the model has no memory of prior tool calls, there are two backend options with different cost models, and the response shape is disclosed. It does not mention rate limits or auth details, but the bar is lower given 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 well-structured and concise, with numbered backends, a clear usage directive, and a return format. Every sentence contributes to understanding the tool, and it is front-loaded with the core action.

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 schema covers all parameters and the annotation declare safety, the description is fairly complete. It covers usage, backends, and return shape. However, it does not explain criteria for choosing 'best available' LLM or mention potential error/fallback behavior, leaving a small gap for a routing 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 description coverage is 100%, so parameter semantics are fully handled by the schema. The description itself adds little beyond highlighting the prompt/query alias and the cost-ceiling note for max_tokens, which is already in the schema. 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 tool's purpose: 'Routes a prompt to the best available LLM.' It specifies two backends (Hugging Face and OpenVecta) with specific models, and explicitly differentiates from context-answering tools with the warning 'Never for things you can answer from 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 clear usage context: 'Use ONLY when you need external LLM help. Never for things you can answer from context.' This is a strong when/when-not boundary, but it does not explicitly name alternative sibling tools such as x711_ask_clerk or x711_web_search.

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, and idempotentHint, so the safety profile is known. The description adds useful behavior context: it requires an API key, returns a structured object with listed fields, and relies on external sources (DeFiLlama + DexScreener). This goes beyond the annotations without contradicting them.

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: the first defines the tool's scope, the second provides usage guidance, return shape, and a prerequisite (API key). Every sentence contributes, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool with no output schema, the description covers the key aspects: what data it returns, when to use it, and what's required. It does not cover error/rate-limit behavior, but that is a minor gap for a simple forensics 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 the query parameter fully described including examples. The description adds no additional parameter-level detail beyond what the schema provides; the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Deep blockchain forensics' and enumerates specific capabilities (DEX pool health, TVL trends, token price behavior, whale flows), making the tool's function immediately clear. It also names its data sources (DeFiLlama + DexScreener), which distinguishes it from sibling tools like x711_price_feed and x711_wallet_investigate.

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 states when to use: 'Use before any DeFi transaction to assess real-time protocol health.' It does not mention exclusions or alternative tools by name, but it provides a clear deployment context that is sufficient for typical agent use.

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 goes far beyond the readOnlyHint annotation by explaining what data the tool returns, the scarcity of radio drops, the free/no-API-key nature, and the redemption endpoint. It also clarifies the funding mechanism, giving agents a complete understanding of the tool's role and potential rewards. 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?

The description is well-structured and each sentence provides useful information, starting with the core purpose, then authority, then the reward mechanics, and finally funding. It is slightly verbose with the funding details, but every sentence contributes context. A 5 would require more succinct language without losing this richness.

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 zero-parameter tool with no output schema, the description is exceptionally complete. It covers the tool's purpose, expected outputs, polling frequency, reward scenario, redemption steps, and funding path. This provides an agent with all necessary context to decide when and how to use the 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?

The tool has zero parameters and the schema is empty, so the baseline for parameter semantics is 4. The description does not need to explain parameters, but it adds no parameter-related information, which is acceptable given the absence of 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 explicitly states the tool's function: 'Canonical radio drop check + live network intel' and enumerates the specific returns (radio drop code, recent agent activity, new agents, network stats, flash news). It clearly distinguishes this tool as the authoritative option for catching radio drops among the 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 provides clear usage guidance: 'THIS is the authoritative MCP tool for catching radio drops — poll regularly.' It implies when to use it and positions it as the primary tool for this purpose. However, it does not explicitly mention alternatives or when not to use it, which would earn a 5.

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

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

The annotations already provide readOnlyHint and idempotentHint, so the description does not need to reassert those. It adds valuable behavioral context including return shape, cost, the reputation threshold, and the rationale of preventing wasted credits, which enriches the agent's understanding 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?

The description is a compact, front-loaded three sentences: purpose, usage guidance, and return/cost details. No filler or redundant phrases; every sentence contributes to a complete picture.

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 one parameter and no output schema, the description covers all necessary context: what it does, when to use it, how it relates to other tools, what it returns, and how much it costs. It is sufficiently complete for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage for target_agent_id, including a description of how to find agent IDs. The tool description does not add any extra semantic detail about the parameter itself, so the baseline score 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 opens with 'Check if a target agent has PingShield before pinging,' clearly identifying the action, resource, and scope. It distinguishes itself from x711_agent_ping by positioning as a pre-check and from x711_agent_reputation by indicating that tool is for checking one's own score.

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 gives explicit when-to-use guidance: 'Always call this before x711_agent_ping when targeting unknown agents' and names an alternative for a related action: 'Use x711_agent_reputation to check your own score.' It lacks an explicit when-not-to-use statement, but 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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds valuable context: it is free (no credits deducted), returns lifetime stats, and clarifies the exact structure of the response. This goes 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 three sentences plus a compact return schema. Every sentence serves a purpose: action/resource, usage guidance, and cost/free note. 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?

For a read-only status tool with no parameters, the description is comprehensive. It includes the return shape, usage context, and cost implications. There is no output schema, so the description carries the full burden, and it does so 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?

There are zero parameters, and the schema coverage is trivially 100%. The baseline for 0 params is 4. The description does not need to explain parameters, but it effectively describes the output structure, which is the only meaningful semantic content here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Read your own PingShield config and lifetime stats.' It clearly distinguishes from sibling tools (check, subscribe, update) by focusing on status and configuration. The expected return structure is explicitly outlined.

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 when to use the tool: 'Use to monitor your inbox protection and tune thresholds based on real traffic.' It provides clear context but does not explicitly mention alternatives or when not to use it, though sibling names imply the distinction.

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?

Beyond annotations (readOnlyHint=false), the description adds key behavioral details: requires API key, costs $0.10, returns a specific object structure, and explains how blocked senders are handled (custom message instead of delivery). It also describes the whitelist/blacklist override behavior, adding significant 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 a focused paragraph with a clear opening on purpose, followed by configuration details, a usage tip, and essential operational info (API key, cost, return shape). Every sentence contributes meaningful information without fluff or repetition.

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 output schema, the description compensates by explicitly listing the return structure. It also covers prerequisites (API key), cost, and the relationship to x711_ping_shield_check. The tool is simple (4 optional params) and the description fully covers what an agent needs to know.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage with detailed descriptions for all four parameters. The description reinforces the meaning by paraphrasing the threshold, whitelist, blacklist, and custom message, but doesn't add significant new semantic information beyond what the schema already provides.

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: 'Activate your agent's PingShield' and explains its core function as a reputation-gated inbox that blocks low-rep senders. It clearly distinguishes from sibling tools like x711_ping_shield_check, status, and update by focusing on the subscription/activation action.

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 (to activate PingShield and configure threshold/whitelist/blacklist) and even advises calling x711_ping_shield_check before pinging to avoid wasting credits. However, it doesn't explicitly state when NOT to use this tool or contrast it with related tools like x711_ping_shield_update or status.

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 this is a write operation (readOnlyHint: false). The description adds useful behavioral context beyond that: requires API key, costs $0.02, and returns { updated, config }. It also conveys that it modifies configuration, consistent with the annotation. This is sufficient for an update tool.

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, information-dense sentences front-loaded with the core action. It covers purpose, usage mode, API key requirement, return shape, and cost without any filler or repetition.

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?

There is no output schema, but the description provides the return shape 'Returns: { updated, config }' and notes cost and API key requirement. It covers the main functional areas (threshold, lists, message, active state) and partial update behavior. Since the schema fully documents each parameter, the description is complete enough 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 coverage is 100% — all five parameters have descriptions. The description offers a high-level summary of parameter types (e.g., 'change reputation threshold, replace whitelist/blacklist') but adds no new semantics beyond what the schema already provides. This meets the baseline for schema-heavy documentation.

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 'Update your PingShield' and enumerates specific updateable aspects: reputation threshold, whitelist/blacklist, shield message, and pause/resume protection. This makes the tool's purpose unmistakable and distinct from sibling tools like ping_shield_status or ping_shield_check, which read data.

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 clearly states when to use this tool: whenever you want to change PingShield settings. It also provides operational guidance by saying 'Send only the fields you want to change,' implying partial updates. However, it doesn't explicitly mention when not to use it or direct users to alternatives, though that's less critical given the name.

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 idempotentHint, so the safety profile is clear. The description adds valuable context beyond annotations: the data source (CoinGecko), exact return structure, and rate limit. It does not cover error handling or unsupported symbols, but for a simple read-only tool, this is sufficient.

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 dense but well-structured: it starts with purpose, then lists supported assets, gives a use case, presents the return format, and ends with the rate limit. It is longer than necessary because the return format duplicates the output schema, but each sentence contributes useful information. No 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?

The tool is simple with only three optional parameters, and an output schema exists. The description adds the key usage tip, supported assets, and rate limit, covering most practical needs. It could mention error behavior or offline handling, but given the low complexity and rich annotations, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, setting a baseline of 3. The description enhances this by noting that any CoinGecko ID is accepted, not just the listed symbols, and by clarifying the query parameter's flexibility. This adds semantic meaning beyond the schema's syntax-focused 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 opens with a specific verb and resource: 'Live crypto price feed via CoinGecko. Returns real-time USD price and 24h change.' It clearly defines the tool's function and lists supported assets, differentiating it from other tools like x711_get_latest_gas_station and x711_tx_simulate.

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 a concrete usage context: 'Use before tx_simulate to get current gas cost in USD.' It also mentions the free tier limit (10 calls/day) and no API key needed, providing practical constraints. However, it does not explicitly compare with alternative price-related tools or state when not to use it.

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 mark it as read-only; the description adds meaningful extras: cost ($0.08), API key requirement, and the cross-referencing behavior against failure patterns and success templates. 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?

Two sentences with a clear action→process→outcome flow. Includes cost and auth without verbosity; every part 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?

Given the 2 params, full schema coverage, and no output schema, the description sufficiently explains purpose, input, process, output, cost, and prerequisites. It could detail the recovery plan format but is adequate for a self-audit 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 descriptions and an example for execution_trace, plus context description. The tool description does not add parameter-level detail, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action (submit an agent execution trace) and a concrete outcome (returns a risk-flagged recovery plan via Hive cross-referencing). It distinguishes itself from siblings by focusing on auditing agent behavior against 26,000+ patterns.

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 implies use when you want to catch silent brittle behavior before losses, which gives clear context. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to select this tool over generic hive or agent 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 and openWorldHint, so the description adds value by noting the requirement for an API key, specifying the real-time nature, and listing the exact return fields (token, sentiment_score, trending, etc.). It also mentions the data sources, giving the agent insight into what to expect. This exceeds the baseline but stops short of full transparency (no error/rate-limit details).

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 compact and front-loaded with the core purpose ('Crypto social sentiment'), followed by key output fields, a usage directive, and a prerequisite. Every sentence/section earns its place; no filler.

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 compensates by listing the return object fields. It also covers the main use case and API key requirement. However, it lacks details on score ranges or interpretation of the fields, which would make it more complete for an agent. Overall, it is adequately complete for a simple single-parameter read-only 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% and the description does not add semantic detail beyond the schema's token description. The schema already provides examples ('ETH', 'bitcoin'). The description's mention of 'token symbol or CoinGecko ID' is redundant with the schema, so the description adds no extra parameter meaning.

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 function: analyzing crypto social sentiment with specific outputs (sentiment score, trending, community size, developer activity). It distinguishes itself from siblings by specifying data sources (CoinGecko + DexScreener) and its unique focus on narrative and hype, which sets it apart from price feeds or general data retrieval.

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 usage context: 'Use before trading decisions.' This provides a clear when-to-use scenario. However, it does not mention when not to use it or name alternatives, so it lacks the full exclusions that would merit a 5.

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

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

The annotations (readOnlyHint=false, idempotentHint=false) already indicate a mutating operation, and the description adds valuable behavioral specifics: the $0.03 USDC cost, the $0.02 royalty to the original publisher, and the return of a copy with your agent_id attached. This goes beyond the bare annotation flags.

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 five concise sentences, each providing distinct information: the action, cost, royalty, return format, and prerequisite browsing step. It is front-loaded with the core purpose and contains no redundancy or filler.

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, the description covers the action, cost, royalty, return value, and how to get the strategy ID. It even includes a human-readable URL. The absence of an output schema is compensated by the explicit statement of the return value, making the tool complete enough for an agent to invoke 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?

The input schema already fully describes strategy_id as a UUID and provides the API URL for obtaining IDs. The description adds the alternative browsing URL (https://x711.io/strategies), which is a minor supplement. With 100% schema coverage, a 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 opens with 'Fork a published strategy from the x711 Strategy Commons,' which is a specific verb+resource pair that clearly distinguishes this from sibling tools like x711_strategy_publish. It also states the cost, royalty, and return value, leaving no doubt about the tool's function.

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 by stating that you fork a published strategy and instructs you to browse strategies first via a URL or API to obtain the strategy_id. It does not explicitly name alternative tools or exclusion scenarios, but the usage context is well-defined.

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 only indicate readOnlyHint=false, openWorldHint=false, and idempotentHint=false, so the description must add behavioral context. It adds the $0.05 cost and royalty structure, but does not disclose irreversibility, public visibility beyond the word 'publish', or any wallet/prerequisite requirements. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each earning its place: purpose, cost, and royalty model/link. It is front-loaded and free of unnecessary detail.

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 publishing tool with five parameters and no output schema, the description adequately covers what the tool does, the economic impact, and the outcome (forking). It does not explain the strategy structure beyond schema, but the schema handles that. The link to browse strategies adds useful 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 description coverage is 100%, with all five parameters having clear examples and explanations. The description does not add additional parameter-level meaning beyond what the schema already provides, so 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 publishes an execution strategy to the x711 Strategy Commons, which is a specific verb and resource. It also distinguishes from the sibling tool x711_strategy_fork by framing this as the publishing action, while fork is a subsequent activity mentioned as a consequence.

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 context by requiring a 'proven execution strategy' and explaining the publishing cost and royalty model. It does not explicitly name alternatives or exclusion criteria, but the context makes it obvious when to use this tool versus the forking tool, which is mentioned in the description.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable behavioral context: 1-hour cache, $0.10 cost, and API key requirement. These operational details (rate limits, pricing, auth) go beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each providing distinct information: what the briefing is, its contents, and operational constraints (cache, cost, auth). It is front-loaded and free of 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 parameterless, read-only digest with no output schema, the description is fully complete. It covers the output components, source, freshness, pricing, and access requirements, giving an agent all needed context to invoke the tool 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?

The tool has zero parameters, and the schema description coverage is 100% (an empty schema). With no parameters to explain, the baseline is 4, and the description adds no parameter-specific meaning, which 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 specifies the tool's function: a cross-domain evolutionary intelligence briefing from SUBSTRATE, listing concrete deliverables (engine pulse, top 5 breakthroughs, surviving lifeforms, domain breakdown). This distinguishes it from sibling tools like x711_substrate_domain_digest or x711_substrate_leaderboard.

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?

Clear context is provided: it's a daily, cross-domain overview with caching and cost information, implying use for a broad intelligence summary. However, it does not explicitly state when not to use it or name alternatives, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and determinism. The description adds valuable context by disclosing '$0.05' cost and 'Requires API key' authentication needs, which are not in annotations. It also describes the output focus ('Top lifeforms + breakthroughs'), but does not delve into pagination or output format, which is acceptable given the read-only nature.

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 compact and front-loaded: the first sentence establishes purpose, followed by scope, output, domains, cost, and auth. Every sentence earns its place, with no fluff or redundancy. It efficiently packs essential information into a short 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 low complexity (one parameter, no output schema, read-only), the description is highly complete. It covers purpose, valid domain values, cost, authentication, and a preview of the output content ('Top lifeforms + breakthroughs'). Annotations fill in safety (read-only, idempotent), leaving no critical gaps for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: the parameter 'domain' is fully described with an enum and definition. The description's repetition of 'Domains: ai, climate, biology, energy, economics, materials' adds no new meaning beyond the schema. Since the schema carries the semantic burden, the description meets the baseline without adding extra parameter 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 the tool's function: 'Domain-targeted SUBSTRATE intelligence briefing' with 'Top lifeforms + breakthroughs in one domain.' It explicitly lists the supported domains, distinguishing it from broader digests. The verb 'digest' and resource 'SUBSTRATE' are specific, and the scope is narrowed by 'Domain-targeted.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Narrower focus, higher signal' implies a comparison to broader alternatives like the daily digest, suggesting when this tool is appropriate. It provides the domain list as valid inputs. However, it does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of full usage 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 already declare readOnlyHint and idempotentHint, and the description adds valuable access context: 'FREE — no credits required (counts toward 10/day free tier). No API key needed.' This discloses rate-limit and authentication traits beyond the annotations, enriching behavioral transparency 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?

The description is extremely concise: two sentences front-load the core purpose ('Agent-seeded lifeforms ranked by fitness score') followed by essential access details. Every sentence earns its place, with no redundant or filler 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 the tool's simplicity (0 params, no output schema), the description covers the essential purpose, the nature of the data (fitness-ranked lifeforms), and access constraints (free tier, no API key). It does not explain what 'fitness score' means or the exact return format, but such detail is not necessary for a straightforward read-only leaderboard.

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, and the schema coverage is 100% (empty schema), so there is nothing for the description to add about parameter semantics. With 0 params, the baseline is 4, and the description appropriately does not attempt to explain nonexistent 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 clearly states the tool's function: 'Agent-seeded lifeforms ranked by fitness score' and 'See which AI agent ideas survived the SUBSTRATE evolution engine.' This uses a specific verb ('see') with a distinct resource (leaderboard of evolved agents), differentiating it from sibling tools like x711_substrate_daily_digest and x711_substrate_seed_hypothesis.

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 does not explicitly state when to use this tool instead of alternatives, though it provides useful access guidance ('FREE — no credits required', 'No API key needed'). Usage context is implied for 'see[ing] which AI agent ideas survived,' but no exclusions or comparisons with sibling tools are 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?

Annotations are sparse (only false hints), so the description carries the full burden. It discloses the cost ($0.25), API key requirement, the initial fitness (0.5), the evolution interval (every 15 min), and the potential for breakthrough publication. This provides substantive behavioral context beyond the schema.

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 primary action, and includes only essential details (cost, API key, evolution process). There is no redundancy or unnecessary information, making it highly concise and well-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?

Given there is no output schema, the description explains the lifecycle of the hypothesis (name, ID, fitness, evolution, breakthrough status), which covers the expected response context. It could explicitly state what the tool returns (e.g., an ID), but the description is sufficiently complete for a write operation with moderate 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 input schema already covers both parameters with clear descriptions and enum for domain, so schema coverage is 100%. The description adds minimal extra meaning about parameters, only implying that the hypothesis evolves and receives a name/ID. This baseline of 3 is appropriate since the schema does the heavy lifting.

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 function: 'Inject your hypothesis into the SUBSTRATE evolution engine.' It specifies the resource (SUBSTRATE evolution engine) and provides concrete outcomes (name, ID, fitness, evolution cycle, breakthrough status). This distinguishes it from sibling tools like substrate_daily_digest or substrate_leaderboard, which are read-oriented.

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 conveys clear context: this tool is for submitting a hypothesis to be evolved. It does not explicitly mention when not to use it or alternatives, but the purpose is unambiguous. The phrase 'Inject your hypothesis' indicates a write action, which is distinct from other substrate 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 mark this as non-readonly and non-idempotent, but the description goes much further by disclosing the public visibility, the estimated reach and pioneer status behavior, the contribution to hive_trending, the API key requirement, the $0.02 cost, and the precise return fields. This gives an agent full awareness of side effects and expectations beyond what annotations convey. 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 compact and information-dense: it opens with a clear analogy, states the core action and audience, lists return fields, and closes with cost and key requirement. Every clause earns its place, and the structure front-loads the most important 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 there is no output schema, the description is unusually complete: it enumerates the exact return fields (broadcast_id, topic, namespace, reach_before, reach_label, how_others_read), prerequisites (API key), cost, and secondary effects (trending visibility). This makes the tool self-explanatory for an agent to select and invoke 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?

The input schema already fully describes both parameters (100% coverage), so the baseline is 3. The description adds extra value by advising that 'high-quality broadcasts surface faster in hive_trending', giving qualitative guidance on message curation, but it does not add new semantic or format details 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 opens with a vivid analogy ('Twitter for agents') and clearly states the action: broadcast a message to a public topic namespace readable by any monitoring agent. It names the resource (topic namespace), the audience (agents), and mentions related behavior (counts toward hive_trending), effectively distinguishing it from sibling tools like x711_hive_write or x711_tx_broadcast.

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 strong context: use this tool when you want to publish a public, topic-scoped message that other agents can read, and notes that it feeds into x711_hive_trending. However, it does not explicitly name alternative tools for when not to use it (e.g., private messaging, one-time transactions), so it stops short of a full when/when-not guide.

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 goes far beyond the annotations by disclosing significant behavioral traits: private keys never leave the agent, submission via eth_sendRawTransaction on public RPC, automatic anonymized pattern writes to The Hive after every broadcast, side effects of viral_conquest mode, and the fire-and-forget nature with zero extra latency. It also mentions API-key/credit requirements for viral_only. No contradiction with the destructiveHint annotation.

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 core action, which is good, but it becomes verbose and includes unnecessary marketing language and a tagline ('It becomes the marketing department for the entire Hive'). The viral_conquest details are repeated in both the description and the schema, adding 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?

Given the tool's complexity (5 optional parameters, multiple modes, side effects, a return object), the description covers most key aspects: supported chains, optional modes, Hive side effects, return fields, and chain-specific explorer notes. However, it leaves some gaps, such as what happens when no signed_tx is provided (since no parameters are required) and whether standard broadcasts also require API keys and credits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers all parameters (100% coverage), so the baseline is 3. The description adds value by explaining chain naming conventions (bnb vs bsc, opbnb), linking simulation_id to x711_tx_simulate, and elaborating on viral_conquest and viral_only behaviors beyond their schema descriptions. This exceeds the baseline.

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 leads with a specific action ('Relay a pre-signed EVM transaction') and lists all supported chains, making the tool's core function unmistakable. It clearly differs from siblings like x711_tx_simulate (simulation) and x711_swarm_broadcast (agent-to-agent broadcast). The purpose remains clear despite marketing fluff at the end.

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 clearly indicates when to use the tool (broadcasting a pre-signed tx) and gives chain-specific guidance for BNB and opBNB. It also implies a simulate-then-broadcast workflow via the simulation_id parameter. However, it never explicitly states when NOT to use it (e.g., 'use x711_tx_simulate first') or names alternatives, so it falls short of a full 5.

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

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

Annotations already declare readOnly, openWorld, and idempotent hints. The description adds concrete behavioral details: uses public RPC eth_call + eth_estimateGas, pulls live gas prices, estimates USD cost, enriches with Hive wisdom, and notes the free tier limit of 3 sims/day. 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 concise and front-loaded with the core action, followed by technical details, return shape, and usage constraint. Every sentence adds value, though the chain list and free-tier note make it slightly longer than necessary.

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 multi-chain simulation and the existence of an output schema, the description is highly complete. It covers purpose, usage guidance, technical approach, return fields, and constraints like the free tier. The output schema handles return value details, so no further explanation is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter (to, from, chain, value, calldata) is already well-documented. The description reinforces that calldata can be omitted for plain ETH transfers and chain aliases (bnb/bsc) exist, but does not add significant 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 simulates an on-chain transaction before broadcasting, with a specific verb and resource. It distinguishes itself from sibling x711_tx_broadcast by explicitly saying 'Always simulate before calling x711_tx_broadcast' and listing supported chains.

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 explicit usage guidance: 'Always simulate before calling x711_tx_broadcast.' Also notes no wallet or API key is needed and lists supported chains, giving the agent strong context for when to invoke this tool versus 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?

The description goes well beyond the sparse annotations (all false) by disclosing key behaviors: source memories are archived (destructive), automatic refund if Groq fails (failure handling), $0.05 cost, and API key requirement. This adds significant context that annotations do not provide, giving the agent a full picture of operational implications.

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 that front-loads the core purpose and then efficiently covers operational details (archival, refund, cost, key). Every phrase adds value, and the structure is clear and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero parameters and no output schema, the description carries the full burden. It covers purpose, transformation, side effects, cost, prerequisites, and failure behavior, giving an agent everything needed to decide on invocation and correctly infer expected outcomes.

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 is empty (0 parameters), so the baseline is 4. The description appropriately has no parameter details to add, as there are none to document. The tool's behavior is fully described without needing parameter-level semantics.

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 and specifically states the tool's function: 'Groq-powered vault compression: 50 cold (least-read) memories → 5 dense summaries.' It names the resource (vault), the action (compress), and the concrete transformation, which distinguishes it from sibling tools like vault_query and vault_write.

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 use ('sharper vault, lower LLM token cost when injecting context') and implies when it's appropriate (when vault has cold memories). However, it does not explicitly mention alternatives or exclusions, so the agent must infer when to choose this over other vault 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?

Beyond annotations (readOnly, idempotent), the description adds valuable behavioral details: ranking is based on cosine similarity × confidence × importance, it is free, requires an API key, and only reads the agent's own vault. These are useful operational signals not present in annotations, though it does not detail response format or pagination.

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 compact and front-loaded with the primary purpose, followed by the ranking mechanism and access details. Every sentence adds functional value (ranking, cost, privacy) without redundancy or fluff, making it easy to scan.

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 there is no output schema, the description partially fills the gap by stating that it returns 'ranked memories' with a specific ranking score, and describes the type of content (facts, insights, skills). It does not specify the exact structure of each result, but for a simple search tool this is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers 100% of parameters with detailed descriptions (including examples for 'q' and constraints for 'limit'). The tool description provides general context about semantic search but does not add further meaning to individual parameters, so it meets the baseline without exceeding 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?

The description clearly states a specific action ('Semantic vector search') on a specific resource ('your private vault') and even details the ranking mechanism. It distinguishes this from sibling tools by emphasizing the private vault scope and unique scoring formula, setting it apart from general retrieval or web search 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 makes the intended use context obvious ('recalls facts, insights, and skills your agent has accumulated'), so an agent knows when to invoke it. However, it does not explicitly state when not to use it or name alternative tools (e.g., x711_deep_search), so it lacks exclusions or explicit 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?

Beyond the annotations (readOnlyHint=false, etc.), the description discloses cost structure ('First 500 lifetime writes free, then $0.01/pack'), decay timers ('context 7d, insight 90d, skill 180d, fact 365d'), the immortal=true surcharge (+$0.05), and privacy ('Vault is private — only your agent can read it'). It also states 'Requires API key,' covering authentication. 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?

The description is front-loaded with the primary purpose and delivers operational details (decay, pricing, immortal, privacy, pairing) in five compact sentences. It avoids unnecessary verbosity, though it repeats some type-decay information already present in the schema descriptions. This slight redundancy prevents a perfect score.

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 mutation tool with no output schema, the description covers all decision-relevant context: persistence semantics, cost implications, privacy boundary, free tier, and the companion read tool. The optional parameters are fully documented in the schema, so the description plus schema is complete enough for an agent to invoke the tool correctly and understand consequences.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers 100% of parameters with detailed descriptions, so baseline is 3. The description adds value by mapping type values to decay durations (e.g., 'context 7d, insight 90d...') and noting the +$0.05 cost for immortal=true, which enhances the schema's parameter semantics. It does not fully compensate for all schema details, but it reinforces key parameter meanings.

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 'Write a private memory pack to your agent's personal vault,' a specific verb and target resource. It distinguishes the tool from sibling vault_query by explicitly saying 'Pair with vault_query for recall' and lists the content types (facts, insights, context, skills), making its purpose unmistakable.

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 provides clear usage context: 'Pair with vault_query for recall' tells the agent when to use this write tool versus the read counterpart. It also mentions the API key requirement and the pricing structure, which are important usage conditions. It lacks an explicit 'when not to use' statement, but the context is otherwise 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=true and idempotentHint=true, covering safety. The description adds valuable behavioral context beyond annotations: cost ($0.05), required API key, and the specific data fields returned. This goes beyond the baseline and helps the agent anticipate side effects (e.g., no on-chain mutations, but a fee is incurred).

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 appropriately sized and front-loaded: it opens with the core purpose, then lists returns, usage guidance, supported chains, and cost. Every sentence adds value, and the structure is logical, though it could be slightly more compact.

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 must explain return values, and it does: balance, age, entity label, transaction history summary, token holdings, and risk flags. It also covers auth requirements (API key) and cost. It is sufficiently complete for an agent to invoke correctly, though it could specify the exact format of the report.

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%: both 'address' and 'chain' have detailed descriptions in the schema, including an example and supported chain list. The description adds no new parameter-level details beyond what the schema already provides, so a 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 tool's function: 'Forensic address intelligence report via Blockscout multi-chain.' It specifies the resource (address intelligence) and the verb (investigate), and distinguishes itself from siblings by listing specific outputs like balance, entity label, and risk flags, which no other sibling tool mentions.

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 when-to-use guidance: 'Run before sending USDC to any unknown address.' It also lists supported chains, giving context for applicability. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

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

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

The description reveals key behaviors beyond annotations: the automatic fallback chain, guaranteed return of results via community-sourced Hive knowledge, and free-tier rate limit. This adds substantial context about what the agent can expect.

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 and front-loaded, with each sentence providing distinct value: purpose, fallback behavior, use cases, output format, and rate limit. 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?

The description is complete given the tool's simplicity: it defines output structure, usage context, fallback behavior, and constraints like the free tier. It substitutes for a full output schema and covers the essentials.

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 for the single 'query' parameter is 100%, as the schema provides examples. The tool description does not add additional parameter-specific semantics beyond restating the query concept. 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 tool performs a multi-source web search with a fallback chain, and specifies what it is best for (tech/AI/crypto, current events, documentation). This distinguishes it from sibling tools like x711_deep_search and x711_data_retrieval.

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 'Best for' provides clear usage context but does not explicitly name alternatives or exclusionary cases. It implies when to use the tool (tech/AI/crypto, current events) but lacks direct contrast with siblings.

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 idempotentHint=true, and the description aligns by describing a parse operation. The description adds useful behavioral context: it is free, requires no authentication, and returns specific fields (chain, token, amount, recipient, retry headers). This goes beyond the schema and 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 compact and front-loaded with the core purpose. Each sentence adds value: what it does, what it returns, free/no-auth, and compatibility with any x402 API. The 'FREE' emphasis is slightly promotional but still informative for an agent deciding to invoke it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter parser with no output schema, the description is complete. It states the input requirement, the output structure (list of fields), and the scope (any x402-compliant API). An agent can confidently select and call this tool to parse a 402 response without needing additional details.

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 sole parameter 'body' is fully documented in the schema with a clear description of the expected input (raw 402 response body, JSON object or string). The tool description reinforces the same idea but does not add new syntax or format details. With 100% schema coverage, 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 identifies the specific verb 'parse' and resource 'x402 Payment Required (HTTP 402) response body', and lists the exact structured output fields (chain, token, amount, recipient, retry headers). This clearly distinguishes it from sibling tools, which focus on unrelated domains like agents, vaults, or web 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?

The description states when to use the tool: when you have a 402 response body, from x711 or any other x402-compliant API. It also notes that no API key is ever needed. However, it does not explicitly mention alternatives or when not to use it, but given the unique niche, the context is reasonably clear.

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