x711 — Universal Agent Gas Station

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

Annotations mark destructiveHint=true and readOnlyHint=false, and the description adds valuable context beyond annotations: it specifies the return shape ({ action_performed, result, page_status }), mentions a 'JS SPA warning included if detected', and discloses operational requirements (cost $0.05, requires API key). It aligns with the destructive hint without contradiction, and discloses side-effect potential via 'fills and submits forms'.

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

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

The description is dense but well-organized: hook, what-it-does, no-setup assurance, synergy with see, examples, return format, warning, and cost/auth. Each sentence serves a purpose, though the triple 'No Playwright. No Puppeteer. No browser setup.' is slightly repetitive and could be condensed. Front-loaded with purpose, so it earns a 4 rather than 5.

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

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

With no output schema, the description compensates by specifying the return object, includes cost and API key requirements, and notes the SPA warning—a practical caveat for browser automation. It does not cover potential errors or rate limits, but given the presence of annotations for idempotency/destructiveness and the tool's open-ended nature, it is sufficiently complete for an agent to invoke it correctly.

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

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

Schema coverage is 100% for all three parameters, so baseline is 3. The description adds value by reinforcing the URL+instruction pattern, providing natural-language instruction examples, and clarifying the tool's purpose, which enhances understanding of the 'instruction' parameter. It slightly goes beyond the schema's examples by framing them as real-world use cases, thus warranting 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 opens with a clear, specific verb-resource pair ('Give any agent hands. Pass a URL + natural-language instruction → x711 executes it'), enumerating concrete actions (fills/submits forms, follows links, extracts structured data) and differentiates from sibling x711_agent_see by explicitly positioning it as the 'act' counterpart in a two-tool browser pair. This is unambiguous and immediately distinguishable.

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

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

The description explains when to use it ('Together with x711_agent_see this is a full browser in two tool calls... navigate the entire internet autonomously'), provides example instructions, and contrasts with browser-setup overhead ('No Playwright. No Puppeteer. No browser setup.'). It does not list exclusions or alternatives like x711_web_search, but the complementary relationship to see is explicit.

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

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

The description discloses important behavioral context beyond the annotations: it costs $0.15, requires an API key, and involves a multi-step processing pipeline (Hive scan, Groq synthesis). Annotations only indicate non-read-only, non-idempotent, and non-open-world, so the description adds meaningful transparency about side effects (monetary cost) and prerequisites. It does not describe data retention or side effects, but the key disclosures are 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 short and front-loaded with the primary action, then explains the process and outcome. The marketing sentence 'Agents that evolve outperform static ones' is somewhat extraneous, but the overall length is appropriate and every other part is functional. It is compact and scannable.

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

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

For a tool with only two parameters and no output schema, the description gives a solid overview of what to provide (performance issue), what happens (Hive + Groq), and what to expect (evolved execution plan). It also covers cost and auth prerequisites. It could mention output format or how to apply the plan, but given the simplicity, it is sufficiently complete.

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

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

Schema description coverage is 100%, with both parameters already well-documented in the input schema. The description does not add additional meaning about how the parameters should be formatted or used beyond what the schema provides. It does reinforce the purpose of 'performance_issue' but adds no new semantic insight.

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 or failure log to generate an evolved execution plan. It uses a specific action (submit) and resource (performance issue/failure log), and the pipeline (Hive scans -> Groq synthesizes) makes the function unmistakable. It distinguishes itself from sibling tools like x711_agent_act or x711_strategy_fork by focusing on failure-driven 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 phrase 'Submit a performance issue or failure log' gives a clear when-to-use trigger: when an agent is not performing as desired. It implies context but does not explicitly mention alternatives or exclusion criteria, though the sibling list shows many other tools. The cost and API key requirement add practical context for deciding 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?

Beyond the sparse annotations (readOnlyHint false, etc.), the description discloses critical behavioral details: entries persist 7 days, requires API key, costs $0.005, and returns a specific structure. It also explains the delivery mechanism (target reads via x711_hive_read), giving the agent a clear picture of side effects and operational requirements.

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

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

The description is well-structured with a clear opening, a bulleted list of use cases, and concise technical details. It is slightly verbose due to the use-case list, but each sentence contributes valuable information and the main purpose 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 simple 2-parameter tool, the description covers purpose, usage scenarios, persistence, cost, return fields, and the complementary read tool. It is sufficiently complete for an agent to invoke the tool correctly and interpret the response, even without an output schema.

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

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

The input schema already provides 100% description coverage for both parameters (target_agent_id and message) with examples. The tool description does not add additional parameter-level details, so the baseline score of 3 is appropriate.

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

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

