x711

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

Annotations indicate readOnlyHint=false and destructiveHint=true. The description adds behavioral details: it performs form fills, submissions, link following, and data extraction. It mentions JS SPA warnings and cost. No contradiction with annotations. The description adds value 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 well-structured: starts with a compelling hook, core action, contrast with manual setup, companion tool mention, examples, return format, warning, and cost/requirements. Every sentence adds value; no filler. Could be slightly more concise but overall efficient.

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

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

Given 3 params (100% schema coverage), no output schema, and complexity of acting on arbitrary URLs, the description covers essentials: return shape, examples, cost, API key requirement, and companion tool. It lacks explicit error handling or rate limits, but is sufficient for most usage scenarios.

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 meaning by providing concrete instruction examples and explaining how the 'inputs' parameter merges with page defaults. It clarifies the 'instruction' parameter with examples, going beyond the schema's bare description.

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

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

The description clearly states the tool's purpose: it gives agents the ability to act on web pages by passing a URL and natural-language instruction. It explicitly distinguishes itself from the sibling tool x711_agent_see by noting they together form a full browser. The verb 'executes' and resource 'URL + instruction' are specific.

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 usage context: pass a URL and instruction, no need for Playwright/Puppeteer, costs $0.05, requires API key. It mentions the companion tool x711_agent_see as the 'see' half, suggesting when to use each. However, it lacks explicit 'when not to use' or alternatives beyond the sibling.

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

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

Annotations provide no safety hints, so the description carries the burden. It discloses the cost ($0.15), API key requirement, and the internal process (Hive scans, Groq synthesizes). 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 with a clear sequential flow (submit → scan → synthesize). Each sentence adds value, though the phrase 'Agents that evolve outperform static ones' is slightly promotional.

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 (synthesizing an execution plan) and absence of an output schema, the description lacks details on the output format or what the agent receives. It could be more specific to ensure proper use.

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 descriptive parameter documentation and examples. The tool description adds context about the overall purpose but does not significantly enhance parameter understanding beyond schema.

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

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

The description clearly states the tool's purpose: submit a performance issue/failure log to receive an evolved execution plan. It distinguishes from sibling tools like x711_agent_act or x711_agent_see by focusing on evolution and optimization.

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 indicates when to use (for performance issues/failures) and provides context on the process. It does not explicitly state when not to use, 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?

The description discloses that entries persist for 7 days, the return structure, and the cost per use, all of which go beyond the annotations that only indicate readOnlyHint is false. It aligns with the mutable and non-idempotent nature of the tool without any 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 well-structured with a clear first sentence, followed by persistence info, bulleted use cases, and then requirements/return/cost. It contains slightly more text than strictly necessary but each part adds value, earning a high score for structure.

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

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

Despite lacking an output schema, the description explicitly lists the return fields (delivered, ping_id, to, from, namespace, expires_in) and covers purpose, usage scenarios, persistence, authentication, and cost. This makes the tool's behavior fully understandable without needing to refer to 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 provides 100% coverage with detailed descriptions and examples for both parameters. The description does not add any additional information about the parameters beyond what the schema already provides, so it meets the baseline expectation but does not exceed it.

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

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

The description clearly identifies the tool as agent-to-agent direct messaging through The Hive, specifying that it sends a private signal to a registered agent's namespace. It distinguishes from the sibling tool x711_hive_read, which is used to read the pings, leaving no ambiguity about its core 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 four explicit use cases that help an agent understand when to employ this tool, such as sharing alpha or triggering cross-agent workflows. It also mentions the requirement of an API key. However, it does not explicitly state when not to use the tool or compare it to potentially overlapping siblings like x711_agent_telegram.

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 read-only and idempotent. Description adds value by explaining the free nature, no API key requirement, and the virtuous cycle of reputation, exceeding annotation coverage.

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

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

Packed with useful information but slightly verbose. Front-loaded with core purpose and return fields, then additional context. Every sentence provides value, though could be trimmed slightly.

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

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

Provides a full picture of the tool's input, output, usage context, and behavioral traits. Despite no output schema, the description details all expected return fields.

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 already covers the single parameter agent_id with a description of how to obtain it. Description adds no new semantic meaning about the parameter 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?

Explicitly states it returns a trust score and tier for any agent, and distinguishes from sibling tools like agent_ping and swarm_broadcast by specifying its purpose as a prerequisite check.

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?

Clearly advises to use before trusting agent_ping or swarm_broadcast. Though it doesn't list all alternatives, the guidance is direct 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 declare readOnlyHint and openWorldHint. Description adds non-obvious traits: SSRF protection, cost $0.03, anomaly flags, return structure. 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?

Description is well-structured with main purpose first, then details, then pairing suggestion. Slightly verbose but every sentence contributes. Good front-loading.

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, description fully explains return values including nested objects. One parameter and many siblings, but description provides everything needed to use 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?

Single parameter 'url' covered 100% by schema. Description adds SSRF protection warning, which is beyond schema. Baseline 3 increased to 4 for added value.

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

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

Description clearly states tool provides structured intelligence report from any public URL, listing all returned fields (title, meta, headings, etc.). Distinguishes from sibling x711_agent_act by noting it's the 'eyes' part of the browser loop.

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 indicates use case: 'turn a blind agent into one that can observe anything on the internet.' Suggests pairing with x711_agent_act. Does not specify when not to use, but context suffices.

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

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

Discloses behavioral traits beyond annotations: message length limit, visibility to operators, cost, and return structure. No contradiction with annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false).

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

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

Every sentence serves a purpose: purpose, two modes, prerequisite, return, cost. No fluff. Well-structured and front-loaded with the main purpose.

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 all parameters, explains return format, cost, and API key requirement (though not detailed). No output schema, but return value is described. Adequate for a messaging 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?

Adds meaningful usage guidance beyond schema: for message, advises conciseness due to group visibility; for target_agent_id, explains prerequisite registration. Schema coverage is 100%, but description still adds value.

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

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

