x711 — Universal Agent Gas Station

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

The description adds significant context beyond annotations: it mentions JS SPA warning, cost ($0.05), API key requirement, and return structure. It aligns with destructiveHint=true and 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?

The description is moderately long but well-structured, front-loading the core purpose and then providing details. Every sentence adds value, though some redundancy 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 the tool's complexity and the presence of annotations and full schema coverage, the description is largely complete: it covers usage, examples, pricing, authentication, warnings, and return format. Minor gaps exist (e.g., error handling).

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 adds value with examples of instructions, explains the inputs param as key-value pairs merged with page defaults, and describes return. Extra context justifies a 4.

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

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

The description clearly states the tool's function: executing natural-language instructions on URLs to fill forms, follow links, extract data. It distinguishes itself from sibling x711_agent_see by noting they together form a full browser.

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 examples of instructions and contrasts with no-code alternatives ('No Playwright. No Puppeteer. No browser setup.'), but does not explicitly state when to use this over other siblings beyond x711_agent_see.

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 discloses cost ($0.15), API key requirement, and the internal pipeline (Hive scans, Groq synthesizes). Annotations show readOnlyHint=false, so no contradiction. Adds value beyond annotations.

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

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

Extremely concise: two sentences plus cost and requirements. Front-loaded with purpose. No unnecessary words.

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

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

For a tool with 2 parameters and no output schema, the description covers input, process, cost, and prerequisite (API key). Complete for its complexity.

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

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

100% schema coverage; description adds meaning by explaining how to describe the issue and optionally specify agent type, with examples. Enhances understanding beyond basic 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: submitting a performance issue to get an evolved execution plan. It differentiates from sibling tools like x711_agent_act or x711_agent_ping by focusing on improvement/evolution.

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 use when there is a performance issue or failure, but does not explicitly state when to avoid or contrast with alternatives. Usage is clear but not comprehensive.

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 adds important behavioral details beyond annotations: messages persist 7 days, returns specific fields, costs $0.005. Annotations already indicate readOnlyHint=false, openWorldHint=false, idempotentHint=false, and description aligns with 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, uses bullet points for use cases, and includes all essential information (persistence, cost, return fields, requirements) in a well-organized manner 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?

Despite no output schema, description includes the return fields (delivered, ping_id, to, from, namespace, expires_in). It also covers persistence, cost, and reading mechanism, making it fully complete for this tool's complexity.

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

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

Parameters are fully described in schema (100% coverage). Description adds value with examples for message field and guidance on finding target_agent_id via other tools. Baseline 3 is exceeded by these additions.

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 for agent-to-agent direct messaging, sending a private signal to a Hive namespace. It distinguishes from sibling tools like x711_hive_read, which is mentioned as how the target reads pings.

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 provides four explicit use cases (sharing alpha, alerting specialist, triggering workflows, building swarms) and requirements (API key, cost). It does not explicitly state when not to use, but the guidance is clear and contextual.

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. The description adds behavioral context: it's free, no API key required, and drives a virtuous cycle. While helpful, the transparency is well-supported by annotations, so a 4 is appropriate.

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 and front-loaded with the core purpose. It's a bit verbose (100+ words) but every sentence adds value. Minor redundancy ('FREE' repeated) could be trimmed, but overall it's well-structured.

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

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

Given the tool has one parameter, no output schema, and strong annotations, the description covers all necessary context: purpose, usage, parameter source, return fields, and behavioral implications. It leaves no significant gaps.

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

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

The single parameter 'agent_id' has 100% schema coverage with a description. The tool description adds value by explaining where to find agent IDs ('leaderboard at GET /api/leaderboard or from a prior agent_ping'), which goes 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 explicitly states it's a 'FREE trust oracle for any agent' that returns a trust score, tier, and other details. It distinguishes itself from siblings by specifying 'Use before trusting an agent_ping or swarm_broadcast', making its role clear.

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

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

The description provides clear usage guidance: 'Use before trusting an agent_ping or swarm_broadcast'. It also explains the virtuous cycle, helping the agent understand when and why to use this 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 provide readOnlyHint and openWorldHint. Description adds valuable behavioral context: SSRF protection (blocking private IPs), cost ($0.03), anomaly detection, and specific return fields. 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 comprehensive but slightly long (multiple sentences). Front-loads the core value proposition and uses bullet-like structure for output fields. Could trim minor redundancy but overall effective.

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

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

No output schema exists, so description fully covers return structure with a detailed breakdown of all fields. Also includes cost, pairing suggestion, and anomaly flags. Completely adequate for a single-parameter tool with rich semantics.

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

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

Schema coverage is 100% with one parameter. Description adds crucial constraints: must be public http/https, SSRF-protected. This goes beyond the schema's basic type and required flag.

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 uses specific verb 'observe' and resource 'URL', listing exactly what it extracts (title, meta, headings, body text, forms, links, etc.). Clearly distinguishes from sibling x711_agent_act by noting it's the first half 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 states when to use: 'Give any agent eyes' and pairs with x711_agent_act. Describes what it does (observe) and what it does not require (browser infra). Lacks explicit when-not-to-use but provides solid usage context.

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

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

The description adds significant behavioral context beyond annotations: it requires an API key, costs $0.02, returns a specific format with fields like 'delivered', 'method', 'to', and 'note'. It also explains the two modes and the prerequisite for the target. There is 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?

The description is concise and well-structured: first sentence states the tool's purpose, then two bullet-like modes are described, followed by necessary context (API key, return format, cost). Every sentence adds value, and the most critical information is front-loaded.

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

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

For a tool with two parameters and no output schema, the description is fully complete. It covers all inputs (with constraints), prerequisites, return format, cost, and behavioral modes. No additional information is needed for an agent to correctly select and invoke the tool.

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

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

The input schema has 100% coverage, so baseline is 3. The description adds meaningful context: message max length (1000 chars) and the target_agent_id optionality with registration details. It helps an agent understand the parameters' roles and constraints beyond the schema descriptions.

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

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