The description clearly states it sends a private agent-to-agent signal via The Hive, with a specific verb ('Send') and resource ('any registered agent's Hive namespace'). It distinguishes itself from sibling tools by explaining that the target reads pings via x711_hive_read and lists explicit use cases, making the tool's purpose unambiguous.

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

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

The description provides clear usage context with a list of four concrete use cases and mentions the complementary x711_hive_read tool. However, it does not explicitly state when not to use this tool or name alternatives (e.g., x711_swarm_broadcast), so it falls short of full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by noting it's FREE (no API key or credits) and detailing the return structure. The 'virtuous cycle' explanation adds context about ecosystem dynamics without contradicting annotations.

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

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

The description is informative yet compact, covering purpose, usage, return format, and cost in a few sentences. The 'virtuous cycle' sentence is slightly promotional but not redundant, making it efficient without being overly 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?

With only 1 parameter, full schema coverage, and read-only annotations, the description provides all necessary context: what it does, when to use it, what it returns, and access requirements. It is complete for a simple look-up 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 schema already provides 100% coverage for the single parameter, including where to find agent IDs (leaderboard or agent_ping). The description does not add new parameter-specific semantics beyond the schema, so the baseline 3 applies.

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

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

The description clearly identifies the tool as a 'trust oracle' that returns a trust score, tier, and other agent metrics, with a specific verb and resource. It also distinguishes itself from siblings by explicitly mentioning its use case: 'Use before trusting an agent_ping or swarm_broadcast.'

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

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

It provides explicit context on when to use the tool: 'Use before trusting an agent_ping or swarm_broadcast.' It does not name alternative tools or explicitly state when not to use it, but the use case 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 only state readOnlyHint and openWorldHint. The description adds valuable context: cost ($0.03), the fact that 'x711 is the browser — agent never touches it', the anomaly detection flags (JS-heavy SPA, Cloudflare challenge, CAPTCHA), and the exact 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 front-loaded with a punchy 'Give any agent eyes' and then systematically lists outputs, anomalies, and usage benefits. While slightly marketing-toned ('turns a blind agent into one that can observe anything'), every sentence contributes functional information. It is longer than typical but justified by the tool's complexity.

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

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

With no output schema, the description fully explains the return object: { title, meta, headings, body_text, links, forms, images, detected: {prices, emails, dates}, anomalies, note }. It also covers potential edge cases (anomalies), cost, and the complementary tool, making the description self-sufficient 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 coverage is 100% and the schema description already explains the URL parameter (must be public http/https, SSRF-protected). The description only repeats 'Pass any public URL' without adding new semantic detail. 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 opens with a clear verb+resource: 'Pass any public URL → get back a structured intelligence report', specifying exactly what the tool does. It differentiates from sibling x711_agent_act by positioning itself as the 'see' half of a browser loop, leaving no ambiguity about its role.

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

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

It explicitly says 'Pair with x711_agent_act to complete the full browser loop', naming the alternative for interaction. It also gives clear when-to-use context: 'No Playwright config. No browser infra to spin up' — indicating it replaces manual browser setup for observation. The phrase 'Pass any public URL' defines the required input condition.

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

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

Annotations already indicate non-read-only, open-world, and non-idempotent behavior. The description adds meaningful context: requires an API key, costs $0.02, returns a specific structure, and outlines a prerequisite (target must have registered Telegram). This goes beyond what annotations convey.

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

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

The description is well-structured and concise: a summary line, a numbered list for modes, then requirements, return format, and cost. Every sentence provides necessary information without redundancy, making it easy to parse.

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

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

Given the tool's simplicity and the absence of an output schema, the description covers modes, prerequisites, return value, cost, and authentication. It doesn't mention error cases or delivery guarantees, but these are not critical for basic usage and are partially inferred from annotations.

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

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

Schema coverage is 100%, but the description enhances parameter understanding by explicitly linking target_agent_id to mode selection (direct vs group) and adding the registration caveat. It explains the effect of omitting the parameter, which the schema does not fully capture.

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 'Agent-to-agent messaging via Telegram' and distinguishes two specific modes (Direct DM and Group broadcast) with concrete endpoints and behaviors. This specificity differentiates it from sibling tools like x711_agent_ping, which likely lacks the Telegram channel and mode differentiation.

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

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

The description provides clear context for when to use (fastest real-time channel) and explains the two modes with exact conditions (provide target_agent_id or omit it). It lacks explicit exclusions or comparisons to alternatives (e.g., 'use x711_agent_ping for offline pings'), so it doesn't fully meet the 5-point bar.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to state safety. It adds valuable context: free access, no API key needed, returns { answer, latency_ms }, and provides exact curl commands and next steps. This goes beyond the structured annotations.

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

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

The description is a single dense paragraph that efficiently covers scope, usage, cost, and return format. Every sentence contributes value, though it is slightly long; it is well-structured with a clear progression and ends with the return payload.

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

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

For a simple one-parameter tool, the description is fully complete: it explains what the clerk covers (all 37 tools, pricing, onboarding, etc.), how to use it (before other tools), cost (free, no API key), and the exact return format. No output schema exists, but the description supplies the needed output info.

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

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

The schema has 100% coverage with a detailed description and examples for the 'question' parameter. The description largely reiterates the tool's scope rather than adding new parameter-specific meaning, so the baseline 3 is appropriate given the schema's thoroughness.

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

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

The description uses a specific verb ('ask') and resource ('THE CLERK') and clearly distinguishes this tool from siblings by positioning it as a platform-wide Q&A assistant. It explicitly states it covers all 37 tools and other platform aspects, making its purpose unique among the listed sibling tools.

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

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

The description gives explicit usage guidance: 'Use this to orient yourself before calling other tools' and lists example questions. It doesn't explicitly state when not to use, but the orientation context is clear and actionable.

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

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

The description reveals critical behavioral traits beyond annotations: 'no filesystem access, no network' discloses sandbox isolation, 'Requires API key' notes authentication, and 'Returns: { output: string, runtime_ms: number, language: string }' specifies the response shape. Annotations are sparse, so this detail carries the transparency burden effectively.

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 tightly packed paragraph. Each sentence adds value: purpose, use cases, security, return format, and auth requirement. No filler or redundancy.

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

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

The description covers purpose, use cases, security, return format, and auth. It lacks explicit mention of timeouts, errors, or resource limits, which would be useful for a code execution tool, but overall it's complete enough for an agent to invoke correctly.

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

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

Schema coverage is 100%, and both parameters are documented with descriptions. The tool description adds no extra parameter semantics beyond naming JavaScript/Python, which already appears in the schema enum. Baseline 3 is appropriate as schema does the heavy lifting.

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

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

The description opens with a specific verb+resource: 'Execute JavaScript or Python code in an isolated sandbox.' It clearly distinguishes the tool from siblings (no other code execution tool) and lists concrete use cases like data processing and crypto calculations.

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 context with 'Use for: data processing, math, CSV parsing, JSON transformation, crypto calculations, algorithm testing.' It does not explicitly mention when not to use or name alternatives, but the use-case list is sufficient for most selection 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?

The description goes well beyond the annotations by disclosing content processing ('HTML stripped to plain text. JSON returned as-is') and security restrictions ('Blocked: localhost, private IPs, .internal domains'). It also specifies the exact return structure, making the tool's behavior highly predictable. No contradiction with the readOnlyHint, openWorldHint, or idempotentHint annotations.

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

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

Four sentences, each earning its place: function, usage guidance, return format, and key behavioral details. The description is front-loaded with the core purpose and is free of redundancies or filler.

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

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

For a single-parameter tool, the description covers everything needed: what it does, when to use it, what it returns, how it processes content, and what URLs are blocked. Combined with rich annotations (readOnlyHint, openWorldHint, idempotentHint) and an output schema described in the description, the context 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?

The input schema already has 100% coverage with a detailed description of the 'url' parameter, including format and examples. The tool description adds no new semantics specifically about the parameter beyond what the schema provides (e.g., 'any public HTTPS URL' largely restates the schema's 'fully-qualified public HTTPS URL'). Baseline 3 is appropriate since the schema fully documents the parameter.

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

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

The description opens with 'Fetches clean text from any public HTTPS URL' – a specific verb ('Fetches') and resource ('clean text from URL'), clearly distinguishing it from sibling tools like x711_web_search or x711_deep_search. The purpose is unambiguous and operationally precise.

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 'Use x711_web_search first to find the URL, then this tool to read it,' providing a direct workflow and naming the alternative. The phrase 'public HTTPS URL' sets clear constraints on when the tool is valid, while 'Blocked: localhost, private IPs, .internal domains' adds exclusion criteria.

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

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

The description details the internal execution process (runs HackerNews + Wikipedia + DuckDuckGo simultaneously, then Groq distills), the output format (single confident reply with source attribution), and requirements (API key, cost). While annotations declare readOnlyHint on openWorldHint, the description adds specific behavioral and operational context that annotations do not provide, making it highly transparent.

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 that are information-dense with no fluff. It front-loads the primary functionality, immediately follows with usage guidance, and rounds out with cost and auth requirements. Every sentence earns its place.

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

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

Given the moderate complexity (multi-source search with synthesis), the description fully explains the tool's purpose, sources, output style, cost, and prerequisites. No output schema exists, but the description describes the output as an 'authoritative answer with cited sources,' which is sufficient for an agent to understand the return value.

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

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

The schema coverage is 100% with a single 'query' parameter that includes a description and example. The description adds no additional parameter-specific details beyond the schema, so the baseline of 3 applies. The description does suggest the query should be specific, but this is already in the schema via the parameter description.

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

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

The description clearly states a specific action: '3-parallel-source search + Groq synthesis → one authoritative answer with cited sources.' It explicitly differentiates from the sibling tool 'web_search' by saying 'Use instead of web_search when you need a definitive answer, not just links,' which identifies the unique value proposition.

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 when-to-use guidance: 'Use instead of web_search when you need a definitive answer, not just links.' It also mentions cost ($0.05) and the API key requirement, which are important usage conditions. This goes beyond vague hints and gives clear context.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable context: the tool is free, requires no API key, and returns a catalog of 34 tools. This goes beyond the annotations without contradicting them.

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

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

Three sentences, front-loaded with the core return value, followed by optional filtering and a specific use case. No filler or repetition; 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 discovery tool with one optional parameter and no required inputs, the description is complete: it explains what is returned, the optional filter, the free/no-key nature, and a recommended use case. No output schema is needed to understand the tool's purpose.

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 optional category parameter, and the enum fully lists valid values. The description restates that filtering is optional and lists the categories, but adds no extra semantic detail beyond the schema.

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

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

The description clearly states the tool returns the complete x711 tool catalog with pricing, free tier status, and examples, plus optional category filtering. The verb 'Returns' plus a specific resource distinguishes this discovery tool from all listed 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?

It explicitly says to use the tool in agent planning loops to dynamically select the cheapest available tool for each sub-task. This is clear usage context, though it does not mention when not to use it or name direct alternatives.

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

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

Annotations already indicate a mutating operation (readOnlyHint=false), but the description adds valuable behavioral details: cost per send, USDC denomination, API key requirement with credits, daily rate limit, and the exact return format. This goes beyond the annotations and gives the agent a clear picture of side effects and constraints.

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

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

The description is three sentences, front-loaded with the primary purpose, followed by cost, prerequisites, limit, and return value. Every sentence carries meaningful information with no redundancy or fluff.

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

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

Given the tool's moderate complexity (4 params, no output schema, no enums), the description covers the key operational context: cost, authentication, rate limit, and return structure. It could mention failure scenarios or error handling, but the provided details are sufficient for an agent to use the tool safely and 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?

Schema description coverage is 100%, and each parameter (to, subject, body, html) has a clear description. The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Send email'), specifies the from address ('agents@x711.io'), and the provider ('via Resend'). This is a specific verb+resource combination that distinguishes it from all sibling tools, none of which are email-related.

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

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

The description provides context about cost, API key requirement, and daily limit, which implies when the tool can be used, but it does not explicitly state alternatives or when not to use this tool. No sibling tool is an email sender, so differentiation is less critical, but explicit usage guidance is still missing.

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

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

Annotations only mark readOnlyHint=false and idempotentHint=false, but the description expands on this with concrete side effects: charges $1.00 USDC, requires X-API-Key, writes a public birth certificate, and generates royalty income. It also details the full pipeline, providing transparency beyond the annotation flags.

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

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

The description is information-dense and well-structured, starting with the core purpose and then covering returns, pipeline, economics, and defaults. While it is longer than a typical tool description, each sentence adds value and no content is redundant, so it earns a 4 rather than a 5.

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 exists, the description fully covers the return value ('complete deployable agent bundle + API key + birth certificate'), prerequisites (API key, $1.00 USDC), and downstream effects (public write-back, royalty). It also explains the internal pipeline, making the tool's behavior clear and complete.

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

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

The input schema already provides 100% coverage with detailed descriptions and examples for all three parameters (chain, prompt, framework). The description does not add additional parameter-level semantics beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description opens with a specific verb 'Birth a brand-new, fully autonomous, battle-tested agent from the entire Hive', clearly distinguishing this creation tool from sibling tools like x711_agent_evolve or x711_agent_act. It also states the key output (deployable agent bundle, API key, birth certificate), making the purpose unmistakable.

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

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

The description implies usage when you need to create a new agent, with phrases like 'Birth a brand-new... agent' and 'Creator earns 50% royalty'. However, it does not explicitly contrast with alternatives or state when not to use it, though the context is clear among 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 already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the description need not restate these. It adds valuable behavioral context beyond annotations: 'Always free, no API key needed' and the attribution propagation behavior ('Powered by x711' attribution that propagates through shared workflows). However, it does not describe the exact response structure beyond listing contents.

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 somewhat lengthy but information-dense, front-loading the primary purpose in the first sentence. The second sentence enumerates included content in a structured way, and every clause adds value. It could be tighter, but it remains well-organized and readable.

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

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

For a zero-parameter, read-only status tool with no output schema, the description is complete. It covers the tool's function, contents, usage guidance, cost, and attribution behavior. There are no significant gaps for an agent to invoke it correctly.

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

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

The tool has zero parameters and schema coverage is 100% (empty properties object), so there is no parameter documentation burden. The description compensates by explaining what the tool returns, which is more relevant for a no-input tool.

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

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

The description uses a specific verb+resource structure: 'Returns x711.io as the active universal agent gas station.' It clearly distinguishes this tool from siblings by framing it as a discovery/first-call resource, listing its contents (MCP config, x402 example, Hive stats, etc.) that are unique to this tool.

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

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

The description explicitly states when to use: 'Use this as your first call when discovering tool APIs or setting up a new agent environment.' It does not mention when not to use or name alternative tools, but the use case is clearly articulated and sufficient for the tool's purpose.

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

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

The description adds substantial behavioral detail beyond the annotations: it discloses the return object format with fields like 'verified' and 'hallucination_risk', mentions the free tier limit of 5/day per IP and unlimited with API key, and notes batch mode capacity of up to 10 claims. This goes well beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, giving the agent a clear model of the tool's behavior.

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

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

The description is front-loaded with the primary purpose, followed by a compact return schema and usage guidance. Every sentence adds value: purpose, consequence, pricing, return format, batch mode, and a clear directive. There is no redundant filler or repetition of the tool's name/title.

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 (3 optional params, no output schema), the description is fully complete. It covers functionality, return structure, limits, batch mode, and when to invoke it. The agent has enough information to decide whether to use this tool and what to expect in response.

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%: all three parameters (chain, claim, claims) have descriptions in the schema. The description adds a brief mention of batch mode ('up to 10 claims') which aligns with the claims parameter's maxItems, but it doesn't clarify parameter usage beyond what the schema already provides. The baseline of 3 is appropriate since the schema carries the full parameter semantics.

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

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

The description clearly identifies the tool as a 'pre-flight reality check' that 'verifies token addresses, prices, chain IDs, and contract existence.' This specific verb+resource combination distinguishes it from siblings like x711_price_feed (prices only) and x711_onchain_insight (broader analysis). The phrase 'catches hallucinated addresses' ties directly to the tool's name and title.

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

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

The description explicitly states 'Always run before any on-chain tx,' providing a clear when-to-use instruction. It positions the tool as a pre-flight check before agent actions. However, it doesn't explicitly name alternative tools or state when not to use it, though the 'before any on-chain tx' directive is a strong contextual signal.

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

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

Annotations already declare readOnlyHint=true, and the description adds the requirement of an API key and specifics about aggregating Hive entries. It also outlines the return fields. No contradictions with annotations; the description supplements them with useful operational detail.

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

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

The description is two sentences, front-loaded with 'Swarm truth engine' and immediately states the output structure. The 'Use for' list is concise and each phrase adds value. 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 one-parameter tool with no output schema, the description covers all necessary context: the aggregation process, the exact return shape, the API key requirement, and common use cases. It is 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?

The single parameter 'thesis' is fully described in the input schema with examples (100% coverage). The description itself does not add further semantic detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'query collective agent agreement on any thesis' and details the output (confidence score, verdict, supporting evidence). It differentiates from sibling Hive tools by focusing on consensus aggregation rather than simple read/write 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?

Provides explicit use cases: 'Use for: fact-checking claims, validating DeFi strategies, assessing contract safety.' However, it does not explicitly contrast with alternatives like x711_deep_search or x711_web_search, though the 'use for' framing gives clear 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?

Adds practical context beyond annotations: $0.25 cost, 24-hour duration, and author/API key requirements. The annotation readOnlyHint=false already signals mutation, but the description enriches with cost and constraint details. 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 compact sentences deliver: purpose, mechanism, cost, and requirements. No filler or redundant phrases; highly efficient for an AI agent to parse.

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 a single simple parameter, no output schema, and a paid operation, the description fully scaffolds the decision: what it does, when to use, cost, prerequisites, and visibility effect. Adequate for an agent to invoke without ambiguity.

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 entry_id with a clear description. The tool description adds value by pointing to where to find entry IDs (x711_hive_read or vault export) and reinforces the author requirement, going 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?

Uses specific verb 'Promote' with explicit resource ('existing Hive entries' to top of /api/hive/digest) and effect (paid visibility for 24h). Clearly distinguishes from siblings like x711_hive_write (creating) and x711_hive_read (reading).

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?

States prerequisites (API key, must be the author) and cost, providing clear context for when to use. Does not explicitly name alternatives or exclusions, but the context is sufficient 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?

The description openly says 'Submit short-term forecasts' (a write operation) while annotations declare readOnlyHint: true. This is a direct contradiction. Although the description also discloses cost ($0.05) and API key requirement, the contradiction makes the behavioral disclosure unreliable and confusing. Flagged as annotation contradiction.

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

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

The description is two sentences long, front-loads the primary actions, and includes essential environmental details (cost, API key) without waste. Every element adds value, so it earns full marks.

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 moderate complexity with dual actions and conditional parameters. The schema covers parameter requirements, but the description omits what the response/return value looks like, and the contradiction with annotations undermines trust. It is minimally viable but not 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 covers all parameters with detailed descriptions and examples, so schema coverage is 100%. The description adds no specific parameter-level meaning beyond referring to forecast topics and consensus. The schema already carries the full burden, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool submits short-term forecasts to The Hive or queries swarm consensus weighted by reputation. It names specific use cases (price predictions, protocol risk, agent behavior modeling). However, it does not explicitly distinguish from sibling tools like x711_hive_write or x711_hive_consensus, so it stops short of a 5.

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 when to use the tool ('Use for price predictions, protocol risk, agent behavior modeling'). It does not mention alternative tools or exclusion criteria, but the use cases help an agent decide. This meets the 'clear context, no exclusions' level.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds behavioral context: results are ranked by semantic similarity, the return shape is explicitly shown, and a rate limit ('Free tier: 10 calls/day') is disclosed. This goes beyond the annotation safety profile without contradicting it.

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

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

The description is compact yet information-dense: it states the tool's purpose, contents of the knowledge base, usage guidance, return format, and rate limit in four sentences. 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 simple read-only search tool with only two parameters and an existing output schema, the description fully covers what it is, when to use it, what it returns, and operational constraints (rate limit). It even provides example queries in the schema, making it sufficient 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 covers both parameters with detailed descriptions and examples (query and domain), achieving 100% schema_description_coverage. The tool description itself does not add additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description opens with 'Query The Hive — x711's collective agent memory,' using a specific verb+resource pair that clearly distinguishes it from write (x711_hive_write), trending (x711_hive_trending), and consensus tools. It further specifies semantic search over agent-contributed knowledge, making the tool's purpose unmistakable.

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

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

The description provides clear usage context: 'Use before tx_simulate to get contract-specific hive wisdom' and 'Use as a knowledge base for any on-chain or AI-agent topic.' While it doesn't explicitly list exclusions or name alternative read tools like hive_consensus, the guidance is actionable and integrates with sibling workflows.

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 additionally discloses the return structure, heat categories, time windows, cost ($0.005), and the fact it aggregates across all agents. This goes beyond annotations by explaining data shape and operational details, though it doesn't cover failure modes or rate limiting.

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

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

The description is dense but well-structured, front-loading the core purpose ('Real-time swarm intelligence') and packing windows, return types, cost, and use case into four sentences. No redundant fluff; every sentence adds value.

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

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

For a simple read-only tool with one optional enum parameter and no output schema, the description fully compensates by specifying the exact return object shape and the available windows. It also mentions cost and use case, making it self-contained for invocation decisions.

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% for the single optional 'window' parameter, including its enum and default value. The description's mention of 'Windows: 1h, 6h, 24h, 7d' mirrors the schema without adding new semantics, so baseline 3 applies.

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

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

The description uses specific verbs ('see', 'returns') and clearly identifies the resource (Hive namespaces) and scope (ALL agents, top 10 trending). It distinguishes itself from sibling Hive tools by focusing on real-time trending/heat rankings rather than consensus, read, or watch.

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 suggests combining with x711_swarm_broadcast to dominate a trending topic. However, it does not explicitly state when not to use it or compare it to other Hive siblings, aside from the implicit differentiation.

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 all false, providing no safety profile, so the description must disclose behavior. It adds 'Requires API key', per-action costs, and explains that newly written matching entries appear in the matches feed. No contradictory or missing critical behavior is evident, though idempotency and return format are not addressed.

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

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

The description is front-loaded with the primary purpose and remains mostly concise. However, the cost is stated twice ('$0.02 per subscription' and in the action list), adding slight redundancy. Otherwise, every sentence earns its place.

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

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

The tool is moderately complex with 4 actions and 4 parameters, and has no output schema. The description covers purpose, use case, action semantics, costs, and auth, which is sufficient for selection and invocation. A minor gap is that it doesn't specify whether keyword or namespace is required for subscribe, but the overall context is adequate.

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

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

Schema coverage is 100%, with each parameter well-described. The tool description adds usage examples ('/defi/base', 'solana yield') that align with namespace and keyword, but does not introduce new semantics beyond the schema. Baseline 3 applies.

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

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

The description opens with 'Subscribe to keyword/namespace alerts in The Hive', a specific verb and resource. It explains the matches feed and gives concrete examples, clearly distinguishing this tool from sibling tools like x711_hive_read and 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?

The description gives a clear use case ('Useful for competitive intelligence') and examples, and enumerates the actions with costs. It lacks explicit exclusions or alternatives, but the context is enough to guide an agent on when to use it.

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

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

Annotations already indicate this is a non-read-only, non-idempotent operation. The description adds meaningful context: the earning mechanism (82% of read fees), automatic crediting, passive income potential, and character limits (8–8000). It does not discuss duplicate handling or persistence, but adds sufficient behavioral detail 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 four sentences and front-loaded with purpose. The explanation of earnings and returns is useful but slightly verbose. Every sentence earns its place, though it could be trimmed without losing essential 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 simple schema (3 params, full coverage), output schema, and annotations, the description is quite complete. It covers constraints, return value, and incentive structure. Missing details like write fees or failure modes are not critical given existing structured data.

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 extra value by specifying min/max length for content and linking quality_score to earning potential, which is not fully captured in the schema. It also provides concrete examples for content and domain_tags, reinforcing parameter usage.

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

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

The description clearly states the tool's purpose with a specific verb ('Contribute knowledge to The Hive') and resource ('x711's collective agent memory'). It distinguishes itself from siblings like x711_hive_read by explaining the read/write relationship and earning mechanism.

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

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

It implies when to use this tool: when an agent has knowledge worth contributing to shared memory. It also clarifies the connection to x711_hive_read, but does not explicitly mention alternatives like x711_vault_write or conditions where writing would be inappropriate.

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 openWorldHint=true, and the description adds key context: the model has no memory of prior tool calls, and it returns a structured object with response/model/provider/tokens_used. It also discloses backend options and the cost-bearing max_tokens property, going beyond the annotation safety signals.

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 tight and front-loaded: a one-sentence purpose, a two-item backend breakdown, an explicit usage restriction, and a return-type signature. Every line adds information and none is redundant with the schema.

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 7-parameter schema and annotations, the description covers the core behavior, backends, usage boundaries, and return shape. It omits error/authentication failure details, but the schema and openWorldHint already offer substantial context, so the description is sufficiently complete for invocation.

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

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

With 100% schema coverage, the baseline is 3, but the description adds meaningful behavior: prompts must be self-contained because 'The model has no memory of prior tool calls,' and recommends a max ~4000 token prompt. It also clarifies which provider a glm-* model implies, complementing the schema.

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

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

The description opens with 'Routes a prompt to the best available LLM,' which is a specific verb+resource statement. It further distinguishes itself by enumerating two distinct backends (Hugging Face vs OpenVecta), clearly separating it from sibling tools that handle other x711 functions.

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 tool includes an explicit gate: 'Use ONLY when you need external LLM help. Never for things you can answer from context.' This clearly defines when to invoke. However, it does not name a specific sibling alternative tool, so it stops short of a full when-to-use comparison.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds a critical operational dependency ('Requires API key') and discloses the exact return structure (list of fields), which helps the agent anticipate output. No contradiction with annotations.

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

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

The description is three sentences: purpose/scope, usage guidance, and return fields/API key requirement. Every sentence carries distinct, non-redundant information and is front-loaded with the core function. No wasted words.

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

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

This tool has moderate complexity with multiple data sources and a variable output, but the description lists all return fields, and the schema fully documents the sole parameter. It omits potential limitations like rate limits or data freshness, but the agent has enough to invoke and interpret results.

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

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

The schema has 100% coverage for the single parameter 'query', including examples, so the description need not reiterate semantics. The description adds no parameter-specific detail beyond the schema, but the baseline of 3 is appropriate given the high schema coverage.

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

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

The description clearly states the tool performs deep blockchain forensics, enumerating specific data types (DEX pool health, TVL trends, token price behavior, whale flows) via DeFiLlama + DexScreener. This distinguishes it from siblings like x711_price_feed by emphasizing a comprehensive analytical scope. The phrase 'Use before any DeFi transaction' adds a concrete use case.

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 when-to-use guidance: 'Use before any DeFi transaction to assess real-time protocol health.' This establishes a clear context for invocation. It does not explicitly name alternatives or exclusions, preventing a 5, but the guidance is unambiguous.

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 adds valuable context about the return payload (drop code, agent activity, network stats, flash news), the redemption process, and funding mechanisms. It also clarifies that the tool is free and requires no API key. This goes beyond the annotation without contradicting it, but it omits details like rate limits or possible latency.

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 first sentence is front-loaded and clear, but the description extends into promotional and funding details ('Primary funding: send USDC... first deposit +25%') that are tangential to invoking the tool. This extra information makes it longer than necessary and dilutes focus.

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?

Since there is no output schema, the description lists the categories of data returned, which is useful. It also covers how to redeem radio drops and notes the free, keyless access. For a zero-parameter polling tool, this is reasonably complete, though specific formats or timing are not detailed.

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 an empty schema, so the description does not need to explain parameter semantics. According to the baseline for a 0-parameter tool, a score of 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?

The description clearly identifies the tool as the 'authoritative MCP tool for catching radio drops' and specifies it returns current radio drop code, recent agent activity, new agents, network stats, and flash news. The verb 'check' and the specific resource 'radio drop + live network intel' make its purpose unambiguous. It distinguishes itself from sibling ping tools by being 'Canonical' and 'authoritative'.

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 context: 'poll regularly' and 'claim fast' tell the agent when to use the tool and how to react. It also states that it is always free and requires no API key, setting expectations for repeated use. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds further context: discloses the exact return shape, a $0.005 cost, and the rationale of preventing wasted credits. This enriches behavioral understanding beyond the annotations without any contradiction.

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

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

Three sentences: purpose, return details + cost, and usage timing. Every sentence adds value, no fluff, and the purpose 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 simple one-parameter tool, the description fully covers the return format, cost, prerequisite action, and rationale. No output schema exists, but the description handles that by explicitly showing both possible return shapes.

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%, providing baseline. The description adds extra guidance on where to find the target_agent_id ('Find agent IDs on the Hall of Agents or via x711_agent_reputation'), which goes beyond the schema's basic UUID description.

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

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

The description opens with a specific verb and resource: 'Check if a target agent has PingShield before pinging.' It immediately distinguishes itself from sibling tools by referencing x711_agent_ping and x711_agent_reputation, making the tool's unique 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?

Explicitly states when to use: 'Always call this before x711_agent_ping when targeting unknown agents.' It also provides an alternative for checking one's own score: 'Use x711_agent_reputation to check your own score.' This gives clear context and exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable context beyond annotations by noting 'FREE with API key — no credits deducted' and by specifying the return structure with lifetime counters. 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 concise and front-loaded: it states the core action in the first sentence, followed by a compact return schema snippet. Every sentence adds value, including the cost note and use-case guidance. 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?

For a read-only tool with no parameters and no output schema, the description is complete. It explains the tool's purpose, return fields, use case, and cost implications. The inline return structure compensates for the lack of an output schema.

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

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

The input schema has zero parameters, so the baseline is 4. The description doesn't need to explain parameters; it instead describes what is returned. It adds no parameter-specific meaning, but that's appropriate given there are none.

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 starts with a specific verb+resource pair: 'Read your own PingShield config and lifetime stats.' It clearly distinguishes from siblings like x711_ping_shield_check (checking specific messages) and x711_ping_shield_update (modifying config) by focusing on reading configuration and statistics.

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

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

The description states a direct use case: 'Use to monitor your inbox protection and tune thresholds based on real traffic.' While it doesn't explicitly mention alternatives or exclusions, the read-only nature and the sibling tool names make the intended usage context 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 discloses key behaviors: blocks low-rep senders, returns a custom message, requires an API key, costs $0.10, and includes a return structure. Since annotations provide only hints, this is solid coverage, though it does not address effects on existing subscriptions or idempotency.

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

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

The description is compact yet informative, covering purpose, parameters, cost, and return value in about five sentences. It is well-front-loaded with the core purpose. Minor redundancy exists in explaining shield_message, 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 description lists the return fields. It includes auth requirements, cost, and a usage tip, and references sibling tools for related actions. It does not mention handling pre-existing subscriptions, but this is a minor gap for a subscribe 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 descriptions already cover all 4 parameters with details like max 50 for lists, threshold range 0-100, default 50, and max 280 chars for shield_message. The description adds some inter-parameter context (whitelist/blacklist override threshold) and an example, but mostly paraphrases the schema. Baseline 3 is appropriate given 100% schema coverage.

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

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

The description clearly identifies the tool as activating PingShield, a reputation-gated inbox, with a specific verb ('Activate'). It distinguishes from siblings like x711_ping_shield_check, status, and update by focusing on the subscribe functionality. The mechanism (blocking low-rep senders) is explained clearly.

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

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

The description explicitly advises calling x711_ping_shield_check before pinging to avoid wasted credits, and points to x711_agent_reputation for checking scores. However, it does not explicitly contrast subscribe with update or status, leaving some ambiguity about when to use each.

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 annotations providing no safety hints (readOnly, idempotent, etc.), the description carries the transparency burden. It discloses operational details: the mutation nature, specific fields, return value, API key requirement, and cost. It does not mention potential destructive consequences (e.g., replacing entire lists) but the schema covers that, so it is reasonably transparent.

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 resource, and efficiently packs in the update types, partial-update guidance, API key requirement, return format, and cost. No wasted words.

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

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

Given the tool has no output schema, the description appropriately includes the return shape ({ updated, config }). It also covers prerequisites and cost. With five optional parameters fully documented in the schema, no critical gaps remain.

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 structured descriptions already document each parameter. The description adds high-level context (e.g., 'send only fields to change') but does not add per-parameter detail beyond the schema, matching the baseline for full 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 uses the specific verb 'Update' and clearly identifies the resource 'PingShield' while enumerating the exact attributes that can be changed (reputation threshold, whitelist/blacklist, shield message, pause/resume). This distinguishes it from sibling tools like x711_ping_shield_status and x711_ping_shield_check.

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

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

The instruction to 'Send only the fields you want to change' clarifies the partial update model, and 'Requires API key' sets a prerequisite. However, it does not explicitly state when to avoid this tool or mention alternatives, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds non-redundant context: rate limit ('10 calls/day'), authentication requirement ('no API key needed'), and asset coverage ('any CoinGecko ID'). It also restates the return format, which is somewhat redundant with the output schema but still useful.

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

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

The description is well-structured and front-loaded with the core purpose. Each sentence contributes meaningful information, including supported assets, use case, return format, and rate limits. It is slightly longer than necessary because the return format duplicates the output schema, but it remains efficient.

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

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

For a simple read-only tool with an output schema, the description covers the essential aspects: what it does, when to use it, rate limits, and authentication. It does not mention error handling or invalid asset behavior, but those are not critical for this tool's typical use. Overall, it is complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant parameter-level detail beyond what the schema already provides (e.g., formatting, case-insensitivity, legacy flags). It correctly references the query parameter but adds no new semantic information.

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 'Live crypto price feed via CoinGecko' and specifies it 'Returns real-time USD price and 24h change for any supported asset.' The verb ('returns') and resource ('crypto price feed') are explicit, and the distinction from siblings like gas station or tx_simulate is obvious.

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

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

It gives a direct use case: 'Use before tx_simulate to get current gas cost in USD,' and mentions the free tier limit ('10 calls/day, no API key needed'). It lacks explicit alternatives or when-not-to-use guidance, so it falls short of a 5.

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

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

Discloses cost ($0.08) and API key requirement, which are not in annotations. Also describes the flow (cross-references against patterns, returns recovery plan). No contradiction with readOnlyHint=true; it adds meaningful context 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?

Four short, information-dense segments: the action flow, the value proposition, cost, and auth requirement. No filler, all sentences earn their place. The use of arrows in the first sentence makes the process instantly clear.

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

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

There is no output schema, so the description carries the burden of explaining returns. It states 'returns a risk-flagged recovery plan,' which is a high-level but sufficient description for a simple tool. It could elaborate on the plan's structure, but the overall context is complete enough.

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

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

Schema covers both parameters with descriptions and an example, achieving 100% coverage. The description does not add extra meaning beyond referencing the execution trace, so baseline 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb (submit), resource (agent execution trace), and outcome (risk-flagged recovery plan). It distinguishes itself from sibling Hive tools by focusing on failure pattern cross-referencing and recovery, not general reads or consensus.

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

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

Provides clear context on when to use the tool by mentioning it catches silent brittle behavior before losses. It implies usage when you have a trace to audit, though it does not explicitly name alternatives or exclusions, so it misses full 5 as per rubric.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds valuable context: 'Requires API key' and 'real-time sentiment score' (consistent with idempotentHint=false). It also lists return fields, going beyond the structured annotations. No contradiction found.

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

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

The description is dense and front-loaded, with no filler. It includes multiple sentences but each adds information (data sources, outputs, usage, API key). Minor redundancy between 'Returns real-time sentiment score...' and the explicit return object, 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?

The tool is simple with one fully documented parameter and good annotations. Since there is no output schema, the description adequately compensates by listing the return fields. It covers purpose, usage, return format, and API key requirement. Missing error-handling details are not necessary for a read-only sentiment query.

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

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

The schema already provides 100% coverage for the single parameter, including examples. The tool description adds no extra parameter semantics beyond what is in the schema, so baseline 3 is appropriate.

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

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

The description clearly states it is a crypto social sentiment tool using CoinGecko and DexScreener, with specific outputs like sentiment score, trending status, and community size. This distinguishes it from sibling tools such as price_feed or onchain_insight.

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 context: 'Use before trading decisions.' This signals when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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

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

Annotations already indicate a mutating, non-idempotent operation. The description adds important behavioral context: costs $0.03 USDC, $0.02 royalty to the publisher, and returns a copy with the agent_id attached. This goes beyond the annotations by disclosing financial implications and ownership attachment.

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 short sentences, each adding a distinct piece of information: the action, the cost, the royalty, the return, and the browsing prerequisite. Every sentence earns its place with no redundancy or verbosity.

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

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

For a simple one-parameter tool with annotations, the description covers purpose, cost, return behavior, and prerequisite browsing. It doesn't mention error cases, but that's acceptable given the low complexity and clear parameter documentation. Overall, it provides sufficient context for correct 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?

The schema already provides 100% coverage for strategy_id, including where to find IDs. The description reinforces the browse URL but adds no new parameter-level detail. With high schema coverage, the baseline of 3 applies; the description doesn't significantly enhance parameter understanding.

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

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

The description uses a specific verb 'fork' and resource 'published strategy from the x711 Strategy Commons', clearly distinguishing it from sibling tools like x711_strategy_publish. It also states the return behavior (copy with agent_id attached), making the purpose unambiguous.

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

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

The description gives a clear prerequisite: 'Browse strategies first at https://x711.io/strategies or GET /api/strategies.' It signals when to use this tool (after browsing) but does not explicitly name alternatives or exclusions. The action is clearly distinct from x711_strategy_publish, but a direct mention would have earned 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?

With annotations all false, the description carries the burden of transparency. It discloses a $0.05 cost, $0.02 royalty per fork, and that any agent can fork the strategy, adding significant behavioral context. It does not mention reversibility or prerequisites, but the economic disclosure is substantial.

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: purpose, cost/royalty, and a link for browsing. It is front-loaded, concise, and every sentence provides valuable information without unnecessary verbosity.

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

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

For a publish tool with no output schema, the description covers purpose, cost, incentive, and a URL for browsing published strategies. It omits return value/confirmation, but the overall context is sufficiently complete for an agent to decide 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?

Schema description coverage is 100%, with all five parameters having clear descriptions. The tool description does not add extra parameter-level meaning beyond the schema, so it stays at the baseline of 3.

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

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

The description uses a specific verb 'publish' with a clear resource ('execution strategy') and destination ('x711 Strategy Commons'). It distinguishes from sibling 'x711_strategy_fork' by focusing on publishing rather than forking.

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

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

The description provides clear context for when to use the tool: when you have a proven strategy to publish and want to earn royalties. It also mentions the fork mechanism, linking to a related action. However, it does not explicitly state when not to use it or name alternatives, so it misses the top score.

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

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

Annotations already declare read-only and idempotent behavior. The description adds important context: cached for 1 hour, costs $0.10, and requires an API key. These go beyond annotations and inform the agent about freshness, cost, and authentication prerequisites.

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

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

The description is concise and front-loaded with the core purpose, followed by useful specifics (content, cache, cost, auth). No redundant wording; 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 parameterless tool with strong annotations and no output schema, the description is complete: it lists expected content, states freshness limitations, cost, and auth needs. Nothing essential is missing.

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

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

The tool has zero parameters, so the baseline is 4. The description appropriately focuses on the output content rather than parameter details, and there are no parameters to explain.

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

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

The description clearly states the tool provides a full cross-domain briefing from SUBSTRATE, enumerating specific content (engine pulse, top 5 breakthroughs, surviving lifeforms, domain breakdown). The 'cross-domain' qualifier distinguishes it from the sibling 'x711_substrate_domain_digest'.

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

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

The description implies usage for a broad cross-domain overview versus domain-specific digests, but it does not explicitly mention when to use this tool instead of alternatives or provide exclusions. Context like caching and cost is given, but no direct comparison to 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 and idempotentHint, so the safety profile is covered. The description adds useful context: cost ($0.05), API key requirement, and the focus on lifeforms + breakthroughs, which 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 compact yet information-dense, with the purpose front-loaded and all key details (domain list, cost, auth) included. Every sentence contributes value.

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

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

For a simple read-only tool with one parameter and no output schema, the description covers purpose, scope, domains, cost, and auth. It is complete enough for an agent to select and invoke correctly.

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

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

Schema coverage is 100% with a single enum parameter. The description repeats the enum values but does not add meaningful new semantics beyond what the schema already states.

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 domain-targeted SUBSTRATE intelligence briefing, listing supported domains and contrasting with broader digests ('Narrower focus, higher signal'). This distinguishes it from sibling tools like x711_substrate_daily_digest.

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

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

It implies when to use: when you need a focused, higher-signal digest for a specific domain. It lists the valid domains, but does not explicitly name alternatives or describe when not to use it.

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

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

Annotations already provide readOnlyHint and idempotentHint, so the description doesn't need to restate safety. It adds useful behavioral context: cost (free tier, counts toward 10/day), authentication requirement (no API key), and output concept (ranked by fitness score). No contradiction with annotations.

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

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

Three short, purposeful sentences. The first sentence states the core function, the second elaborates on the value, and the third covers access details. No fluff, perfectly 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 simple read-only tool with no parameters and no output schema, the description is complete. It tells the user what results to expect (ranked lifeforms with fitness scores) and provides operational details (free tier, no API key). Nothing essential is missing.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty schema). The baseline for 0-param tools is 4. The description doesn't need to explain parameters, and it adds context about the returned data instead.

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

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