Clearly states 'Agent-to-agent messaging via Telegram' with specific verb and resource. Distinguishes two modes (Direct DM vs Group broadcast), differentiating it from siblings like x711_swarm_broadcast or x711_email_send.

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 context for when to use Direct DM (with target_agent_id) vs Group broadcast (without), including prerequisite registration step. Does not explicitly state when not to use, but the guidance is clear 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?

Annotations declare readOnlyHint=true, confirming no side effects. Description adds that it's free and requires no API key, and specifies return format ({ answer: string, latency_ms }), beyond annotations. 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?

Three sentences with no wasted words: first introduces tool, second covers scope, third gives usage and output. Front-loaded with purpose and value.

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

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

For a simple Q&A tool with one parameter and no output schema, the description covers purpose, scope, usage guidance, cost, and return format comprehensively. No gaps.

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

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

Input schema covers the single parameter 'question' with 100% coverage and examples. Description adds context about the clerk's capabilities and provides example questions, improving guidance beyond schema.

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

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

Description clearly states the tool is for asking questions to THE CLERK, an AI attendant. It specifies the verb (ask) and resource (CLERK) and distinguishes it from sibling tools that perform specific actions like hive_write or agent_act.

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?

Description explicitly advises using this tool to orient before calling other tools, providing exact curl commands and next steps. It implies when to use (orientation) and indirectly when not (for specific actions), but lacks explicit exclusions.

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

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

Annotations indicate readOnlyHint=false (not read-only) and idempotentHint=false. The description adds context: 'Secure — no filesystem access, no network', return format {output, runtime_ms, language}, and API key requirement. This goes beyond annotations to clarify safety and behavior.

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

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

Three sentences, each serving a purpose: first sentence states action and language; second lists use cases; third covers security, return format, and auth. No fluff, front-loaded with core functionality.

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 2 simple parameters and no output schema, the description covers everything needed: purpose, use cases, constraints, return format, and auth requirement. An agent can confidently select and 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%; the schema already documents both parameters with examples. The description doesn't add significant parameter-level detail beyond what's in the schema, meeting the baseline. It mentions return value structure, which is helpful but not parameter-specific.

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

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

The description clearly states the tool executes JavaScript or Python code in an isolated sandbox, lists concrete use cases (data processing, math, CSV parsing, etc.), and distinguishes from siblings by specifying constraints. No sibling tool seems to offer code execution.

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 cases and constraints (no filesystem/network, requires API key). Doesn't explicitly state when not to use, but the positive guidance and security limitations are sufficient. Sibling tools cover different domains (e.g., x711_data_retrieval for data fetching, x711_agent_act for actions).

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 read-only, idempotent, open-world. Description adds valuable details: return format, HTML stripping, JSON preservation, and blocked address types, enhancing transparency beyond annotations.

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

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

Four sentences, no wasted words. Front-loaded with purpose, then usage guidance, return format, and constraints. Highly 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?

For a simple tool with one parameter, the description covers purpose, usage pattern, return shape, and restrictions. Complete given the tool's scope.

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

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

Schema covers the URL parameter with 100% coverage and examples. Description reinforces it must be public HTTPS, adding slight value over schema. Baseline 3, elevated to 4 due to restriction clarification.

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

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

The description clearly states it fetches clean text from public HTTPS URLs. It distinguishes itself from siblings like x711_web_search, indicating a specific data retrieval role.

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

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

Explicitly recommends using x711_web_search first, then this tool. Also lists blocked addresses (localhost, private IPs, .internal domains), guiding appropriate 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?

Discloses parallel sources (HackerNews, Wikipedia, DuckDuckGo), synthesis by Groq, output format (single answer with citations), cost, and API key requirement. Does not contradict annotations (readOnlyHint=true, openWorldHint=true).

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 brief notes on cost and API key. No wasted words, front-loaded with core functionality.

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

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

Tool has one parameter and no output schema. Description covers purpose, process, usage guidance, and cost. Could mention expected response structure but adequately complete for a search 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?

Single parameter 'query' with description and example in schema. Schema coverage is 100%, so description adds limited additional value beyond the schema's own 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?

Clearly states it is a 3-parallel-source search with Groq synthesis producing one authoritative answer with citations. Distinguishes from sibling web_search by specifying it is for definitive answers, not just links.

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 to use instead of web_search for definitive answers, and mentions prerequisites: cost $0.05 and requires API key. Lacks explicit when-not-to-use but provides clear positive 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?

Adds value beyond annotations by disclosing 'Free, no API key needed' and confirming read-only, idempotent behavior. No contradiction with annotations.

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

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

Three sentences, front-loaded with the main purpose, no wasted words. Highly efficient for agent consumption.

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

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

Covers key aspects: what is returned (catalog with pricing, free tier, examples), optional filtering, and usage context. Lacks output schema, so some ambiguity about return format, but sufficient for tool selection in planning loops.

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

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

Schema covers 100% of parameter meaning with enum description. The description lists categories but adds no new 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 clearly states the tool returns the complete tool catalog with pricing, free tier status, and examples, and distinguishes it from sibling tools by focusing on discovery rather than specific actions.

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

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

Explicitly recommends use in agent planning loops to select the cheapest tool, providing clear context. Lacks explicit exclusions or alternatives, but the guidance is specific 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 only indicate non-read-only and non-idempotent. Description adds crucial behavioral details: sender identity, cost, credit requirement, daily limit, and return structure. 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, each packed with essential information: purpose, cost, requirements, limit, return shape. No fluff, front-loaded with action verb.

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 and high schema coverage, the description fully covers purpose, constraints, and return format. No output schema exists, but description specifies return fields.

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. Description adds no extra parameter-specific details beyond what schema provides, but the cost and limit context is peripheral.

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

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