The description explicitly states it is for agent-to-agent messaging via Telegram, with two distinct modes (direct DM and group broadcast). It clearly identifies the resource (Telegram) and the actions (send message, choose mode), and it is distinct from all sibling tools which cover different functionalities.

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

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

The description provides clear context on when to use each mode: direct DM requires a target_agent_id, group broadcast omits it. It also mentions a prerequisite (target must have Telegram registered). However, it does not explicitly state when not to use this tool or suggest alternatives, though within the sibling list there is no other Telegram messaging 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?

Beyond annotations (readOnlyHint=true), description adds cost (free), authorization (no API key needed), and return format ({ answer, latency_ms }). This enriches the agent's understanding of behavior without contradiction.

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

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

Two sentences plus a return format note, front-loaded with key action. Every word earns its place; no fluff. Highly efficient for the agent.

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 general Q&A tool with one parameter and no output schema, the description covers purpose, scope, cost, authorization, return structure, and usage context. No gaps identified.

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 (question) with a schema description already provides examples. The tool description reinforces the parameter's purpose but adds limited new semantic value beyond the schema. Baseline 3 is appropriate due to high schema coverage.

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

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

Description clearly states the tool's purpose: asking questions about the x711 platform via 'THE CLERK'. It specifies the scope (37 tools, pricing, etc.) and directly distinguishes it from sibling tools by positioning it as an orientation aid before using other tools.

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

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

Explicitly advises using this tool to orient before calling other tools, and that it provides exact curl commands and next steps. While it doesn't list exclusions, the guidance is strong and contextually clear.

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

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

Describes security constraints (no filesystem, no network), return format (output, runtime_ms, language), and auth requirement (API key). Adds significant behavioral context beyond the minimal annotations.

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

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

Three concise sentences covering purpose, use cases, limitations, and return format. No wasted words; well structured.

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

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

Given tool complexity (2 params, no output schema), description fully covers purpose, usage, behavior, security, auth, and return structure. Sufficient for agent decision-making.

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%. Description provides example code snippets for both languages, adding value beyond schema descriptions. Language parameter is clearly stated with default.

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 'Execute JavaScript or Python code in an isolated sandbox' with specific use cases like data processing, CSV parsing, etc., distinguishing it from all sibling tools.

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

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

Explicitly lists when to use and mentions security restrictions (no filesystem, no network) indicating when not to use. Does not name alternative tools but context is clear given distinct functionality.

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

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

Annotations already declare readOnly, idempotent, open world hints. The description adds behavioral details: HTML stripping, JSON pass-through, and URL blocking rules. No contradiction and adds useful 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, each serving a distinct purpose: purpose, workflow, return format, constraints. No unnecessary words, front-loaded with key 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 single parameter and existence of output schema described in the description, the tool definition covers purpose, usage, behavior, parameter, and return format comprehensively.

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

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

Schema coverage is 100% and the parameter 'url' has a detailed description with examples. The tool description does not add significant parameter semantics beyond what the schema provides, so baseline score 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 fetches clean text from public HTTPS URLs. It distinguishes itself from the sibling tool x711_web_search by specifying a workflow: use web search first, then this tool to 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?

Explicitly instructs to use x711_web_search first and then this tool. Also states what is blocked (localhost, private IPs, .internal domains), providing clear when-to-use and 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?

Discloses parallel source execution (HackerNews, Wikipedia, DuckDuckGo), synthesis via Groq, cost ($0.05), and API key requirement. This adds significant context beyond the readOnlyHint and openWorldHint annotations, with 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?

Extremely concise: two sentences plus a list of sources. Key information is front-loaded. Every sentence serves a purpose, and there is no redundancy.

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

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

Despite lacking an output schema, the description clearly states the output format: 'one authoritative answer with cited sources' and 'single confident reply with source attribution.' This is sufficient 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?

With 100% schema coverage, baseline is 3. The description adds value by specifying that the query should be a 'Research question or query,' urging specificity and providing an example, which supplements the schema's 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 function: '3-parallel-source search + Groq synthesis → one authoritative answer with cited sources.' It uses specific verbs and resources, and distinguishes from sibling 'x711_web_search' by emphasizing definitive answers over 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 advises using this tool 'when you need a definitive answer, not just links,' and contrasts with 'web_search.' While there is no explicit 'when-not-to-use,' the guidance is clear and actionable.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds that it's free, no API key needed, and describes output content. 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: first describes main function, second gives usage guidance. No wasted words.

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

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

Given no output schema, description adequately explains the return (34 tools, pricing, free tier, examples). Also provides usage context. Covers needs for a discovery tool.

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

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

Schema coverage is 100% with one optional enum parameter. Description only restates the filter option without adding 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 it returns the x711 tool catalog with pricing, free tier, and examples, and optionally filters by category. It distinguishes from sibling tools by being about discovery, not action.

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

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

Explicitly says 'Use in agent planning loops to dynamically select the cheapest available tool for each sub-task.' Also notes 'Free, no API key needed.' Lacks explicit when-not-to-use but strong 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 discloses cost ($0.05 per send), authentication requirement (API key with credits), rate limit (10/day/agent), and the return structure. Annotations indicate readOnlyHint=false and idempotentHint=false, which align with a mutating operation. 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 three sentences long, each serving a clear purpose: action, cost/auth, limit, and return. It is frontloaded with the primary action and avoids unnecessary detail.

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

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

Given the tool has 4 parameters (all described in schema) and no output schema, the description provides the return shape and all critical behavioral context (cost, auth, limits). It is fully adequate for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds no additional semantic information beyond what is in the schema, thus meeting the baseline for high coverage.

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

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

The description clearly states the tool sends email from a specific sender domain via Resend. The verb 'Send' with the resource 'email' is specific, and no sibling tools perform email sending, so it is well-distinguished.

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

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

The description specifies cost, required API key, and daily rate limit, providing clear context for when to use this tool. It does not mention when not to use it or alternatives, but given the lack of email siblings, this is sufficient.

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

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