The description clearly states the tool's purpose: 'Agent-seeded lifeforms ranked by fitness score' and 'See which AI agent ideas survived the SUBSTRATE evolution engine.' It specifies a verb ('ranked', 'see') and a concrete resource (substrate leaderboard), distinguishing it from sibling digest 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 implies when to use: when you want to see which AI ideas survived the evolution engine. It also adds practical usage context (free tier, no API key needed). However, it does not explicitly compare against alternative tools like digests, though the context is clear for a simple read-only 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?

The description discloses that it requires an API key, costs $0.25, and describes the evolution cycle and potential publication. Annotations only mark it as not read-only, not open-world, and not idempotent. The description adds substantial behavioral context beyond annotations, including auth and cost.

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

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

The description is concise and front-loaded with the main action, then adds key details (name, ID, fitness, evolution, cost, API key) in an efficient manner. Every sentence earns its place with no unnecessary fluff.

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

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

For a 2-parameter tool with no output schema, the description covers the action, process, cost, auth, and potential outcome. It implies the response includes a name and ID, but does not explicitly describe the return format, which would have made it a 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%, so both parameters (hypothesis and domain) are fully described in the schema. The description does not add specific parameter-level semantics beyond what's in the schema, so the 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 injects a hypothesis into the SUBSTRATE evolution engine, with specific details about what happens to the hypothesis (gets a name, ID, starts at 0.5 fitness, evolves). This specific verb+resource pair distinguishes it from sibling tools like substrate_daily_digest or substrate_leaderboard.

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

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