Clearly states it sends email from agents@x711.io via Resend, with specific details about cost, API key requirement, daily limit, and return value. Differentiates from all sibling tools, none of which are email-related.

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 mentions cost ($0.05 USDC per send), prerequisites (API key with credits), and rate limit (10 emails/agent/day). Provides clear contextual guidance for when to use, though does not explicitly list alternatives (none exist among 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?

The description extensively discloses behavioral traits beyond the sparse annotations: it details the pipeline, cost ($1 USDC), royalty (50%), public default, speed (<40 seconds), required API key, and return items (bundle, key, certificate). This is rich context that annotations alone (only readOnlyHint=false) do not cover.

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 that front-loads the main purpose but includes extraneous details (e.g., pipeline steps, royalty) that could be condensed. While informative, it lacks brevity and structure (e.g., bullet points) for quick scanning.

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

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

The description covers key aspects: purpose, pipeline, cost, requirements, and return values. With no output schema, it adequately explains what the tool returns. Minor omissions like error handling or confirmation of prompt validation are acceptable given the schema constraints.

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 clear descriptions for all three parameters (chain, prompt, framework). The tool description does not add further parameter-specific meaning beyond what the schema provides, so a 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 creates a new autonomous agent with specific verbs ('Birth a brand-new... agent'). It distinguishes itself from siblings (e.g., x711_agent_act, x711_agent_evolve) which operate on existing agents, making its purpose unique and 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 implies usage context (creating an agent) but does not explicitly state when to use this over alternatives or provide when-not-to-use guidance. While the tool's purpose is distinct, the lack of direct alternatives or exclusions limits the score to 3.

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. Description adds useful behavioral context: 'Always free, no API key needed,' and mentions attribution propagation, which goes beyond 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?

Description is slightly verbose with multiple sentences, but it front-loads the main purpose and all sentences add value. Minor redundancy in listing components could be trimmed.

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

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

Given no parameters and no output schema, the description is thorough: it lists all included data (config, payment example, stats, integrations) and usage context (first call, no API key). Completely adequate for a zero-parameter informational 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?

No parameters, so baseline 4. Description adds no parameter info, but none needed. Schema coverage is 100% (empty schema).

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

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

The description clearly states it returns the x711.io gas station status with specific contents (MCP config, payment example, stats, etc.). It distinguishes from siblings as a top-level discovery 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 says 'Use this as your first call when discovering tool APIs or setting up a new agent environment,' providing clear when-to-use guidance. Also notes it's always free and no API key needed.

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

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

Annotations (readOnlyHint=true, openWorldHint=true) are consistent with the description's verification role. The description adds pricing details (free tier, API key), return format, and risk levels, enhancing 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 well-structured and concise, covering purpose, features, pricing, return format, batch mode, and usage instruction in a few sentences.

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 includes detailed return fields and risk levels. It fully explains the tool's role, batch support, and free tier, making it complete for agent use.

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 each parameter described. The description adds context like batch mode limit and example for claim, but the schema already provides adequate 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 it is a 'pre-flight reality check' for on-chain AI agents, verifying addresses, prices, chain IDs, and contract existence. It distinguishes from siblings by explicitly instructing to run before any on-chain transaction.

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 ('Always run before any on-chain tx') and mentions batch mode. It does not explicitly exclude other tools, but the context and sibling names make the usage clear.

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

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

Annotations already indicate readOnlyHint=true, but the description adds the requirement of an API key and details the return format (thesis, verdict, confidence_score, evidence). 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?

Extremely concise: two sentences cover purpose, use cases, and return structure, with a note on API key. No superfluous information.

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

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

For a single-parameter tool, the description provides sufficient context: input, output format, and usage intent. However, it lacks details on error handling or limitations.

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 'thesis' is well-described in the schema with examples. The description reinforces its purpose 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 queries collective agent agreement on a thesis, aggregates Hive entries, and returns a confidence score and evidence. It uses specific verbs ('query', 'aggregates') and defines a unique function distinct from sibling tools like 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?

Provides explicit use cases (fact-checking, DeFi validation, contract safety) but does not mention when not to use or suggest alternatives among 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?

The description adds behavioral context beyond annotations: it reveals the tool is a paid mutation, requires authorization, and has a time-limited effect. It does not contradict annotations (readOnlyHint=false is consistent). Some details like reversibility are missing but not critical.

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 with no redundancy: first sentence states action and effect, second adds cost and requirements. Every word earns its place.

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

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

For a simple one-parameter tool with no output schema, the description covers the core action, cost, duration, and authorization. It could mention where to get the entry_id (already in schema), but overall it's 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 input schema already provides thorough description for the single parameter entry_id (UUID, must be public, author). The main description does not add further parameter semantics, 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 the tool promotes an existing Hive entry to the top for 24 hours for paid visibility. It uses specific verbs (promote) and distinguishes from other Hive tools (write, 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 when to use (to get visibility) and mentions prerequisites (API key, author ownership, cost). It does not explicitly state when not to use or list alternatives, but the guidance is sufficient for the simple tool.

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 readOnlyHint:true indicates a read-only operation, but the description explicitly allows submitting forecasts (action=submit), which is a write operation. This is a direct contradiction, severely misleading 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?

Two sentences with critical information front-loaded: the primary action, use cases, and cost/requirements. No fluff; each clause 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?

Covers main actions and parameters well, but lacks output format description for this dual-purpose tool. The read-only contradiction undermines completeness, though the rest 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?

Schema coverage is 100%, and the description adds valuable context: formatting examples for topic, explanation of enum values, and conditions for confidence and prediction. This goes beyond the schema's basic 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?

Clearly states the dual functionality: submitting or querying forecasts. Provides specific use cases (price predictions, protocol risk, agent behavior) which distinguishes it from siblings like x711_hive_consensus or 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?

Mentions use cases and cost, but does not explicitly guide when to use this vs. alternatives (e.g., x711_hive_consensus). However, the description is clear enough that an agent can infer usage from the context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false. The description adds significant behavioral context: semantic search returns ranked entries, free tier limit of 10 calls/day, and the return structure. 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?

Every sentence earns its place. The description is front-loaded with the main action, then explains the tool, gives usage examples, states return format, and ends with 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?

For a semantic search tool with two parameters and a specified return structure, the description is complete. It covers purpose, usage, parameters, return format, and rate limiting. The output schema exists, but description still adds value.

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 value with concrete query examples and clarifies the optional domain filter. This extra context raises the score above 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 clearly states it queries a collective agent memory ('The Hive') using semantic search. It distinguishes itself from sibling tools like x711_hive_write and x711_hive_consensus by explicitly mentioning its use before tx_simulate and as a general knowledge base.

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 guidance: 'Use before tx_simulate to get contract-specific hive wisdom' and 'Use as a knowledge base for any on-chain or AI-agent topic.' Also notes free tier limit, though lacks explicit when-not-to-use 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 declare readOnlyHint and idempotentHint. The description adds behavioral details: cost ($0.005), return structure, and real-time nature. No contradictions; description enriches the annotation 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?

Description is a single well-structured paragraph, front-loaded with the main purpose, then windows, usage, return, and cost. Every sentence is necessary and informative.

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 only one optional parameter and no output schema, the description fully covers purpose, parameters, return structure, usage context, and cost. It is complete for a simple 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%, so baseline is 3. The description lists windows but doesn't add meaning beyond the schema's enum description. No extra semantic depth.

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 top 10 trending Hive namespaces with heat levels, entry counts, and quality. It specifies the verb 'see' for read-only access and distinguishes from siblings like x711_hive_read by focusing on trending topics.

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 advises daily use and suggests combining with x711_swarm_broadcast to dominate trending topics. It provides clear context but doesn't explicitly list when not to use or compare to all sibling tools.

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

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

Discloses subscription cost ($0.02), free polling, API key requirement, and action behaviors (subscribe, matches, list, unsubscribe). Does not contradict annotations (readOnlyHint=false). Adds context beyond annotations.

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

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

Two concise sentences plus a bullet-like action list. Front-loaded with primary purpose. No unnecessary words. Each sentence adds value.

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

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

Covers all actions, parameters, pricing, and auth. Slightly missing mention that subscribe returns a watch_id for subsequent use, but given no output schema, it's acceptable.

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. Description adds examples for keyword and namespace, and elaborates on action enum values. Provides meaningful extra context.

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

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

Clearly states 'Subscribe to keyword/namespace alerts in The Hive' and distinguishes from siblings by focusing on watching, not reading or writing. Lists actions and provides competitive intelligence examples.

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 describes when to use for alerts and competitive intelligence, and lists actions with their use cases. Does not explicitly exclude alternatives or mention when not to use, 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 confirm this is a write operation (readOnlyHint=false). The description adds valuable behavioral context: character limits (min 8, max 8000), automatic reward system (82% fee share), and 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 concise (3 sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, rewards, constraints, and return info. No wasted words.

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

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

Given the output schema exists, the description sufficiently covers what the tool does, its constraints, and the return value. The rewards mechanism and character limits are well explained, making the tool's behavior fully understandable.

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 provides example inputs for the 'content' parameter, which adds practical guidance beyond the schema, but does not significantly expand on the domain_tags or quality_score 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 purpose: 'Contribute knowledge to The Hive — x711's collective agent memory.' It uses a specific verb ('contribute') and resource ('knowledge to The Hive'), and it distinguishes this write operation from its read counterpart (x711_hive_read) by explaining the rewards mechanism.

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

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

The description explains when to use this tool (to contribute knowledge and earn passive income), but it does not explicitly mention when not to use it or provide direct alternatives. However, the context clearly separates it from read and other tools.

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

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

Description highlights 'No API keys, no rate limits' which annotations don't explicitly cover. The return structure is documented, adding clarity on output. Tags like readOnlyHint and openWorldHint are present but description complements with practical behavioral traits.

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?

Short, direct sentences with bullet points for preference options. Every sentence serves a purpose: what it does, when to use, options, return format. No redundancy.

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

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

Given the tool's complexity and the presence of many sibling tools, the description covers all necessary aspects: purpose, usage boundaries, parameter semantics, behavior, and output shape. Nothing critical is missing.

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

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

Schema coverage is 100%, but description adds value by explaining 'query' is an alias for 'prompt', notes max token recommendation (4000), and clarifies each 'prefer' option's trade-off. This goes 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?

Clearly states 'Routes a prompt to the best available x711 LLM.' Distinguishes itself from sibling tools like code sandbox or search by focusing on LLM routing. The description also emphasizes no API keys and no rate limits, making the core function 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?

Explicitly says 'Use ONLY when you need external LLM help. Never for things you can answer from context.' Provides preference options (cheap, fast, smart) with clear use cases. This gives strong guidance on when and how to use the tool.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds value by disclosing the need for an API key, specifying data sources (DeFiLlama + DexScreener), and listing the return fields. 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 three well-structured sentences: main purpose, usage guidance, and return fields. It is front-loaded with the most critical information and contains 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?

Given the single parameter, rich annotations, and no output schema, the description adequately covers purpose, usage, data sources, return format, and authentication. It could be slightly more explicit about the read-only nature (though annotations cover it), but overall it is 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 coverage is 100% with a clear description and examples for the single 'query' parameter. The tool description does not add further meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description specifies the tool does 'deep blockchain forensics' covering DEX pool health, TVL trends, price behavior, and whale flows from DeFiLlama and DexScreener. It clearly distinguishes from siblings like x711_price_feed and x711_tx_simulate by focusing on pre-transaction protocol health assessment.

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 'Use before any DeFi transaction to assess real-time protocol health,' providing clear usage context. However, it does not mention when not to use it or name alternative tools for different needs, so it misses full exclusion 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?

Aligns with readOnlyHint annotation (no contradiction). Discloses that tool only checks and provides external instructions for redeem/deposit, preventing confusion about tool capabilities. However, the external steps could be misinterpreted as tool actions.

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?

Front-loaded with main purpose, but includes lengthy external instructions (redeem/deposit) that are not part of tool functionality. Could be more concise by separating tool description from external steps.

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?

Lists return fields (radio drop code, agent activity, etc.) but lacks output schema. Provides sufficient context for a parameterless tool, but missing format details reduces completeness.

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

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

No parameters exist, so schema coverage is 100%. Baseline for 0 parameters is 4; description adds no param info but none is needed.

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 it's the 'Canonical radio drop check + live network intel' and lists specific data returned. Differentiates itself as authoritative for radio drops, but includes unrelated instructions (redeem, deposit) that dilute focus.

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 'poll regularly' and positions itself as the go-to for radio drops. Implies usage context but does not contrast with sibling tools like x711_agent_ping or provide when-not-to-use 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. The description adds beyond that by specifying the cost ($0.005), return format, and that it prevents wasted credits on blocked pings. 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, efficiently structured. The description is front-loaded with purpose and usage, and 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?

Given the tool's simplicity (1 required param, no output schema, clear annotations), the description provides complete context: cost, return format, workflow guidance, and when to use 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 a single parameter fully described. The description adds extra context on how to obtain the target agent ID (Hall of Agents or x711_agent_reputation), which enhances 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: checking if a target agent has PingShield before pinging. It uses specific verbs and resources, and distinguishes itself from siblings like x711_agent_ping and x711_agent_reputation.

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

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

Explicitly states when to use this tool: 'Always call this before x711_agent_ping when targeting unknown agents.' Also provides an alternative for checking own score via x711_agent_reputation.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is clearly non-destructive. The description adds value by stating it's FREE with API key and no credits deducted, and it explicitly lists the return structure, which goes beyond annotations.

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

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

The description is three sentences, each earning its place: first states purpose, second provides usage guidance, third adds cost/return details. No redundancy or wasted words.

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

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

Given there are no parameters and no output schema, the description fully compensates by explicitly listing the return fields (shielded, config, stats) and their subfields. It provides complete information for a read-only status check 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?

There are no parameters, so the description carries no burden. Baseline is 4 for 0 parameters, and the description does not need to add parameter info.

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

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

The description clearly states it reads PingShield config and lifetime stats, using specific verb 'Read' and resource 'your own PingShield config and lifetime stats'. It distinguishes from siblings like ping_shield_check and ping_shield_update, which are different 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?

The description explicitly says to use it for monitoring inbox protection and tuning thresholds based on real traffic, providing clear context. It implies when to use, though it doesn't explicitly state when not to use or name alternatives, which is acceptable given sibling tools.

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

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

Discloses cost ($0.10), auth requirement (API key), and return fields. Annotations are minimal (readOnlyHint false, etc.), so description carries the burden well. No contradictions.

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

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

Single dense paragraph covers all key points, but could be improved with structure (e.g., bullet points). However, it is front-loaded with the core purpose and efficient in word count.

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 4 parameters, no output schema, and complex behavior (threshold, lists, message), the description adequately explains what the tool does, how to use it, and what it returns.

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

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

Schema coverage is 100%, but description adds value: explains threshold range (0-100), max list sizes (50), max message length (280 chars), default threshold (50), and references related tool x711_agent_reputation.

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

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

The description clearly states it activates a reputation-gated inbox that blocks low-rep senders from reaching via x711_agent_ping. It distinguishes from siblings like x711_ping_shield_check and x711_ping_shield_update by focusing on subscription and setup.

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 guidance: 'The smart sender move: call x711_ping_shield_check before pinging to avoid wasting credits on a blocked attempt.' Also mentions API key requirement. Could be more explicit about when not to use vs update, but current guidance is good.

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 mutability (readOnlyHint=false). The description adds the cost ($0.02) and return shape ({ updated, config }), which are useful behavioral details not captured by annotations.

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

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

Three sentences, no filler. Front-loaded with purpose, then usage note and cost/return. 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?

Covers partial updates, cost, and return format. No output schema exists, but the description provides sufficient shape. For a 5-parameter tool with no nested objects, it is complete enough.

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 detailed descriptions for each parameter. The description adds 'Send only the fields you want to change' but does not add new semantic details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Update') and resource ('PingShield') and lists the configurable settings (reputation threshold, whitelist/blacklist, shield message, pause/resume). It clearly distinguishes from siblings like 'x711_ping_shield_check' which reads status.

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

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

Explicitly instructs to send only fields to change, and notes API key requirement. Does not provide explicit when-not-to-use or alternative tool names, but the sibling list and partial-update guidance are 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 and idempotentHint. The description adds value by specifying the data source (CoinGecko), output structure, rate limits (10 calls/day), and that no API key is needed, fully disclosing behavioral traits beyond annotations.

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

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

The description is concise and front-loaded with the core purpose. Every sentence adds essential information (source, use case, rate limits, output format) without redundancy, making it efficient 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?

Given the tool's simplicity, the description covers all necessary aspects: purpose, usage, parameters (via schema), output schema (provided), and annotations. It fully equips an agent to select and 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 coverage is 100%, so baseline is 3. The description adds value by explaining the 'query' parameter usage (single/multiple, case-insensitive) and listing supported assets with examples, going beyond the schema's descriptions.

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

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

The description clearly states it is a live crypto price feed via CoinGecko, returning real-time USD price and 24h change. It lists supported assets and explicitly mentions use before tx_simulate, distinguishing it from sibling tools like x711_hive_*.

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

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

The description provides explicit usage context: 'Use before tx_simulate to get current gas cost in USD.' It also mentions free tier and no API key. However, it does not specify when not to use or list alternatives, though 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=true, so the description does not need to reaffirm safety. It adds valuable context: cost ($0.08), required API key, and that it returns a risk-flagged recovery plan. 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 three sentences, front-loaded with the main purpose, and each sentence adds essential information. No wasted words.

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

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

Given the tool's low complexity (2 params, no output schema), the description adequately covers what it does and what it returns. Could mention more about the recovery plan format, but not necessary for basic understanding.

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 both parameters having descriptions. The description adds an example for execution_trace and notes context is optional, but does not provide significant new meaning beyond the schema. Baseline is appropriate.

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

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

The description uses a specific verb ('Submit') and resource ('agent execution trace'), and clearly states the action: cross-referencing against patterns and returning a recovery plan. It distinguishes itself from sibling tools like x711_agent_act or x711_hive_read by focusing on audit/analysis rather than execution or 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 implies usage for catching 'silent brittle behavior before it causes real losses,' providing clear context for when to use. It does not explicitly state when not to use or list alternative tools, but the intended use case is well communicated.

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

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

Discloses API key requirement, data sources (CoinGecko + DexScreener), and return fields. Annotations only provide readOnlyHint and openWorldHint; description adds critical behavioral context without contradiction.

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

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

Concise, front-loaded with purpose, no redundant information. Every sentence adds value.

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

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

Without output schema, description lists return fields. Mentions data sources and API key. No discussion of rate limits or pagination, but adequate for a simple query 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 already describes 'token' with examples. Main description does not add additional meaning or constraints beyond the schema. Schema coverage is 100%, so baseline 3 is appropriate.

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

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

Clearly states it provides crypto social sentiment with specific outputs (sentiment score, trending status, community size, developer activity). Distinct from siblings like x711_onchain_insight or x711_price_feed.

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 before trading decisions', providing a clear context. Does not list alternatives or when not to use, but the directive is helpful.

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 (which only hint at non-read-only and non-idempotent), the description reveals cost ($0.03 USDC), royalty ($0.02), and return value (copy with agent_id attached). This adds significant 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?

Four sentences covering purpose, cost, royalty, output, and guidance. Every sentence is informative and nothing is wasted. Highly concise.

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

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

For a simple tool with one parameter and no output schema, the description covers cost, royalty, return value, and where to get IDs. It is nearly complete, though could mention that the fork creates a new owned strategy.

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

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

Schema covers 100% of parameters with a description for 'strategy_id'. The description reinforces with a concrete URL and endpoint hint for obtaining IDs, adding value 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 'Fork a published strategy' with a specific verb and resource. It distinguishes from the sibling 'x711_strategy_publish' by mentioning 'published strategy', though it does not explicitly contrast the two.

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

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

The description implies usage when you want to copy a strategy and provides browsing instructions, but it does not explicitly state when to use this tool over alternatives or 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 adds value beyond annotations: it discloses cost ($0.05 USDC), royalty mechanism, and the fact that the strategy becomes publicly forkable. Annotations already indicate a write operation (readOnlyHint=false); description confirms non-destructive creation.

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

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

Two sentences: first defines purpose, second explains economics. No wasted words, front-loaded with key action and outcome.

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

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

The description covers purpose, cost, and royalties. For a publish tool with no output schema, it would benefit from hinting at return value (e.g., strategy ID). Overall adequate given 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%, so baseline 3. The description does not add extra meaning to parameters beyond what the schema already provides (e.g., 'title' described as 'Short strategy name'). No additional parameter context.

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

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

The description clearly states the verb 'publish' and the resource 'execution strategy to the x711 Strategy Commons'. It distinguishes from the sibling 'x711_strategy_fork' by describing publish as creating a new strategy, while fork implies copying.

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: publishing costs $0.05 USDC and yields royalties. It implies when to use this tool (to create a new strategy) versus forking (to reuse existing). No explicit when-not, but the distinction 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?

Beyond annotations (readOnly, idempotent), the description adds key behavioral traits: cached for 1 hour, costs $0.10, and requires API key. These details help the agent understand side effects and prerequisites. 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 two sentences long, front-loaded with the main purpose, and includes essential details without any fluff. Every word serves a purpose.

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 key output elements (top breakthroughs, domain breakdown) and operational context (caching, cost, authentication). While no output schema exists, the description gives sufficient insight for an agent to decide to invoke the tool. Minor gap: no explicit mention of return format or size, but acceptable.

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 no parameters, so schema coverage is 100%. According to the rubric, 0 parameters earns a baseline of 4. The description does not need to explain parameters, and it adds value by describing the output context.

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

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

The description clearly states the tool provides a daily briefing from SUBSTRATE covering cross-domain evolutionary intelligence. It specifies the content (engine pulse, top breakthroughs, domain breakdown) and distinguishes it from siblings like x711_substrate_domain_digest which likely focuses on a single domain.

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 indicates when to use this tool (to get a daily digest) and provides context such as caching interval and cost. It does not explicitly mention alternatives or when not to use, but the context is clear and helpful.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds behavioral context beyond this: it mentions the tool costs $0.05 and requires an API key. This is valuable information about usage constraints. 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 extremely concise: three sentences that front-load the key purpose ('Domain-targeted SUBSTRATE intelligence briefing'), differentiate from similar tools, and add essential operational details (cost, auth). Every sentence serves a purpose 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?

Despite the tool being simple (one parameter, no output schema), the description covers all necessary context: purpose, scope (domain-specific vs general), input options (enum), cost, and authentication. Annotations already cover idempotency and read-only behavior. No gaps remain; the description is fully complete for effective agent 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% (the only parameter 'domain' has an enum description). The tool description also lists the domains explicitly, adding no new semantics but reinforcing the enum values. With high schema coverage, baseline is 3; the description doesn't add substantial meaning beyond what the schema already provides, so score remains 3.

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

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

The description clearly states the tool generates a domain-targeted SUBSTRATE intelligence briefing. It uses specific verbs ('briefing', 'top lifeforms + breakthroughs') and the resource is clear. The sibling list includes x711_substrate_daily_digest, which is broader, so this tool is well-differentiated as a narrower, higher-signal alternative.

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

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

The description implies usage context: 'Narrower focus, higher signal' suggests using this tool when a domain-specific intelligence brief is needed rather than a general daily digest. The list of domains provides guidance on valid inputs. However, it does not explicitly state when not to use it or mention alternatives beyond the implied contrast with the daily digest, so it misses some explicit 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 provide readOnlyHint=true and idempotentHint=true, so the description adds value by confirming it's free and requires no API key. It does not disclose any side effects beyond what annotations cover, but the added cost context is beneficial.

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 efficient sentences with no fluff. The first sentence states the core purpose, the second adds engaging context, and the third provides practical cost information. Every sentence adds value.

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

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

For a simple read-only tool with no parameters and no output schema, the description covers purpose, cost, and accessibility. However, it omits any hint about the output format or data structure, which could be useful for an agent.

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 no parameters, and schema coverage is 100%. There is no need for parameter descriptions. Baseline for zero parameters is 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 returns 'Agent-seeded lifeforms ranked by fitness score' and explains the context of the SUBSTRATE evolution engine. This differentiates it from sibling tools like x711_substrate_seed_hypothesis or x711_substrate_daily_digest.

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

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

The description mentions it is 'FREE — no credits required (counts toward 10/day free tier). No API key needed,' which implies when to use (low-cost access). However, it does not explicitly exclude other tools or provide when-not-to-use 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?

The description adds significant behavioral context beyond annotations: it mentions mutation (inject, evolves), cost ($0.25), authentication requirement (API key), evolution frequency (every 15 min), and breakthrough possibility. Annotations only indicate readOnlyHint=false, so description provides rich additional detail.

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 action verb 'Inject', and each sentence adds non-redundant information. No wasted words.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers key aspects: purpose, process, cost, and restrictions. However, it does not describe the return value explicitly; it implies the tool returns a name and ID, but not the format or structure. Slightly incomplete but acceptable.

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 an example in the hypothesis parameter description but does not explain parameter semantics beyond what the schema already provides. The example is helpful but not critical extra 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 injects a hypothesis into the SUBSTRATE evolution engine, with specific outcomes: gets a name, ID, starts at 0.5 fitness, evolves every 15 min, and can achieve breakthrough status. This distinguishes it from sibling tools like x711_substrate_daily_digest or x711_agent_evolve.

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

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

The description implies usage for injecting new hypotheses but does not explicitly state when to use it versus alternatives or provide exclusion criteria. With many sibling tools, more explicit guidance would be helpful.

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

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

Annotations provide readOnlyHint=false, openWorldHint=true, idempotentHint=false. The description adds key behavioral context: requires API key, costs $0.02, returns reach and pioneer status, and broadcasts affect trending. This supplements the annotations without contradiction, but could mention error cases or rate 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 remarkably concise: three sentences front-loaded with purpose, then details. Every sentence adds value (purpose, returns, cost, relation to trending). No 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 explains the return object structure and meaning. It also mentions cost and authentication. However, it does not cover failure modes or what happens if the topic doesn't exist, leaving minor gaps.

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

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

Schema coverage is 100% and both parameters are well-described. The description adds value beyond the schema: for 'topic' it gives example slugs and formatting rules; for 'message' it advises on content quality and impact on trending. This enriches the 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 states the tool's purpose: 'broadcast a message to a public topic namespace that any agent monitoring that topic can read.' It uses a specific verb ('broadcast') and resource ('message to public topic namespace'), and distinguishes from siblings like x711_hive_write by mentioning it counts toward hive_trending and is for agent-to-agent broadcasting.

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

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

The description provides context for when to use: 'to broadcast to a topic' and notes that 'Requires API key.' It implies when not to use by indicating this is for public broadcasting to all agents, versus alternative tools like direct agent actions. However, it lacks explicit exclusions or alternatives, so not 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 annotations (destructiveHint=true, readOnlyHint=false), the description adds key behavioral details: private keys never leave the agent, use of public RPC, anonymized pattern writing to the Hive, zero extra latency on core tx path, and viral conquest behavior. 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 informative but slightly verbose with marketing language (tagline). It front-loads the main purpose and is well-structured, but could be trimmed slightly while retaining all necessary information.

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

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

Given the tool's complexity (5 parameters, output schema with return fields listed), the description covers all needed aspects: supported chains, safety guarantees, viral conquest flow, and return structure. No missing context.

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

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

Schema coverage is 100%, and the description adds significant meaning beyond schema: explains chain enum values (bnb/bsc, opbnb), signed_tx format, viral_only and viral_conquest behaviors, and simulation_id linking to tx_simulate. Each parameter is well-documented.

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 purpose: relaying a pre-signed EVM transaction to a list of supported chains (Base, Ethereum, etc.). The verb 'Relay' and explicit resource 'pre-signed EVM transaction' distinguish it from sibling tools like 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 provides usage context by explaining when to use viral_conquest and viral_only modes, and includes chain-specific guidance for BNB. It implicitly links to x711_tx_simulate via the simulation_id parameter. However, it does not explicitly state when not to use this tool vs. 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 adds substantial behavioral context beyond annotations: uses public RPC eth_call + eth_estimateGas, no wallet or API key, live gas prices, USD cost estimation, Hive wisdom enrichment, and return structure. Annotations already mark it as read-only and idempotent.

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 (5-6 sentences), front-loaded with purpose, and each sentence adds value: chains, mechanism, free tier, return structure. No unnecessary 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?

Given multi-chain simulation complexity and presence of output schema, the description covers critical context: simulation before broadcast, free tier, Hive wisdom, and chains. It ties well to sibling tool x711_tx_broadcast.

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

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

Input schema has 100% coverage with descriptions. The description does not add new parameter details beyond what schema provides, 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 it simulates on-chain transactions on multiple chains before broadcasting, and distinguishes from its sibling x711_tx_broadcast with explicit instruction to simulate first.

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 strong usage guidance: always simulate before broadcast, free tier limits, no API key needed. It lacks explicit 'when not to use' but the context is clear as a prerequisite tool.

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

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

Discloses side effects: source memories are archived. Mentions automatic refund on failure and fixed cost ($0.05). Given minimal annotations, this adds meaningful 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?

Four sentences, no wasted words. Front-loaded with the main action, then effects, then reliability and cost. 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?

Covers input, transformation, side effect, reliability, cost. Lacks explicit output format description, but the outcome ('5 dense summaries') is implied. Adequate for a simple tool with no output schema.

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

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

No parameters in schema (0 params, 100% coverage). Description does not need to add parameter info, but it logically explains the compression process, which is appropriate for a parameterless tool.

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

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

Clearly states the specific verb 'compress' and the resource 'vault', with a precise transformation: 50 cold memories → 5 dense summaries. Distinguishes from sibling vault tools like query/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?

Explains the benefit ('sharper vault, lower LLM token cost') and prerequisites ('Requires API key'). Provides context for when to use (to reduce injection cost) but doesn't explicitly state when not to use or name 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 adds meaningful behavioral context beyond the annotations (readOnlyHint, idempotentHint) by explaining the ranking formula (cosine similarity × confidence × importance), that it's free, and the access restrictions. 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 three sentences with no redundant information. The first sentence states the core action, the second clarifies what is retrieved, and the third covers cost and security. 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?

Despite lacking an output schema, the description clearly indicates the return type ('ranked memories by cosine similarity × confidence × importance') and what it recalls ('facts, insights, and skills'). For a simple search tool with two parameters, this is fully 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?

Schema coverage is 100% with descriptions for both parameters. The description adds value by providing natural language examples for the 'q' parameter ('USDC contract address Base chain' etc.), which helps the agent craft effective queries. The 'limit' parameter is already well-documented in schema.

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

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

The description explicitly states 'Semantic vector search across your private vault' with a specific verb (search) and resource (private vault). It distinguishes itself from sibling tools like vault_write (write) and external search tools by focusing on the agent's own accumulated memories.

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: 'FREE always', 'Requires API key', and 'reads your vault only — other agents cannot access it'. It implies when to use (to recall personal memories) but does not explicitly name alternatives like vault_write for storing or web_search for external info, leaving some room for improvement.

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

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

Adds significant behavioral context beyond annotations: auto-decay timers, pricing tiers, privacy, and API key requirement. No contradiction with annotations (readOnlyHint: false, idempotentHint: false).

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

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

Concise and well-structured: covers purpose, key details, pricing, and pairing in a few sentences without 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?

Complete for a write tool: explains what happens, types, decay, pricing, privacy, and API requirement. No output schema, but return behavior is implied.

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 3. Description adds overarching context (e.g., decay timers linked to type), but parameter details are already well-explained in the schema.

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

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

The description clearly states it writes a private memory pack to the agent's personal vault, specifying the types of data (facts, insights, context, skills) and distinguishing from sibling tools like vault_query and vault_compress.

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 guidance on when to use (persisting information), includes decay timers, pricing, and pairing with vault_query, and mentions API key requirement. Lacks explicit 'when not to use', but context is clear.

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

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

The description adds significant behavioral context beyond annotations: it mentions the cost ($0.05), API key requirement, and the exact return data (balance, age, entity label, transaction history, token holdings, risk flags). Annotations already indicate read-only and idempotent behavior, and the description complements them 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 concise (4 sentences), front-loaded with the core functionality, and every sentence adds value. No fluff or redundancy. Structure is clear: purpose, return data, usage advice, supported chains, cost.

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 absence of an output schema, the description does an excellent job listing return fields (balance, age, entity label, transaction history, token holdings, risk flags) and provides context on pricing, API key, and supported chains. It gives the agent enough information to understand the tool's output and constraints.

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 for both parameters. The description mentions 'address' and 'chain' but does not add significant new meaning beyond what the schema already provides (e.g., default chain, address format). Parameter semantics are adequately covered by the schema.

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

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

The description clearly states it provides a 'Forensic address intelligence report via Blockscout multi-chain' and lists specific return fields (balance, age, entity label, etc.). It differentiates itself from sibling tools which are primarily about agent actions, searches, or other blockchain operations, making the purpose distinct.

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 advises to 'Run before sending USDC to any unknown address,' providing a clear use case. It lists supported chains but does not explicitly state when not to use or mention alternative tools for similar tasks. The guidance is good but not exhaustive.

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

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

Description details the automatic fallback chain, guaranteed return of results, and the return format. Annotations (readOnlyHint, openWorldHint) are consistent, but description adds context: fallback behavior, free tier limits, and no API key needed. 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?

Description is concise (5 sentences), front-loaded with the core purpose, and provides essential details (fallback, best uses, output structure) without unnecessary verbosity.

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-source fallback and the presence of an output schema, the description covers all key aspects: sources, fallback, result format, and rate limits. It is fully informative for an agent to use correctly.

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

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

Only one parameter 'query' with 100% schema coverage (description includes examples). The tool description does not add significant meaning beyond the schema, as schema already describes natural language/keywords. Baseline 3 is appropriate.

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

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

Description clearly states it is a 'Multi-source web search' with specific sources (HackerNews, Wikipedia, DuckDuckGo, x711 Hive). It also specifies target query types (tech/AI/crypto, current events, documentation). This distinguishes it from sibling tools like x711_deep_search or x711_hive_consensus.

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 'Best for: tech/AI/crypto queries, current events, documentation discovery.' This provides clear when-to-use guidance. Does not explicitly state when not to use, but the scope is well-defined. Could mention alternatives like x711_deep_search for comprehensive research.

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 description adds value by stating it is free and requires no API key. No contradictions.

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

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

The description is two sentences: first states the primary action, second lists return values and key features. No wasted words, front-loaded with the verb.

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

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

The description covers purpose, return structure, and scope (any x402 API). No output schema exists, but the description lists returned fields, which is sufficient for a simple parsing tool with annotations.

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

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

Schema coverage is 100% with a clear description for the single parameter. The description does not add significant new detail beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool parses x402 (HTTP 402) response bodies and returns structured payment instructions. It distinguishes itself from siblings by being the only parsing tool for this specific 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?

The description explicitly states when to use: for any x402 response body. It implies usage context but does not provide alternative tools or when-not-to-use, though no siblings overlap.

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