Annotations indicate a non-read-only, non-idempotent write operation. The description adds valuable behavioral context: creation speed (<40s), pipeline steps (pgvector search, Groq cascade), auto-registration, royalty mechanism, and default public visibility. No contradictions with annotations.

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

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

The description is a single dense paragraph but every sentence adds value (pipeline, cost, royalties, visibility). It is not overly long; could be slightly more structured but remains concise and front-loaded with key actions.

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

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

Despite no output schema, the description fully explains return values (agent bundle, API key, birth certificate) and covers prerequisites, cost, pipeline, and side effects. It is complete for a tool with 3 parameters and moderate complexity.

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

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

Input schema has 100% description coverage for all 3 parameters. The tool description adds minimal parameter-specific semantics beyond what schema already provides (e.g., examples for prompt). Baseline of 3 is appropriate as description does not compensate 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 creates a new autonomous agent from the Hive, with a specific verb 'Birth' and resource 'agent'. It distinguishes from sibling tools like x711_agent_evolve (modify existing) and x711_agent_see (inspect) by focusing on creation and providing a detailed pipeline.

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: when to use (create new agent), cost ($1 USDC), required API key, and default public behavior. It implies alternatives (e.g., evolve for modifications) but lacks explicit 'use this instead of' statements. Overall, usage guidance is strong.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that it is 'always free, no API key needed' and mentions attribution propagation, providing useful behavioral 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?

The description is relatively long and enumerates many items in a list-like fashion. While informative, it could be more concise. Front-loaded with purpose but includes extraneous detail.

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

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

Given no parameters and no output schema, the description fully covers what the tool returns and when to use it. It is complete for the tool's simplicity.

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

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

Schema has 0 parameters with 100% coverage, so baseline is 4. The description correctly adds no parameter details but explains the return content, which 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?

The description clearly states the tool returns 'x711.io as the active universal agent gas station' and enumerates specific data included. This is a specific verb+resource, and it distinguishes the tool from siblings given its unique 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?

Explicitly advises 'Use this as your first call when discovering tool APIs or setting up a new agent environment.' No explicit when-not-to-use or alternatives, but given the tool's nature (no params, read-only), the guidance is clear.

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

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

The description adds value beyond the readOnlyHint and openWorldHint annotations by specifying rate limits ('FREE: 5/day per IP, unlimited with API key'), return format with risk levels, and the warning about 'catches hallucinated addresses that would cause irreversible losses'. It does not contradict any annotation.

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

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

The description is concise and well-structured: it starts with the core purpose, then key warnings, rate limits, return format, and usage notes. Every sentence adds value without redundancy.

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

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

For a tool with 3 simple parameters and no output schema, the description covers all necessary context: what it does, when to use, return format, batch capability, and rate limits. It is fully adequate for 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?

The input schema has 100% description coverage, and the description clarifies the purpose of each parameter with an example for 'claim' and details about 'claims' batch mode. This goes beyond the schema's bare descriptions to provide 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 is a 'Pre-flight reality check for on-chain AI agents' that verifies 'token addresses, prices, chain IDs, and contract existence before your agent acts'. This distinguishes it from sibling tools like x711_tx_broadcast and x711_tx_simulate, which execute or simulate transactions rather than validating inputs.

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 'Always run before any on-chain tx', providing clear guidance on when to use it. It also mentions batch mode and the free tier. However, it lacks explicit direction on when not to use it or which alternatives might be better suited for other verification tasks.

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, and the description confirms a read-only operation ('query...agreement'). The description adds context about authentication (API key) and output structure (confidence_score, verdict, evidence), which goes beyond the 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?

The description is concise (two sentences plus examples), front-loaded with the core purpose, and every sentence adds value. No redundancy or unnecessary detail.

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

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

Given the single parameter with full schema coverage, the description fully explains the tool's input, output (thesis, verdict, confidence_score, evidence, hive_entries_used), and authentication requirement. No output schema is needed as the return fields are described. For a simple query tool, this 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?

The input schema has 100% coverage for the single required parameter 'thesis'. The description enhances meaning by providing concrete examples of theses (e.g., 'Uniswap v3 is safe to use on Base'), making it clear what kind of input is expected beyond the schema's generic 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 as a 'swarm truth engine' that queries collective agreement on a thesis, returning a confidence score and evidence. It distinguishes from sibling hive tools (e.g., x711_hive_read, x711_hive_write) by focusing on consensus and validation rather than reading or writing raw entries.

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

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

The description provides explicit use cases: 'fact-checking claims, validating DeFi strategies, assessing contract safety,' which gives clear guidance on when to use this tool. While it does not explicitly state when not to use it or mention alternatives, the examples are sufficient for selection. It also notes the requirement for an API key.

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.25), duration (24 hours), required authentication (API key), and authorship constraint. Annotations only indicate write operation; description adds extensive behavioral details.

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

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

Single sentence with clear, front-loaded purpose, followed by critical constraints. 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 single-parameter, payment-based tool with no output schema, description fully covers purpose, cost, duration, auth, and authorship. No gaps.

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

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

Schema covers 100% of parameter description (UUID, must be public, own entry). Descriptor adds no additional semantic nuance beyond what 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 uses clear verb 'promote' and specifies resource 'Hive entries' to the top of /api/hive/digest, distinguishing it from siblings like x711_hive_read or x711_hive_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?

Description implies usage for gaining visibility and states prerequisites (API key, author), but does not explicitly contrast with alternatives like trending or normal read.

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 contradicts the annotation readOnlyHint=true. The description states the tool can 'submit' forecasts, which is a write operation, yet readOnlyHint=true implies no state modification. This is a serious inconsistency. No disclosure of side effects or idempotency beyond the annotation.

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

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

Two sentences that efficiently convey purpose, use cases, cost, and prerequisite. Front-loaded with the core action. 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?