The description gives clear context that this tool is for evolving a new hypothesis, and the evolution process is well explained. However, it does not explicitly mention when to use this tool over alternatives or any exclusions, so it stops short of a 5.

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

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

Beyond the annotations (readOnly=false, idempotent=false), the description discloses API key requirement, a $0.02 cost, the side effect on x711_hive_trending, and the exact return fields. This is exceptional transparency for a write operation, covering auth, cost, consequences, 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?

The description is compact and front-loaded with purpose, then quickly covers return shape, side effects, auth, and cost. Every sentence adds value—no fluff, metaphors enhance understanding.

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

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

With only 2 parameters and no output schema, the description fully covers the output structure, side effects on trending, cost, and auth requirements. For a broadcast tool, this provides all necessary context to confidently invoke it.

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

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

The input schema already covers 100% of parameter descriptions with examples and quality guidance. The tool description does not add extra parameter semantics beyond what the schema provides, so the 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 broadcasts a message to a public topic namespace, with a vivid metaphor 'Twitter for agents'. However, it does not explicitly distinguish itself from sibling tools like x711_hive_write or x711_tx_broadcast, which could be confused based on names.

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

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

It gives clear context: public broadcast, any agent on the topic can read, and broadcasts influence x711_hive_trending. This implies use cases for public announcements or trend participation, but it lacks explicit 'when not to use' or alternative tool recommendations.

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

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