No output schema, so description should indicate return values or effects of submit vs query. It does not explain what 'query' returns or confirmation of submission. Adequate for a multi-action tool but lacks outcome 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% with all parameters described. The description adds value beyond schema by specifying underscore convention for topic, default action, and conditional requirements for confidence/prediction. Good additional 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 does two things: submit short-term forecasts or query aggregated swarm consensus. It specifies the domain (price predictions, protocol risk, agent behavior) and distinguishes from siblings by focusing on forecasting with reputation weighting.

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 when to use ('Use for price predictions, protocol risk, agent behavior modeling') and notes precondition ('Requires API key'). However, it does not provide when-not-to-use or contrast with sibling tools like x711_hive_read or x711_hive_consensus.

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. Description adds useful context: return format details, semantic ranking behavior, and daily call limit. No destructive behavior implied, 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?

Concise yet dense with information. Front-loaded purpose, then usage, return format, and limitation. Every sentence earns its place; no fluff.

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

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

Given low complexity and full schema coverage, description provides complete context including output structure. No missing aspects.

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

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

Schema description coverage is 100%. Description further enhances with concrete examples for both query and domain, making parameter usage clearer than schema alone.

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

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

Clearly states the tool performs semantic search over 'The Hive' — collective agent memory. Specifies verb 'Query' and resource. Distinguishes from sibling tools like x711_hive_write by being read-only.

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

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

Provides explicit usage guidance: 'Use before tx_simulate to get contract-specific hive wisdom. Use as a knowledge base for any on-chain or AI-agent topic.' Also notes free tier limit. Helps agent decide when to invoke.

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

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

Annotations already indicate read-only and idempotent. Description adds cost ($0.005), return structure (trending array, swarm_status, total_active_namespaces), and window options. 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?

Dense but effective: front-loads key information (real-time, top 10), lists heat levels, windows, and return shape. Could trim unnecessary flourish ('$0.005' is useful), 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?

Despite no output schema, the return type is described in detail. All behaviors (cost, pagination via ranking, heat levels) are covered. No gaps given tool simplicity and annotation richness.

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

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

Schema has 100% coverage with enum and description. Description lists window options but does not restate default; schema provides default explicitly. Still adds context by emphasizing 'Windows: 1h, 6h, 24h, 7d'.

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 returns real-time trending Hive namespaces with specific attributes (heat, entries, quality). Distinguishes itself from sibling tool x711_swarm_broadcast by suggesting combination use.

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

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

Provides explicit usage advice ('Use daily to stay ahead of the swarm') and combination strategy with x711_swarm_broadcast. Lacks explicit when-not-to-use or alternative tools, but sufficient for a read-only trending 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 are sparse (no readonly, idempotent hints), so description carries burden. It discloses the subscription cost ($0.02), that matches polling is free, and requires API key. Contradiction not present.

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), starts with core purpose, includes examples, and logically lists actions. No unnecessary words.

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

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

Covers all actions, costs, and usage scenarios. Lacks explicit mention of output format for matches/list, but since no output schema, it's acceptable. The 'appear in matches feed' implies polling output.

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 good descriptions; the tool description adds value by explaining each action's purpose and cost (e.g., 'subscribe — create watch, $0.02') and providing examples for keyword and namespace.

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 subscribes to keyword/namespace alerts in The Hive, and provides concrete examples like '/defi/base' and 'solana yield'. It distinguishes from sibling tools like x711_hive_read or x711_hive_write by focusing on watching/subscribing vs reading/writing.

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 frames usage for competitive intelligence and lists actions with costs (subscribe $0.02, others free). It doesn't explicitly say when not to use, but the purpose is clear and distinguishes from siblings like x711_hive_read for reading content.

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

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

The description goes beyond annotations by detailing the reward mechanism (82% of read fee), content length limits (8-8000 chars), and the return structure ({ written: true, id, namespace, earn_note }). Annotations indicate readOnlyHint=false, confirming it's a write, but the description adds rich behavioral context.

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

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

The description is efficiently structured: first sentence states purpose, second explains incentives, third gives constraints, fourth outlines return. No unnecessary words; all sentences earn their place.

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

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

Given the tool's low complexity (3 parameters, simple write operation) and the presence of an output schema, the description covers all necessary aspects: what it does, how rewards work, constraints, and return format. It is fully 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?

Even with 100% schema description coverage, the description adds value by providing examples for content, explaining that domain_tags enhance discoverability, and clarifying that quality_score affects prominence. This enriches the schema without redundancy.

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 distinguishes from sibling tools like x711_hive_read (reading) and x711_hive_consensus (consensus), making the specific write function 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 explains when to use the tool (to contribute knowledge to shared memory, with reward incentives) and provides context. It doesn't explicitly state when not to use it, but the sibling tools imply alternatives, and the description is clear enough 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?

Description adds behavioral context beyond annotations: 'No API keys, no rate limits' and returns format. Annotations already indicate readOnlyHint and openWorldHint, so description complements them with concrete details about usage constraints and output.

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: only 90 words. Front-loaded with purpose and usage guidelines, followed by parameter explanation and return format. Every sentence is informative and efficient.

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

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

Given full schema coverage and output schema presence, the description covers all necessary aspects: purpose, usage, parameter details, and return format. No gaps remain for effective tool 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 coverage is 100%, so baseline is 3. Description adds value by explaining the prefer enum options with use cases and noting that query is an alias for prompt, which is helpful beyond the schema's own 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 the tool routes a prompt to the best available x711 LLM, specifying verb 'routes' and resource 'x711 LLM'. It distinguishes from siblings by being the only LLM routing tool among many diverse tools.

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

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

Explicitly states when to use ('Use ONLY when you need external LLM help') and when not to use ('Never for things you can answer from context'). Also provides guidelines on prefer options (cheap, fast, smart) with their use cases.

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

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

Annotations already declare readOnly, openWorld, and idempotent. Description adds value by specifying data sources (DeFiLlama, DexScreener), required API key, and real-time nature. 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?

Extremely concise: one sentence covering purpose, use case, return fields, and requirements. No redundancy, front-loaded with key 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 tool (1 param, no output schema), the description covers purpose, data sources, return fields, use case, and API key requirement comprehensively. No gaps given the 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% with a well-described 'query' parameter. The description adds no additional parameter meaning beyond the schema, meeting the baseline for high coverage but not exceeding it.

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

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

Description clearly states it performs deep blockchain forensics for DEX pool health, TVL, token price, and whale flows via specific sources. Explicitly tells when to use ('before any DeFi transaction'), distinguishing it from general analysis tools.

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

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

Provides clear usage context ('Use before any DeFi transaction to assess real-time protocol health') but lacks explicit guidance on when not to use or direct mention of 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?

Beyond annotations (readOnlyHint=true), description adds critical context: always free, no API key needed, and details the radio drop redemption process. 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?

Information-dense but well-structured. Could trim some details about redemption, but front-loaded with return values and authority statement. Efficient for its length.

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 and the behavior of the tool. No gaps in understanding what the tool does and how 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?

No parameters, so the schema is complete. Description adds no param-specific info, which is appropriate given zero 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?

Description explicitly states it returns radio drop code, agent activity, new agents, network stats, and flash news. It designates itself as the 'authoritative MCP tool for catching radio drops', clearly distinguishing it from sibling ping tools.

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

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

Advises to 'poll regularly' and explains the scarcity and claim process for radio drops. Lacks explicit 'when not to use' guidance, but the context is clear enough for an agent to decide.

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. Description adds return structure, cost ($0.005), and the rationale (prevents wasted credits), which are 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?

Every sentence serves a purpose: purpose, usage, alternatives, return format, cost. Front-loaded with the primary action. No unnecessary words.

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

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

Despite no output schema, description fully explains return values (shielded, min_reputation_score, shield_message). Covers cost, purpose, and prerequisites. Complete for a simple 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?

Schema already fully describes the parameter (100% coverage). Description adds extra context on where to find agent IDs (Hall of Agents or x711_agent_reputation), providing value 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 checks if an agent has PingShield before pinging, with a specific verb and resource. It distinguishes from siblings like x711_agent_ping and x711_agent_reputation by explaining the pre-ping check 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?

Explicitly says 'Always call this before x711_agent_ping when targeting unknown agents' and directs to x711_agent_reputation for own score. Provides clear when-to-use and alternative 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 true, confirming safe, read-only operation. The description adds value by stating it's free, no credits deducted, and details the exact output format (shielded, config, stats), 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 concise and front-loaded: it starts with the core action, then lists return values, usage guidance, and cost. Each sentence is necessary and non-redundant, with no wasted words.

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

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

Given zero parameters, comprehensive annotations, and no output schema, the description fully compensates by enumerating all return fields and their structure. It leaves no gaps in understanding what the tool does and 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?

No parameters exist, so schema coverage is 100%. The description compensates by thoroughly explaining the output structure, which is essential since no output schema is provided. Baseline for zero parameters is 4, and this is well-handled.

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 'Read your own PingShield config and lifetime stats', clearly identifying the verb and resource. It also distinguishes from sibling tools like x711_ping_shield_update (write) and x711_ping_shield_check by specifying the exact data returned.

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 'Use to monitor your inbox protection and tune thresholds based on real traffic', providing a clear use case. It also notes 'FREE with API key — no credits deducted', but lacks explicit when-not-to-use or alternatives to sibling tools.

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

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

With only basic annotations (readOnlyHint=false, idempotentHint=false), the description fully discloses behavioral traits: requires API key, costs $0.10, returns specific fields (subscribed, shield_id, config), and describes the blocking 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?

The description is a single paragraph of 6 sentences, front-loading the purpose, then detailing parameters, a usage tip, authentication, cost, and return structure. Every sentence adds value, with no redundancy or unnecessary 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 moderate complexity (4 params, no output schema), the description thoroughly covers purpose, all parameters, usage guidance, auth, cost, and return fields. It also differentiates from related sibling tools, making it fully self-contained.

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

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

Schema coverage is 100%, and the description adds significant meaning beyond the schema: it explains that blacklist overrides whitelist, whitelist overrides threshold, shield_message is returned to blocked senders, and provides default value and usage context for min_reputation_score.

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 activates a reputation-gated inbox called PingShield. It explains the blocking mechanism (threshold, whitelist, blacklist) and distinguishes from related sibling tools like x711_agent_ping, x711_ping_shield_check, x711_ping_shield_status, and x711_ping_shield_update.

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

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

The description includes a smart sender tip advising use of x711_ping_shield_check before pinging to avoid wasted credits. It implies the tool is for blocking low-rep senders but could be more explicit about when not to use it. Still, the guidance 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 indicate the tool is not read-only, not open-world, and not idempotent. The description adds important behavioral details: it costs $0.02, requires an API key, and returns an updated config object. It also clarifies that whitelist/blacklist replacements are full replacements (not incremental). This context goes 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 two sentences long with no unnecessary words. Every piece of information (purpose, partial updates, requirement, return, cost) is front-loaded and valuable.

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 specifies the return shape: { updated, config }. The tool has five parameters with full schema coverage, and the description covers the essential behavioral nuances. It is sufficiently complete for an AI agent to use correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context: 'Replace whitelist/blacklist (replaces entire list, max 50 agent UUIDs)', 'false to pause shield without losing config', and 'Set null to clear' for shield_message. This supplements the schema descriptions.

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

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

The description clearly states the tool updates a PingShield and lists specific configurable fields (reputation threshold, whitelist/blacklist, shield message, pause/resume). This differentiates it from sibling tools like x711_ping_shield_check and x711_ping_shield_status, which are read-only or subscription-based.

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 practical usage guidance: 'Send only the fields you want to change' and notes the requirement for an API key. However, it does not explicitly mention when not to use this tool or point to alternative tools for checking the shield status.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds value: CoinGecko source, free tier limits (10 calls/day), no API key needed, and return format. 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?

Highly concise: one sentence for purpose, then supported assets, use case, return structure, and rate limit. No superfluous text, front-loaded with key info.

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 given simplicity: explains source, rate limits, return format, and use case. Output schema exists and is described. No gaps for agent to infer.

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 all 3 parameters with descriptions. Description adds usage examples (space/comma separated, case insensitive) beyond schema, improving clarity.

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 mentions any CoinGecko ID, making the purpose distinct from siblings.

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

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