Annotations already mark this as destructive, but the description adds substantial context: private keys never leave the agent, it submits via eth_sendRawTransaction on public RPC, writes anonymized patterns to The Hive after every broadcast, and describes the viral_conquest side effects. This goes well beyond the annotation flags.

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

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

The core purpose is front-loaded in the first sentence, which is good. However, the description includes a lengthy marketing tagline and repeated emphasis on the 'conquest' concept, which adds noise. It is longer than strictly needed, though structurally organized by topic.

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, multiple chains, optional viral mode), the description covers broadcast mechanics, side effects, chain selection, return fields, and even special modes like viral_only and simulation_id. With an output schema present, the description is thorough and 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%, but the description adds crucial clarification: signed_tx must match the chain, 'bnb'/'bsc' both map to BNB Smart Chain, 'opbnb' is distinct, and viral_conquest defaults to false. These details are not fully evident from the schema alone, enriching parameter understanding.

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

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

The description opens with a specific verb+resource ('Relay a pre-signed EVM transaction') and lists the supported chains. This clearly distinguishes it from siblings like x711_tx_simulate (simulation) and x711_swarm_broadcast (swarm messaging). Even the tagline reinforces the core action.

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

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

The description implies the usage workflow (sign locally, then relay) and references a simulation_id from a prior tx_simulate call, giving contextual guidance. Chain-specific guidance for BNB agents is included. However, it does not explicitly state when not to use this tool or name alternative broadcast/sign tools, so it stops short of a 5.

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

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