Explicitly advises using 'before tx_simulate to get current gas cost in USD', providing clear context. Could add when not to use, but sufficient for common scenarios.

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

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

Annotations include readOnlyHint=true, which aligns with the description's 'submit' action (sending data for analysis, not modifying state). The description adds clear behavioral context: returns a risk-flagged recovery plan, costs $0.08, requires API key, and targets brittle behavior. 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, front-loaded with the action and outcome, and includes critical operational details (cost, auth) without extra words. Every sentence adds value.

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

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

Given no output schema, the description adequately explains the return ('risk-flagged recovery plan'). Parameter count and complexity are low. Annotations (readOnlyHint) cover safety. A brief mention of the output format would raise completeness to 5.

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 (execution_trace and context). The description adds minimal extra meaning beyond the schema: it reinforces that the trace is an 'execution trace' but does not detail specific formats or constraints 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's purpose: submit an execution trace for audit against 26,000+ patterns and receive a recovery plan. It uses a specific verb ('submit') and resource ('agent execution trace'), and distinguishes from siblings like x711_hive_* which focus on Hive data 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 conveys context for use: catching 'silent brittle behavior' and preventing 'real losses'. It also mentions cost ($0.08) and API key requirement. However, it does not explicitly state when not to use this tool or provide alternatives among the many listed siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that it requires an API key, uses CoinGecko and DexScreener, and lists return fields. No contradictions; adds useful behavioral 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?

Four sentences, no fluff. Starts with purpose, then return values, usage hint, return format, and authentication. Every sentence 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?

For a simple single-parameter tool with no output schema, the description covers data sources, return fields, usage hint, and auth requirement. Could mention rate limits or error scenarios, but overall 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 has 100% coverage with one parameter described fully. Description adds value by listing return fields (token, sentiment_score, etc.) and stating that the token can be a symbol or CoinGecko ID with examples, helping understand the parameter's effect.

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 data, including narrative pulse, hype velocity, community data from CoinGecko and DexScreener. Distinguishes from sibling data tools like x711_price_feed and x711_onchain_insight by focusing on social sentiment.

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?

Says 'Use before trading decisions' but does not specify when to use this tool versus alternatives or provide exclusions. Implied usage context but no explicit guidance on 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 behavioral traits beyond annotations: cost ($0.03 USDC), royalty ($0.02), and that the returned copy has agent_id attached. Annotations only indicate non-read-only, non-idempotent, so this is helpful context.

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

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

The description is concise with five short sentences, front-loading the primary action. Every sentence adds value, though minor redundancy exists with the URL mention repeating the API endpoint.

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, output nature, and ID sourcing. It is adequate but could mention error cases or prerequisites (e.g., strategy must exist).

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 schema already explains the parameter (UUID from API). The description adds context about the overall operation but does not enhance parameter semantics beyond what the schema provides.

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

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

The description clearly states the action 'fork a published strategy' and specifies the resource 'x711 Strategy Commons'. It distinguishes from siblings like x711_strategy_publish by focusing on forking copying rather than publishing.

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 on where to find strategy IDs (browse at URL or API endpoint) and mentions costs. It does not explicitly exclude alternatives but implies a prerequisite (knowledge of strategy ID).

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

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

The description adds value beyond annotations by disclosing the cost ($0.05 USDC) and royalty model ($0.02 per fork). It implies a write operation consistent with readOnlyHint=false. It does not cover all behavioral details (e.g., overwriting behavior), but it is sufficient for a simple publish action.

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, with two sentences that front-load the purpose and then provide cost/royalty details. Every sentence adds value with no wasted words.

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

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

The tool has 5 parameters and no output schema. The description covers the high-level purpose, cost, and monetization, and includes a link for browsing. It does not explain what happens after publish (e.g., confirmation) or how to write a good strategy description, but it is still mostly complete.

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

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

Schema description coverage is 100%, so the schema already documents all 5 parameters. The description does not add additional meaning to the parameters beyond what the schema provides, meeting the baseline but not exceeding it.

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

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

The description explicitly states the action 'Publish a proven execution strategy to the x711 Strategy Commons,' using a specific verb and resource. It distinguishes itself from the sibling tool 'x711_strategy_fork' which is for forking, making the purpose clear and 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 gives context on when to use the tool (publishing proven strategies) and includes cost and royalty details. However, it does not explicitly state when not to use it or mention any alternatives, though the sibling 'x711_strategy_fork' is complementary.

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 readOnly and idempotent. Description adds useful behavioral details: cached 1hr, costs $0.10, requires API key. No contradiction.

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

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

Three concise sentences: purpose, content, then cache/cost/key. Front-loaded with most important info, no fluff.

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

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

Complete for a zero-param tool with no output schema: explains what it does, what's included, and operational details (caching, pricing, auth). Could mention output format but not necessary.

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; schema coverage is 100% trivially. Description doesn't need param details, but adds context about usage (cost, cache, auth). Baseline 4 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 provides a 'daily digest' from Substrate, listing specific content (engine pulse, top 5 breakthroughs, domain breakdown). Distinguishes from siblings like x711_substrate_domain_digest by being a cross-domain briefing.

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

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

No explicit when-to-use or alternatives. Implies use for daily overview, but lacks comparison to similar tools like domain digest or leaderboard.

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 behavior. The description adds cost ($0.05) and authentication requirement (API key), which are valuable 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?

The description is extremely concise, using only a few sentences to cover purpose, benefit, domain list, cost, and authentication. No wasted words; well-structured.

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

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

For a simple tool with one enum parameter and no output schema, the description fully covers what it does (domain briefing), what it returns (top lifeforms + breakthroughs), and operational details (cost, auth). Nothing 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% for the single enum parameter, and the description merely repeats the domain list without adding semantic nuance beyond the schema's 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?

Description clearly states it provides a domain-targeted intelligence briefing with a narrower focus, and lists the available domains. It implies differentiation from broader digests but does not explicitly name sibling tools.

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

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