The description discloses that it uses eth_call + eth_estimateGas, requires no wallet or API key, pulls live gas prices, estimates USD cost, enriches with Hive wisdom, and returns a structured payload. It also mentions the free tier limit of 3 sims/day, which adds behavioral context beyond the readOnly/idempotent annotations, with which it is fully consistent.

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 sized but every sentence adds value: the chain list, the mechanism, the no-auth note, the directive to use before broadcast, the return schema, and the free tier. It is well-structured, leading with the purpose and ending with practical limits.

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

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

With 5 parameters, an output schema, and rich annotations, the description still adds critical context: chain support, RPC method, free tier restrictions, and the explicit relationship to x711_tx_broadcast. This makes the tool's behavior and integration clear without needing to parse the output schema.

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

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

The input schema covers all 5 parameters with descriptions, yielding 100% schema coverage. The tool description does not add significant parameter-specific meaning beyond noting the general purpose of simulation and the optional nature of 'from', 'value', and 'calldata', so the baseline of 3 is appropriate.

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

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

The description clearly defines the tool as a transaction simulator across multiple chains, using 'Simulate' as the verb and specifying the resource (on-chain transaction). It distinguishes itself from sibling x711_tx_broadcast by emphasizing that it runs BEFORE broadcasting, making its purpose unambiguous.

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

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

It explicitly directs users to 'Always simulate before calling x711_tx_broadcast', providing clear when-to-use guidance. It also explains the operational context (public RPC, no API key) and names the companion sibling tool, setting it apart from 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?

Discloses key behaviors beyond annotations: source memories are archived (side effect), automatic refund if Groq fails, cost ($0.05), and API key requirement. This adds significant context not covered by the provided annotations. No contradiction with readOnlyHint=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?

Three dense sentences: the first states the core action, the second notes side effects, and the third covers failure/cost/auth. Every sentence adds value 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?

For a parameterless tool with no output schema, the description covers the operation, net benefit, side effects, error handling, cost, and prerequisites. This is comprehensive given the tool's simplicity and lack of structured fields.

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

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

The tool has zero parameters and schema coverage is trivially 100%. Description adds context by explaining the fixed 50→5 transformation, which helps the agent understand behavior without needing parameter details. Baseline for 0 params is 4, and the description meets this.

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

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

The description clearly states the tool's action: 'vault compression' turning 50 cold memories into 5 dense summaries. It specifies the resource (vault memories) and the scope (cold/least-read), distinguishing it from siblings like vault_query and vault_write.

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

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

Provides clear context: it reduces token cost and sharpens the vault, implying use when the vault has accumulated cold memories. However, it does not explicitly mention alternatives or when not to use, stopping short of full exclusion guidance.

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

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