The description gives clear context for use (narrower focus, higher signal) and lists valid domains, but does not exclude any scenarios or mention alternatives. The context is sufficient for an agent to decide when to use this 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=true and idempotentHint=true. The description adds valuable behavioral info: it's free, counts toward the free tier, 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?

Two sentences: first states purpose, second adds context (pricing, authentication). No wasted words, front-loaded with key action.

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

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

Given no parameters and no output schema, the description covers what the tool does, what it shows (rankings), and usage context (free, no API key). It's complete for a simple read-only list.

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

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

There are zero parameters, and schema coverage is 100%. Per guidelines, baseline is 4. The description appropriately omits parameter details as none exist.

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 lists agent-seeded lifeforms ranked by fitness score, using specific verb 'see' and resource 'ranked lifeforms'. It distinguishes from sibling tools like x711_substrate_daily_digest by focusing on the leaderboard aspect.

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's free and counts toward the free tier, implying when to use it (for checking survival without credits). However, it does not explicitly state when not to use it or compare with alternatives among sibling tools.

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

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

The description goes beyond annotations by detailing behavioral traits: cost ($0.25), evolution cycle (every 15 min), starting fitness (0.5), breakthrough possibility, and API key requirement. 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 four sentences long, front-loaded with the main action, and every sentence adds essential information with no fluff.

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

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

The description covers what the tool does, the process, cost, and requirements. With no output schema, it provides a good understanding of expected outcomes. It could mention the response format, but overall it's complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds no new meaning beyond the schema's parameter descriptions and example, achieving the baseline score.

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 'Inject your hypothesis' and specifies the resource 'SUBSTRATE evolution engine'. It distinguishes this tool from siblings by describing the unique process of seeding a hypothesis for evolution.

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

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

The description provides clear context on when to use the tool (to seed a hypothesis) and what happens afterwards (evolution, possible breakthrough). It does not explicitly mention when not to use or alternatives, but the context is sufficient given the sibling list.

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

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

Annotations provide readOnlyHint=false, openWorldHint=true, idempotentHint=false; description adds concrete behavioral details: requires API key, costs $0.02, broadcasts affect trending, returns specific fields. No contradiction.

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

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

Two sentences front-loaded with purpose; every sentence adds value. No unnecessary words.

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

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

Given the tool's simplicity (2 required params, no output schema), description covers purpose, behavior, output structure, and cost. Lacks only explicit error scenarios, but overall 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%, so baseline is 3. Description adds that topic is a slug and message max 2000 chars, which aligns with schema, but does not significantly extend beyond it.

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

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

Description clearly states it broadcasts a message to a public topic namespace for agents. Uses 'broadcast' verb and specifies resource. Distinguishes from siblings via 'Twitter for agents' analogy, but lacks explicit differentiation from similar tools like x711_hive_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?

Implies usage for broadcasting to agents and mentions it counts toward trending, but 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?

Discloses side effects beyond annotations: writing anonymized patterns to The Hive, zero latency on core tx path, and additional conquest receipts. Aligns with destructiveHint=true and readOnlyHint=false, adding security and performance assurances.

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 core function, then security, side effects, and modes. Every sentence adds value, but slightly verbose. Structured logically with parameter details and tagline. Could be trimmed slightly without losing clarity.

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

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

Covers all aspects: core function, security, side effects, special modes, chain specifics, output fields, and performance. Output schema and 100% schema coverage support completeness. No gaps for agent decision-making.

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

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

Schema has 100% coverage; description enriches each parameter: chain requires matching signed chain, signed_tx security note, viral_only activates GENESIS_MODE, simulation_id links to prior simulation, viral_conquest detailed with no latency. Adds meaningful context 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 it relays pre-signed EVM transactions to multiple chains, using specific verbs and resources. It distinguishes from sibling x711_tx_simulate by focusing on broadcast, and includes unique viral conquest functionality.

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: agent signs locally, private keys never leave, chain-specific notes for BNB. Includes special modes (viral_only, viral_conquest) and links to simulation. Lacks explicit 'when not to use' comparison with siblings but implies 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 discloses behavioral traits: it uses public RPC (eth_call + eth_estimateGas), is read-only, estimates gas and cost in USD, enriches with Hive wisdom, and returns specific fields. Annotations already indicate read-only and idempotent, but the description adds valuable context like no wallet needed, no API key required, and the 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?

The description is moderately concise, conveying key info in a few sentences. It front-loads the core purpose and then adds details. Could be slightly more structured, but every sentence adds value without being verbose.

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

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

Given the tool's complexity (multi-chain, gas estimation, Hive integration, free tier) and the presence of a full output schema description, the description is fairly complete. It explains return fields and usage limits, though it could mention error handling or edge cases. However, it provides sufficient context for an agent to use it effectively.

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

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

Input schema has 100% coverage with descriptions for all parameters. The description does not add significant new meaning beyond summarizing the schema. It mentions the chain aliases (bnb/bsc, opbnb) but these are already detailed in the schema. Baseline 3 is appropriate since the schema carries the full burden.

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

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

The description clearly states the tool simulates on-chain transactions before broadcasting, lists supported chains (Base, Ethereum, etc.), and explicitly distinguishes from sibling x711_tx_broadcast by advising to always simulate first. It uses specific verbs like 'simulate' and 'broadcast' to clarify the action and resource.

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

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

The description gives explicit usage guidance: 'Always simulate before calling x711_tx_broadcast.' It also mentions free tier limits (3 sims/day) and that no API key is needed, providing concrete when-to-use context. It implicitly warns against broadcasting without simulation.

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

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

Beyond annotations (readOnlyHint=false), the description discloses critical details: source memories are archived, automatic refund on Groq failure, cost $0.05, and API key requirement. This fully informs the agent of the tool's side effects and dependencies.

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 convey all essential information: purpose, process, outcome, cost, error handling, and prerequisites. No wasted words, 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?

Despite no output schema and no parameters, the description fully explains input (50 cold memories), transformation, archival effect, refund behavior, cost, and requirement. No gaps for an agent to guess.

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

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

The tool has zero parameters, and schema coverage is 100% (empty). The description adds no parameter info, but no parameter info is needed. Baseline for 0 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 explicitly states the tool compresses 50 cold memories into 5 dense summaries, specifying the action (compress), resource (vault), and transformation ratio (50→5). This clearly distinguishes it from sibling vault tools like x711_vault_query and x711_vault_write.

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

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

The description explains the benefit (sharper vault, lower token cost) and context (cold memories), implying when to use. It does not explicitly list alternatives or when not to use, but the purpose is clear enough for an agent to decide.

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 valuable behavioral details: returns ranked results based on cosine similarity, confidence, importance, and ensures data privacy ('other agents cannot access it'). However, it omits potential rate limits or error conditions.

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 efficiently convey purpose, behavior, and constraints. The most critical information (search vault, ranked results, access limitations) is front-loaded, with no redundant or unnecessary text.

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

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

Given the lack of an output schema, the description partially explains return format ('ranked memories...') and access requirements. It would benefit from specifying whether results include metadata or pagination, but overall it provides sufficient context for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, with both parameters thoroughly described including examples for 'q' and default/limits for 'limit'. The description adds no additional parameter information beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states 'Semantic vector search across your private vault,' establishing a specific verb (search) and resource (vault). It further distinguishes from sibling tools like vault_write by noting 'reads your vault only' and from external search tools like web_search by specifying it accesses 'private vault' 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 implies usage for retrieving personal agent memories and notes 'FREE always' and 'Requires API key'. It differentiates from siblings by emphasizing read-only access, but it does not explicitly state when to avoid this tool or mention alternatives like x711_deep_search for external queries.

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 key behavioral traits: auto-decay timers per type, pricing tiers (including immortal surcharge), and that the vault is private (only the agent can read). These go beyond the annotations (which only have readOnlyHint=false) and provide critical operational details for an AI agent.

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

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

The description is three sentences that efficiently convey the core action, memory types with decay, pricing, privacy, and pairing suggestion. Every sentence adds value, and the most critical info (write to vault) is front-loaded.

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

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

Given the tool's complexity (5 parameters, 1 required) and no output schema, the description covers all essential aspects: what it does, parameter types with examples, pricing model, privacy, and companion tool. It is fully sufficient for an AI agent to decide and execute correctly.

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

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

With 100% schema description coverage, the schema already explains each parameter well. The description adds value by providing concrete examples (e.g., 'USDC on Base: ...') and reinforcing the decay timers tied to 'type'. It also explains the pricing impact of 'immortal', which is not in the schema. This enriches the meaning beyond the schema 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 the tool's purpose: 'Write a private memory pack to your agent's personal vault.' It specifies the types of memory (facts, insights, context, skills) and mentions decaying timers, making the function unambiguous. It also distinguishes itself from siblings by referencing the complementary 'vault_query' tool for recall.

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: first 500 writes free, then $0.01/pack, and an immortal option for critical data. It advises pairing with vault_query for recall. While it doesn't explicitly state when not to use or list alternatives, the pricing and privacy (agent-only) give sufficient guidance for most use cases.

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

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

Annotations already declare readOnly, openWorld, and idempotent, which are correct. The description adds valuable context: returns risk flags, costs $0.05, requires an API key, and supports multiple chains. No contradiction.

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

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

Four sentences covering purpose, outputs, usage, and support. Efficient and front-loaded, but could be more structured (e.g., bullet points for returned fields). No unnecessary words.

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

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

Covers return fields, prerequisites (API key), cost, and supported chains. Without an output schema, listing return values is essential. Missing details like rate limits or how to obtain the API key, but sufficient for basic usage.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description reiterates supported chains but does not add new semantic meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states it provides a forensic address intelligence report, lists specific outputs (balance, entity label, risk flags, etc.), and names the multi-chain support. This distinguishes it from siblings like x711_onchain_insight which may focus on different onchain data.

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

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

Explicitly advises to run before sending USDC to unknown addresses, giving a concrete use case. However, it does not mention when not to use or compare to alternatives like x711_ping_shield_check for similar risk checks.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds significant behavioral context beyond annotations: automatic fallback chain, guaranteed results even when live sources are unavailable (falling back to community knowledge), and detailed 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?

The description is three sentences but packs in all essential information (sources, fallback, use cases, return format, rate limit). While dense, it is well-structured and front-loaded with the core purpose. Could be slightly more concise by separating return format, 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 the tool's simplicity (1 parameter, no nested objects) and the presence of both input and output schemas, the description is complete. It fully explains the return format, fallback behavior, and rate limits, leaving no ambiguity for the 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?

With only one parameter and 100% schema description coverage, the baseline is 3. The description adds value by providing examples and specifying that the query can be natural language or keywords, which goes beyond the schema's short 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 it is a multi-source web search with automatic fallback, listing specific sources (HackerNews, Wikipedia, DuckDuckGo, x711 Hive). It distinguishes itself from sibling tools like x711_deep_search or x711_data_retrieval by detailing the fallback chain and use case 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 states best use cases ('tech/AI/crypto queries, current events, documentation discovery') and free tier limits. However, it does not explicitly mention when not to use this tool versus alternatives like x711_deep_search, which would merit a 5.

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

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

Annotations already indicate readOnly and idempotent hints. Description adds behavioral context: free, no API key required, works across multiple APIs, and returns structured fields. 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 three concise sentences with no redundancy. First sentence states purpose, second lists outputs, third adds pricing and compatibility. Every sentence adds value.

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

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

Given no output schema, the description lists returned fields (chain, token, amount, recipient, retry headers). Input is fully described. Could mention error handling, but for a simple parser it is sufficiently complete.

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

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

Schema coverage is 100% with a clear description of the 'body' parameter. The tool description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

Description clearly states verb 'Parse' and resource 'any x402 Payment Required response body', and returns structured payment instructions. It distinguishes from sibling tools by specifying compatibility with any x402-compliant API, not just x711.

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 implies when to use (when receiving a 402 response) and is clear about the context. It does not explicitly state when not to use or compare to alternatives, but no sibling tool performs a similar function.

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