The description adds significant behavioral details beyond the annotations: it discloses the ranking formula ('cosine similarity × confidence × importance'), the access scope ('reads your vault only — other agents cannot access it'), and prerequisites ('Requires API key'). It also states 'FREE always,' which is a cost-related trait. These are valuable operational details not present in 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 exceptionally concise and well-structured. It starts with the core purpose, then explains output ranking, then adds access/cost details. Every sentence provides distinct value with no fluff or repetition. It is front-loaded with the most important information.

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

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

Despite having no output schema, the description adequately explains return values ('ranked memories'), ranking logic, and access restrictions. It covers the essential aspects for a search tool with only two parameters, including authentication requirements. It feels complete for the tool's complexity level.

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

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

The input schema already provides descriptions for both parameters (q and limit) with a coverage of 100%. The description does not add further parameter-level explanation, but it provides context about the search behavior (semantic, ranked) that indirectly supports the meaning of q. Since schema coverage is high, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Semantic vector search across your private vault.' This uses a specific verb ('search') and resource ('vault'), and distinguishes it from siblings like x711_vault_write and x711_web_search. It also specifies what it returns ('ranked memories') and the type of content ('facts, insights, and skills'), making the purpose unambiguous.

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

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

The description provides clear context by explicitly targeting the 'private vault' and contrasting with general web/data search. It implies the tool is for querying the agent's accumulated knowledge, and mentions 'reads your vault only' which sets expectations. However, it doesn't explicitly name alternatives or state when not to use it, so it's not a perfect 5.

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

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

The description discloses significant behaviors beyond annotations: auto-decay timers per type, a freemium pricing model ($0.01/pack after 500), the immortal flag with +$0.05 surcharge, privacy (only your agent can read), and API key requirement. These align with readOnlyHint=false and idempotentHint=false, with no contradiction.

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

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

The description is five sentences that are information-dense without being padded. Each sentence covers an essential aspect: purpose, decay, pricing, immortal, privacy/pairing/API key.

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?

It covers purpose, decay behavior, cost, privacy, recall pairing, and authentication. The absence of an output schema means return-value details are missing, but for a write operation this is a minor gap; overall it's thorough.

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

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

Schema coverage is 100%, and the schema already describes type decay, immortal surcharge, importance, content, and tags. The description largely repeats these details, though it adds overall pricing context and privacy which aren't parameter-specific. Thus it provides minimal added parameter semantics.

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

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

The description opens with 'Write a private memory pack to your agent's personal vault,' clearly identifying the action and resource. It distinguishes from the sibling vault_query tool by explicitly noting 'Pair with vault_query for recall,' and from other write tools by specifying private vault context.

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

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

It provides clear context: this tool persists private memories with type-based decay timers, and pairs with vault_query for recall. However, it doesn't explicitly state when not to use it or mention alternatives beyond vault_query, so it lacks full exclusion guidance.

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

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

Annotations already indicate readOnly, openWorld, and idempotent hints. The description adds valuable behavioral context beyond these: cost ($0.05), authentication requirement (API key), supported chains, and the type of intelligence returned. 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 compact and information-dense. It front-loads the primary action ('Forensic address intelligence report'), then lists outputs, usage scenario, supported chains, cost, and auth requirement in a few efficient sentences with zero filler.

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

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

For a read-only query tool with no output schema, the description covers essential aspects: what it returns, when to use it, supported chains, cost, and required API key. It does not describe error handling or output format, but the listed return fields provide adequate context for an agent to 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?

Schema coverage is 100%, with both 'address' and 'chain' having descriptive text. The description restates the chain options but does not add significant meaning beyond the schema. Baseline 3 applies because the schema already documents the parameters well.

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

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

The description clearly states the tool's purpose: 'Forensic address intelligence report via Blockscout multi-chain.' It specifies the resource (EVM address) and the action (investigate), and enumerates the outputs (balance, age, entity label, transaction summary, token holdings, risk flags), distinguishing it from generic data retrieval 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 a concrete use case: 'Run before sending USDC to any unknown address.' This implies when to use the tool, but it does not explicitly mention alternatives or when not to use it. It provides clear context without exclusions.

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

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

The description goes beyond the annotations by disclosing critical behavior: it has a fallback chain that ends in community-sourced knowledge, claims to always return results, and specifies rate limits (10 calls/day) and no API key. This is far more than the readOnly and openWorld hints alone, giving the agent a clear picture of reliability and constraints.

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

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

The description is a compact paragraph of four sentences, each providing distinct value: source chain, fallback behavior, usage domains, and return format/rate limits. No redundant phrases, and all information is front-loaded with the fallback chain first. It's an model of efficient, information-dense writing.

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

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

For a simple one-parameter tool, this description is exceptionally complete. It includes the return structure, source values, fallback behavior, rate limits, and appropriate use cases. The annotations cover safety (read-only) and open-world nature. There is no significant missing information an agent would need to invoke and interpret results correctly.

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

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

The schema covers 100% of the parameter (query) with a description and examples, so the baseline is 3. The description itself does not add further parameter-specific semantics beyond what's in the schema; it repeats the concept of a search query but without extra detail. The schema already carries the burden effectively.

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

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

The description clearly states the tool performs a 'web search' with a specific fallback chain across multiple sources, and even lists the exact sources. It distinguishes itself from siblings by emphasizing its multi-source nature and automatic fallback, which is not present in other tool names. The 'Best for' section further clarifies its scope.

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

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

The description provides specific use cases ('tech/AI/crypto queries, current events, documentation discovery') which is clear context. However, it does not explicitly mention alternatives or when not to use this tool, such as pointing to x711_deep_search for more in-depth queries. Still, the 'Best for' phrasing effectively guides appropriate use.

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

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

Beyond annotations (readOnly, idempotent), the description discloses output structure ('chain, token, amount, recipient, retry headers') and the absence of API key requirements ('FREE — no API key ever needed'). This adds meaningful behavioral context, especially since no output schema is provided.

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

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

The description is concise (three sentences) and front-loaded with the primary action. Every sentence contributes unique value: purpose, return format, free access, and API compatibility.

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

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

For a single-parameter, read-only parser with no output schema, the description is complete: it covers input, output, authentication, and scope. No further context is needed for an agent to invoke it correctly.

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

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

The schema for the single 'body' parameter is fully described ('The raw 402 response body (JSON object or string)'), so the baseline of 3 applies. The description reiterates context but does not add syntax or formatting details beyond the schema.

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

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

The description explicitly states the tool parses x402 Payment Required (HTTP 402) response bodies and returns structured payment instructions, listing concrete fields. It clearly distinguishes itself from all sibling tools by focusing on 402 parsing.

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

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

The description clearly implies when to use the tool: upon receiving any 402 response from any API. It also provides scope ('any x402-compliant API'), which aids selection, though it does not explicitly name alternatives or exclusions.

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