MeshMarket

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

Annotations include readOnlyHint=false, but the description goes further: it states the tool 'writes up to 3 new memories back' (mutation), describes fallback behavior when the memory server is unreachable ('falls back to its own always-on store otherwise — never fails the call'), names the exact model used, and notes that the response includes the model name. No contradiction with annotations; the description adds substantial behavioral context.

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

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

The description is dense but every sentence carries distinct information: core function, memory behavior, fallback, usage guidance, model, input, output, and cost. It is front-loaded with the primary purpose and structured to flow from what → when → how → returns. No filler or repetition.

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

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

This is a complex tool with no output schema, but the description covers all critical aspects: memory read/write counts, semantic recall, fallback guarantee, model, cost, usage context, input shape, and a complete list of return fields. It also distinguishes siblings. Nothing essential is missing 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%, so baseline is 3. The description adds value by summarizing the input format ('Input: {think: string}') and enumerating the return fields, which is helpful since there's no output schema. However, it omits the aliases and the optional character scope, which the schema documents fully. Overall, it meaningfully supplements the schema without redundancy.

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

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

Description opens with 'Reason over a question or task with your agent's own persistent memory in the loop' – a specific verb+resource+mechanism. It clearly differentiates from siblings: 'agent-memory covers plain store/recall' and 'agent-brain-smart runs the identical contract on claude-sonnet-5.' This is unambiguous about what the tool does and how it differs.

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

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

Explicit usage guidance: 'Use for decisions that should build on what the agent already knows' and directly names the alternative for plain store/recall ('agent-memory'). It also references agent-brain-smart for a different model tier. This tells the agent when to pick this tool over its closest siblings.

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

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

The description discloses the memory loop (recall up to 12, write up to 3), the serving model, cost per call, and that the response names the serving model. These go well beyond the sparse annotations (readOnlyHint false, openWorldHint true, destructiveHint false) and give the agent a concrete model of side effects 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 moderately long but every sentence carries useful information: tier, contract, model, cost, when-to-use, input, and output. The trailing '(20 MESH/call, a tool · cognition)' is metadata that could be trimmed, and the opening repeats the title, but overall it is front-loaded and well-structured.

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

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

For a tool with one nested object parameter and no output schema, the description covers the input shape (albeit simplified), the return fields, model, cost, and usage guidance. Aliases are documented in the schema, so the description plus schema together are complete enough for correct invocation.

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

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

The description's 'Input: {think: string}' omits the required outer 'input' wrapper described in the schema, which could mislead invocation. It adds no information beyond the schema's 100% parameter descriptions and fails to mention the optional 'character' parameter, so it subtracts rather than adds value.

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

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

The description clearly identifies this as the Smart tier of agent-brain, sharing the identical memory loop but served by claude-sonnet-5 for deeper reasoning. It distinguishes from the sibling agent-brain by model, cost, and quality tradeoff. The purpose is specific and immediately understandable.

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 names agent-brain as the fast default and instructs to pick this tier when answer quality matters more than price. This gives a direct when-to-use vs alternative. The statement 'identical contract' also implies the same use cases as the base tier.

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=false, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the action defaults (non-empty content infers store, otherwise recall), the 2 MESH/call cost, and the scoped/private nature of the memory. It doesn't detail what happens on overwrite or deletion, but the annotations plus the action-default disclosure are solid.

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

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

The description is compact and front-loaded with the core purpose, then gives the action syntax, then the use case, then the sibling contrast, then cost. Every sentence earns its place. Slight redundancy with the schema's action enum, but the inference behavior is worth stating.

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 a rich schema (100% coverage) and annotations covering safety, the description is nearly complete. It explains the action inference, the cost, and the relationship to agent-brain. The only gap is that it doesn't describe the return format of recall results, but with no output schema and the schema already covering inputs, this is a minor omission.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds value by explaining the action inference behavior (non-empty content/remember/text infers store, otherwise recall) and the cost, which are not in the schema. It doesn't repeat the schema's parameter details, which is appropriate.

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

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

The description states a specific verb-resource pair ('Store or recall private, scoped memory') and immediately distinguishes itself from the sibling agent-brain by noting that agent-brain is the reasoning layer that reads/writes memory in the loop. This makes the tool's role clear and differentiates it from its closest sibling.

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

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

The description gives explicit usage context: 'Good for continuity across sessions' and contrasts with agent-brain as the reasoning layer. It doesn't explicitly say when NOT to use it or name alternatives beyond agent-brain, but the session-continuity context plus the sibling contrast provides clear 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=false, openWorldHint=true, and destructiveHint=false, so no safety contradiction exists. The description adds useful non-schema context: cost per call ('6 MESH/call'), a 'reasoning' tag, and that output is a 'structured recommendation'. It does not go into side effects or operational behavior beyond that.

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 clause, and the cost/tag suffix is compact and useful. The provenance phrase 'the original api.meshtool.ai capability, now settled in MESH' is mildly promotional and not strictly necessary, but overall the description remains short 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?

The description gives the essential usage and cost details, and the schema fully documents the parameters. However, 'structured recommendation' is vague, and since there is no output schema, the agent receives little guidance about the expected response shape.

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 `context`, `goal`, and `constraints` each documented in the schema. The description's 'Input: { context: string }' merely restates part of the schema without adding new meaning, so the schema carries the parameter-documentation burden.

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

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

The description clearly states a specific verb ('Analyze') and resource ('any business situation'), and promises a 'structured recommendation' as the return value. It does not explicitly differentiate from sibling tools, but the phrasing is specific enough to distinguish this from the other tools in the sibling list.

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

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

The phrase 'Analyze any business situation' implies the tool should be used whenever business analysis is needed, which provides a reasonable context of use. However, there is no explicit guidance on when not to use it, no mention of alternatives, and no exclusion criteria.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds context by stating it is an educational resource (a tool · education) and notes a cost of 4 MESH/call, which gives agents a sense of interaction cost. However, it does not describe what actually happens when called (e.g., returns a guide, no side effects) or how the input payload is used. With annotations present, the description provides marginal extra value but not rich behavioral disclosure.

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

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

The description is a single paragraph but well-structured: it starts with the core identity, then lists covered topics, then the target audience, and finally cost/category. Each clause contributes useful information. It is slightly long-winded but not bloated. The front-loaded purpose makes it easy to scan.

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

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

Given the tool is a guide with a single 'input' object parameter, the description should explain what to pass. It only says it covers certain topics but never specifies the expected payload format for this tool. The schema description is misleading because it references other tools' payloads, and no output schema exists. An agent cannot confidently invoke this tool correctly, so the description is incomplete.

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?

Although schema description coverage is 100%, the schema's parameter description is generic and gives examples for other tools (agent-brain, agent-memory) rather than for browser-agent-101. The tool description does not clarify what should go into the 'input' object for this specific tool. This leaves the agent without a clear understanding of how to construct a valid invocation, so the description fails to add meaningful 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 'Plain-language guide to using an AI browser agent' and enumerates the specific coverage areas (agent-to-person work, agent-to-agent work, getting started). This fully distinguishes it from sibling tools like agent-brain or search, which are action-oriented tools rather than educational guides. The name and title are consistent and reinforced by the description, leaving no ambiguity about the tool's purpose.

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

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

The description indicates the tool is 'Perfect for anyone new to agentic tools,' which implies a target audience and when it might be most useful. However, it does not explicitly state when not to use it or name alternative tools for specific tasks. The guidance is inferred from the content ('how to get started from zero') rather than explicit, so it meets the 'implied usage' level but lacks clear 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 discloses key behaviors: kernel-free generation, deterministic (no model call), and the guarantee that non-watertight STL fails the call with MESH refunded. It also mentions the cost (15 MESH/call). Annotations indicate readOnlyHint=false and openWorldHint=true, which align with the description's emphasis on deterministic generation and no model call. The description adds value beyond annotations by explaining failure modes and guarantees.

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

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

The description is concise, front-loaded with the core purpose, and every sentence adds value. It covers purpose, guarantees, failure behavior, determinism, and cost in a compact format. 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 complexity of the tool (many parameters, multiple output formats, guarantees), the description is quite complete. It explains the output formats, the guarantee of wall thickness, failure handling, and determinism. It does not detail return values, but there is no output schema, so the description could have mentioned what the response contains (e.g., base64 STL). However, the description mentions 'binary STL (watertight solid), DXF R12, or SVG' and 'MESH refunded' which gives some context. Slight gap on response structure, but overall adequate.

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

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

The input schema has 100% description coverage for all parameters, so the description does not need to add much. However, the description does not provide additional context beyond the schema, such as relationships between parameters (e.g., wall must be less than pitch) which are already in the schema. The description mentions 'Full input contract: this tool's input_schema' which reinforces reliance on schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: turning parameters into manufacturable files (STL, DXF, SVG) for parametric lattice/perforation panels. It specifies the exact output formats and the guarantee of wall thickness, distinguishing it from generic file generation tools. The verb 'Turn' and resource 'parameters into a manufacturable file' are specific and actionable.

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 fabrication tasks (3D printing, laser cutting, CNC) and mentions deterministic behavior, but does not explicitly state when not to use it or suggest alternatives. It provides clear context for when to use this tool, but lacks explicit exclusions or alternative tool references.

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=false, openWorldHint=true, and destructiveHint=false. The description adds useful output behavior and cost context, including exact receipts, no invented support, and 5 MESH/call. It does not explain why readOnlyHint is false or what side effects, persistence, or audit behavior may occur.

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 action and output, then adds supporting behavioral claims. It is reasonably tight for a single-parameter analysis tool, though the last two sentences lean slightly promotional.

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

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

With no output schema, the description carries the burden of explaining return values. It does name the verdict categories and receipt-citation behavior, but does not describe the exact response structure. The input schema is generic and the annotations' openWorldHint/readOnlyHint=false context is not fully explained.

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 the baseline is 3, but the schema's own input description is generic and even references other capabilities (agent-brain, agent-memory). The tool description usefully clarifies that the payload should contain a claim plus evidence, yet it still does not define exact nested keys or payload structure.

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?

States a specific function: take one claim plus evidence and return CONFIRMED, REFUTED, or UNVERIFIABLE. The verdict enum and receipt-citation standard make the purpose concrete. It does not explicitly differentiate itself from similar siblings such as refutation-pass, 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?

Gives a clear input recipe ('one claim plus the evidence — code, a diff, or text'), which implies when to use it. However, it provides no exclusions, no when-not-to-use guidance, and does not name alternative sibling tools for related tasks.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false) and the description adds useful context beyond them: the cost (3 MESH/call), OWASP-awareness, and that output includes fixes and rationale. However, it doesn't disclose behavioral details like length limits, language support, or whether it mutates state. The additions are helpful but not rich; 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 core purpose is delivered in one front-loaded sentence. The parenthetical '(3 MESH/call, a tool · devtools)' adds minor noise with awkward phrasing, but it is short and conveys cost, so the overall structure is 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 tool with no output schema and a generic, non-tool-specific input schema, the description carries the burden of explaining both the input contract and return behavior, and it does neither. An agent cannot reliably construct a correct call because the payload structure for this tool is unspecified. Missing guidance on expected input format is a critical gap.

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

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

Despite nominal 100% schema coverage, the schema description is a generic template showing examples for OTHER tools (agent-brain, agent-memory) rather than for code-review. The tool description mentions 'pasted code' but never specifies the expected payload structure for the single 'input' object, so an agent cannot determine how to format the code it should pass.

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?

States a specific verb and resource ('Reviews pasted code') with a precise scope covering bugs, OWASP-aware security issues, and style problems. The code-analysis focus implicitly distinguishes it from sibling analysis tools like biz-analyze and task-analysis, and the mention of fixes/rationale sets expectations for output.

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?

'Pasted code' implies when to use the tool (when the agent has code snippets to analyze), but it offers no explicit exclusions or named alternatives. With over 40 siblings including other analysis-oriented tools, the lack of explicit when-not-to-use guidance leaves selection partly to inference.

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 experimental status, the narrow 'reliable output' scope, missing structured caption/scheduler fields, and the 3 MESH/call cost. This adds meaningful behavioral context beyond the sparse annotations and does not contradict them.

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

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

The description is tight and front-loaded: purpose, input, reliable output, limitation, and cost each get a short clause or sentence. There is no redundant or filler content.

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

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

The description gives enough high-level context to select the tool, but not enough to construct the actual 'input' payload: it never shows a concrete example or field names for the clip library/reactions. With no output schema and one generic required object, this is a genuine gap.

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

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

While the schema already describes the input generically as a 'capability-specific payload', the description adds the key semantic guidance that the payload should contain a clip library plus the last post's reactions. It lacks a concrete example or field names for this specific tool, so it does not earn a 5.

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?

It clearly identifies the tool as an 'experimental content-ranking planner for repost loops' and states the reliable output: a next-pick recommendation and an explanatory note. However, it does not explicitly differentiate it from sibling tools such as lane-post or mesh_publish, leaving some ambiguity about when this one is preferred.

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 usage context: feed it a clip library and the last post's reactions, and expect a recommendation/note. It does not, however, state when not to use it or which sibling alternative to choose, so it stops short of full routing 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 goes beyond annotations by characterizing the tool as a raw gateway that relays the league app's response, implying pass-through behavior with no interpretation. It also discloses the 1 MESH/call cost and gives examples of mutating calls like set_lineup and trades, which is useful context for a non-read-only tool.

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

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

The description is compact and front-loads the core purpose ('Raw gateway') before giving examples and usage constraints. The opening repeats the tool title and the trailing 'a tool · sports' adds little, but most sentences carry meaningful information.

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

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

For a single-parameter pass-through gateway with no output schema, the description adequately covers protocol, example methods, intended audience, cost, and the fact that responses are relayed from the league app. It does not specify a full JSON-RPC request shape, but the 'already know the contract' framing makes that a reasonable omission.

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?

Although the schema has 100% coverage, its 'input' property description is a generic placeholder with irrelevant agent-brain/agent-memory examples. The tool description compensates by explaining that the input should be a JSON-RPC request body and by naming realistic methods such as tools/list and tools/call, adding essential meaning beyond the schema.

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

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

The description clearly identifies this as a raw gateway into a private fantasy-football MCP server that accepts JSON-RPC request bodies and relays responses. It names concrete operations (get_standings, get_roster, set_lineup, trades, weekly processing) and explicitly separates itself from plain-language lineup advice, making its purpose and scope 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 gives clear context: it is for agents that already know the fantasy-mesh MCP contract, not for users wanting plain-language lineup advice. It provides examples of valid calls, but it does not name a specific alternative tool for the excluded plain-language use case.

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 readOnly/openWorld/destructive hints; the description adds useful behavior beyond them: the tool is curated-only, public-safe, and expressly does no live memory/repo/vault reads, and it discloses the 4 MESH/call cost. No contradiction with 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 core behavior, exclusions, and cost are packed into one front-loaded sentence, and the parenthetical is efficient. It is slightly cryptic ('tool · knowledge', '4 MESH/call'), but nothing is padded.

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 a nested payload and no output schema, this description would need to specify the request shape and return format to be safely callable. It provides purpose and scope but leaves the core 'what do I put in input and what comes back' undefined, and the schema description directs the agent to unrelated tool payloads.

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's only parameter is a generic 'input' object with examples for agent-brain and agent-memory, neither of which is this tool. The main description does not clarify the expected payload for DevDesk COG Public Ask, so the nominal 100% coverage does not actually help an agent formulate the correct question/query object.

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 names a specific operation (Public-safe Q&A) over a defined resource (audited DevDesk COG facts) and lists the topics covered. The 'Curated only; no live memory, repo, or vault reads' clause distinguishes it from memory/repo tools among the siblings, though it does not explicitly name a sibling to prefer.

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 it is appropriate: ask about audited COG facts, curated information, public-safe questions. It gives an exclusion ('no live memory, repo, or vault reads') but never states when to use an alternative tool or names alternatives, so the agent is left to infer routing from 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 only say readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds useful behavioral context: cost per call (2 MESH), output characteristics (status, timing, selected headers, preview), and capability boundaries (no vault/inbox/custom headers). This meaningfully supplements 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 compact sentences, with the core purpose and output front-loaded before constraints and cost. The opening repeats the tool name/title, which is mild redundancy, but overall the description is efficient and easy to scan.

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

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

The description reveals output shape and constraints, but omits the critical input contract for invoking the probe. There is no output schema, no parameter examples for this specific tool, and no indication of how to pass the URL/method, so an agent cannot reliably construct a valid call from the description alone.

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 only documents an 'input' object with generic examples for other tools ('agent-brain', 'agent-memory'), not for this probe tool. The description says GET/POST and endpoint but never specifies how to structure the input object, leaving the essential parameter semantics undocumented.

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?

States a specific action (probe), a resource (public HTTPS endpoint), allowed methods (GET/POST), and the bounded return fields. It does not explicitly compare itself to the sibling 'fetch' tool, but the scope is clear enough to distinguish the core behavior.

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?

Gives clear context: the tool is for probing public HTTPS endpoints with GET or POST, and explicitly excludes vault expansion, inbox access, and custom headers. It does not name an alternative tool or state a when-not-to-use condition relative to siblings, 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 declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds valuable behavioral context: it is a browser-lane render, it returns only bounded title/headings/snippets, and it costs 3 MESH/call. It also explicitly states it does not access private memory, vault, or estate context, which is important behavioral disclosure beyond the annotations.

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

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

The description is compact and front-loaded: it states the action, the resource, the output bound, and the privacy exclusion in two sentences. The cost note and tool tag are appended without bloat. 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?

For a single-parameter tool with no output schema, the description covers the key facts: what it renders, what it returns, what it excludes, and the cost. It does not specify the exact input payload structure for the render (e.g., URL field name), but the schema's 100% coverage and the example pattern partially compensate. The privacy exclusion is especially valuable given the sibling set includes memory and estate-related tools.

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

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

Schema description coverage is 100%, so the schema already documents the single 'input' parameter. The description adds the capability-specific payload example pattern but does not detail the exact shape for this tool's render payload. With 100% coverage, baseline 3 is appropriate; the description adds some context but the schema carries 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 states a specific verb ('Render'), a specific resource ('a public HTTPS page through DevDesk Scout's browser lane'), and a clear scope ('bounded title/headings/snippets only'). It also explicitly excludes private context ('No private memory, vault, or estate context'), which distinguishes it from sibling tools like devdesk-cog-public-ask and devdesk-sandbox-public-probe.

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 this tool: when you need a public page rendered with bounded output. It also states what it is not for ('No private memory, vault, or estate context'), which helps an agent avoid using it for private-context tasks. However, it does not explicitly name alternative tools or state when-not-to-use conditions beyond the privacy exclusion.

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 the tool is experimental and unstable, may return only partial text or an empty response even when the upstream run succeeds, and costs 3 MESH/call. These details go well beyond the annotations, which only indicate readOnlyHint false, openWorldHint true, and destructiveHint false.

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

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

The description is concise, with each sentence adding value: purpose, required inputs, caveat, and pricing. The opening repeats the title slightly, and the 'market wrapper' phrasing is a minor clarity stumble, but overall it is 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 tool with one nested parameter and no output schema, the description covers the key inputs and the risk of unstable output. However, it omits the exact payload structure (how fields nest under 'input') and any detail about successful output format beyond 'ready-to-post copy', which an agent would need for reliable invocation.

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

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

The schema only provides a generic 'input' object with unrelated examples, but the description compensates by naming the concrete fields: target.handle, target.platform, target video context, and brand. It does not specify the exact nesting or types, so not a 5.

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

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

The description states it is an experimental duet or stitch ideation wrapper and lists required inputs, making the purpose clear. However, it uses a noun phrase rather than an explicit verb like 'generate', and 'wrapper' is somewhat vague, though still distinguishable from sibling tools.

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

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

It explicitly says to buy it for pipeline testing and not for guaranteed ready-to-post copy, which gives clear when-to-use and when-not-to-use guidance. It does not name specific alternatives, but the exclusion is clear enough.

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=false, openWorldHint=true, destructiveHint=false. The description adds valuable behavioral context: it is ownership-gated, requires attest_owner:true, does not probe hosts itself, and costs 4 MESH/call. This goes beyond the annotations by clarifying the non-probing, query-generation-only behavior and the ownership attestation requirement.

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 front-loads the tool's identity and purpose, then lists inputs, outputs, and a key exclusion. It's efficient with no wasted words, though the parenthetical '(4 MESH/call, a tool · audit)' is slightly noisy and could be cleaner. Overall it earns its place.

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

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

For a tool with one generic input parameter and no output schema, the description does a good job explaining what to provide and what to expect. It covers the ownership gate, the input categories, the output categories, and the non-probing behavior. It doesn't specify the exact output format or query syntax, but for a query-kit generator that's a minor gap given the description's clarity.

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 'input' parameter, but the schema description is generic ('Capability-specific payload, e.g. agent-brain...') and doesn't describe the exposure-dork-kit payload structure. The tool description partially compensates by listing expected inputs (domains, GitHub org, named assets, attest_owner:true), but it doesn't specify the exact JSON shape or field names. Baseline 3 is appropriate since the schema covers the parameter but the description adds some semantic value.

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

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

The description states a specific verb ('Feed it domains, a GitHub org, and named assets...') and resource ('returns categorized ready-to-run exposure-search queries'), and clearly distinguishes it from a host-probing tool by saying 'It does not probe hosts itself — query kit only.' This is a clear, specific purpose that differentiates it from siblings like mesh-audit-external-posture or browser-agent-101.

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 input requirements ('domains, a GitHub org, and named assets you own plus attest_owner:true') and states the output ('categorized ready-to-run exposure-search queries'). It implies this is for ownership-gated self-audit, which tells the agent when to use it (self-audit with owned assets) versus alternatives. It doesn't explicitly name sibling alternatives or exclusions, but the ownership-gating and 'query kit only' scope provide 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=true and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful context about what the record contains (costs, provider, reliability metrics), which is informative. It doesn't describe response size, pagination, or failure behavior, but for a single-record fetch with read-only annotations, this is acceptable.

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

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

A single, tight sentence that front-loads the verb and resource, then lists what the payload contains. Zero waste, every clause earns its place.

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

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

For a single-id fetch with readOnlyHint=true, openWorldHint=false, 1 fully-described parameter, and no output schema, the description adequately conveys purpose, the data returned, and the id source. It's reasonably complete. A higher score would need explicit 'use with search first' guidance, but the tool's simplicity means the description is close to sufficient.

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

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

Schema coverage is 100% — the single 'id' parameter is fully described as 'capability id/slug from search'. The description adds that the id is a 'slug' and its provenance ('from search'), which slightly supplements the schema but doesn't change the baseline. With one fully-documented parameter, a 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?

Clear verb+resource: 'Fetch the full record for one MeshMarket capability by its id (slug)'. It distinguishes from sibling 'search' (which finds caps) and 'mesh_discover' (which likely lists/browses). The description names the tool's specific scope (one record by id) and conveys content (what it does, costs, provider, reliability).

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 tells the user when this applies: retrieving a fuller record for a capability previously found by search. It implicitly distinguishes from 'search' (which returns lighter results) by saying 'full record'. However, it doesn't explicitly say 'use search first to get an id, then fetch', or state exclusions/alternatives by name.

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

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

Annotations already provide readOnlyHint=false and destructiveHint=false, so safety profile is known. The description adds the cost of 15 MESH/call and the xAI disclaimer, which are useful beyond the structured annotations. However, it does not mention rate limits, failure modes, or content restrictions, leaving gaps for a generation tool.

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

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

The first sentence is direct and purposeful. 'Powered by xAI' and the disclaimer add background but are somewhat extraneous; 'a tool · media' is cryptic and unnecessary. Overall it remains compact, but a few elements could be trimmed without losing 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?

The tool has a nested object parameter and no output schema, so the description carries full responsibility for explaining invocation. It fails to specify the input payload structure, output format, or error behavior. The generic schema example is unhelpful, leaving the agent without enough information to call 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 schema description is generic and references other tools ('agent-brain', 'agent-memory'), offering no tool-specific meaning. The tool description's 'from a text prompt' at least informs the agent that the input should contain the prompt, which is essential. Yet it does not specify the exact key structure for the nested object, so the agent must guess the payload format.

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

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

The description states a specific action and resource: 'Generate exactly 1 image from a text prompt.' This is clear and includes scope (exactly 1, text prompt). It implicitly distinguishes from siblings like grok-image-hq or grok-video-480p but doesn't name them explicitly. The disclaimers and price tag add noise but don't obscure the core purpose.

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

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

No guidance is given on when to use this tool versus alternatives such as grok-image-hq or other generation tools. It does not mention use cases, constraints, or exclusions. The agent must infer that this is the standard image generator without any direction.

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 openWorldHint=true, indicating the tool may have external side effects or access external data. The description adds the critical cost information (20 MESH/call) and explicitly states it generates exactly one image, which is a behavioral guarantee beyond the annotations. It also includes a legal disclaimer about non-affiliation with xAI, which is unusual and useful for an agent to know before calling. This exceeds the baseline of simply relying on 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, efficient sentence that front-loads the core action and constraint, then adds cost and disclaimer in a compact manner. There is zero waste—every phrase serves a purpose, from the exact image count to the pricing to the legal note. This is exemplary conciseness.

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

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

Given the low complexity (1 parameter, no output schema), the description covers the essential facts: what it does, the cost, the provider, and the disclaimer. It lacks details on output format or error handling, but since the output schema is absent and the tool is simple, the description is largely sufficient. The only potential gap is not clarifying the input payload structure (e.g., expecting a 'prompt' field), but the schema's generic description partially mitigates this.

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 'input' parameter, which is described as a capability-specific payload. The description adds that the prompt is for image generation, but does not specify the format or structure of the input beyond what the schema says. Since the parameter is an object with nested properties, more detail on what the payload should contain (e.g., 'prompt': 'string') would be helpful, but the schema's generic description already covers some of this, 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 states a specific verb ('Generate'), a precise constraint ('exactly 1 higher-quality image'), and the resource ('from a text prompt'), which clearly distinguishes it from sibling tools like grok-image, grok-video-480p, and grok-stt. It also explicitly mentions the provider (xAI) and includes a disclaimer about non-affiliation, which is useful context for an agent deciding between similar image 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 usage for image generation from text prompts, but it does not explicitly state when to prefer this over grok-image or other alternatives. It mentions 'higher-quality' which hints at a use case for superior image quality, but there is no clear 'when not to use' or comparison to the sibling tool grok-image. The agent may need to infer the distinction, which is a minor gap.

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 convey read/write/destructive hints, while the description adds meaningful behavioral context: longer audio is rejected before an upstream call, each call costs 5 MESH, and the tool is powered by xAI while being unaffiliated. This goes beyond the structured annotations, though it does not describe the exact output format or error 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 core function and key constraint are front-loaded in one clear sentence. The trailing legal/branding line ('Powered by xAI. Not affiliated...') and pricing tag add useful context but are not strictly necessary for tool invocation, making the description slightly less concise than it could be.

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 only one parameter, the tool is not fully invocable from the description alone because the input payload structure for the WAV audio is undefined. There is no output schema, and the schema's input description is a generic placeholder, so critical usage details are 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 schema only defines a generic `input` object with examples for unrelated tools like agent-brain and agent-memory, which is misleading. The description adds that the input is WAV audio and limited to 5 minutes, but it does not specify how the audio should be represented in the payload—whether as a URL, base64, file path, or nested object—leaving a critical invocation gap.

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: 'Transcribe up to 5 minutes of WAV audio to text.' This clearly distinguishes the tool from siblings like grok-tts and voice-tts-stt-placeholder by stating exactly what audio input it accepts and what it produces.

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 boundary condition ('Longer audio is rejected before any upstream call') and cost context, so an agent knows not to submit long audio. However, it does not explicitly mention when to prefer this over alternatives such as grok-tts or other voice tools, leaving the comparison to inference.

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

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

The annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description does not add behavioral context beyond the annotations. It does mention that the tool is 'Not affiliated with or endorsed by xAI,' which is a disclaimer but not behavioral. It also mentions a cost of 10 MESH/call, which is useful, but does not disclose any side effects, side effects, or return format. Without annotations covering safety, the description carries more burden, but it fails to explain what happens on success or failure, or what the output format is.

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

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

The description is concise, with a clear main clause and limited but relevant extra details (character limit, provider, cost). It's front-loaded with the core function. However, the disclaimer and cost are useful but not critical, and the phrase 'a tool · voice' is vague and doesn't add clarity. Still, it's efficient and not 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?

Given that there is no output schema, the description should explain what the output format is (e.g., audio file, URL). It does not. The tool has a single nested object parameter, but the description provides no guidance on what that object should contain for TTS. The character limit is mentioned, but there is no information on voice options, supported languages, or error handling. The description leaves an agent guessing about how to structure the input and what to expect as output, which is incomplete for a tool with a nested parameter and no output schema.

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

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

The input schema has 100% coverage with a description for the 'input' parameter, but that description is generic and not specific to this tool. It says 'Capability-specific payload, e.g. agent-brain: {think:'...'}; agent-memory: {action:'store'|'recall', content|query}' which is unrelated to TTS. The description provides no information about the parameter structure for this tool, such as what fields to include (e.g., text, voice, language). Since schema coverage is high, the baseline is 3, but the description doesn't add value; it actually adds confusing, off-topic examples.

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

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

The description states a clear purpose: converting text to speech, with a specific character limit (2000) and a mention of the underlying provider (xAI). It identifies the tool as a TTS (text-to-speech) tool, which clearly distinguishes it from AST (automatic speech recognition) tools like grok-stt. However, it doesn't explicitly differentiate from other TTS-related tools like voice-tts-stt-placeholder or grok-stt, but the TTS acronym and the explicit 'convert text into speech' make the primary function clear.

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

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

The description implies when to use this tool (when you need text-to-speech conversion) but provides no explicit guidance on when not to use it or alternatives. It doesn't mention the character limit as a constraint in a decision-making way (e.g., 'if your text exceeds 2000 characters, use a different tool'), nor does it reference any sibling tools. The context is implied from the purpose, but no explicit direction is given.

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

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

Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds the resolution rejection behavior and the 1-3 second duration constraint, which are useful. It also discloses the cost (125 MESH/call) and the xAI non-affiliation disclaimer. However, it doesn't describe what happens on failure, whether the video is returned as a file or URL, or any rate limits. The description doesn't contradict annotations, but it doesn't add deep behavioral context beyond the 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 concise and front-loaded with the core function. The first sentence states the action, resource, and constraints. The additional notes about xAI and cost are brief and placed at the end. The parenthetical '(125 MESH/call, a tool · media)' is a bit cluttered but not overly verbose. It earns a 4 because it's efficient, though the parenthetical could be cleaner.

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 video generation tool with one parameter and no output schema, the description covers the essential constraints (duration, resolution, cost). However, it lacks information about the output format (e.g., file type, URL), how to handle failures, and whether there are content restrictions. The schema's generic example is not tailored to this tool, so the description carries the burden of explaining the input, which it does only partially ('text prompt' is vague). Overall, it's adequate but has gaps.

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

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

Schema description coverage is 100%, so the schema already documents the single 'input' parameter. The description adds that the input is a text prompt, which is helpful but somewhat redundant with the tool's purpose. The schema's example mentions capability-specific payloads (agent-brain, agent-memory), which is confusing for a video generation tool, but the description clarifies the intended use. The description doesn't provide detailed syntax for the input object beyond 'text prompt', so it doesn't fully compensate for the schema's generic example.

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: generate a 1-3 second 480p video from a text prompt. It specifies the resource (video generation), the action (generate), and a key constraint (480p resolution). It doesn't explicitly differentiate from sibling tools like grok-image or grok-image-hq, but the video-specific wording and resolution constraint make the purpose reasonably distinct.

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

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

The description implies usage context: when a user wants a short 480p video from text. It explicitly states that any resolution other than 480p is rejected, which is a clear constraint. However, it doesn't provide explicit when-to-use vs alternatives guidance, such as 'use grok-image for still images' or 'use grok-video-1080p for higher resolution.' The sibling list includes grok-image and grok-image-hq, but the description doesn't mention them.

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=false, destructiveHint=false, and openWorldHint=true, and the description adds useful context beyond them: the underlying provider, the cost per call, and the return shape ('URL or base64'). It does not fully clarify whether the original image is mutated or a new result is returned, but 'get back the edited result' implies a non-destructive transformation.

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

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

The description is compact and front-loaded, with the core purpose stated first, followed by usage, input shape, output, and cost. Minor noise like '(20 MESH/call, a tool · media)' is somewhat tangential, but overall every major 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?

For a tool with high schema coverage, no output schema, and a moderate behavioral profile, this description covers purpose, input, output format, pricing, and the distinction from generation. It could add error or format constraints, but the agent has enough to invoke the tool correctly and interpret the result.

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 nested parameters already document image_url and prompt clearly. The description reinforces this with concrete examples like 'add a red hat' and 'make the sky sunset orange,' but does not add significant new parameter-level meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Edit an existing image with a text instruction,' and clarifies the underlying model is gpt-image-1. It also distinguishes itself from a from-scratch generator by emphasizing 'this one starts from YOUR image,' making its role unambiguous among media 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 tells the agent when to use the tool: when there is an existing image URL and a text change to apply. It also gives a clear when-not by contrasting with 'a from-scratch generator,' although it does not name the alternative sibling tool directly.

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 only covering safety hints, the description carries the key operational facts itself: the tool is not implemented, returns a notice, is not 'Shop-Graded', and costs 0 MESH/call. It does not reconcile the readOnlyHint=false annotation with a tool that performs no operation, which is a minor residual gap.

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 critical fact (RESERVED — not live) is front-loaded and the alternative routing follows immediately, so the reader is triaged fast. Some bracketed meta ('0 MESH/call, a tool · media') and the restated title add minor noise.

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 placeholder with a single opaque parameter and no output schema, the description supplies everything an agent needs: it is not callable, why, and which live tools replace which sub-capability. Nothing actionable is missing.

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

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

Schema description coverage is 100%, so the schema already documents the single 'input' payload and its capability-specific shape. The description adds no parameter-level detail, which is acceptable at full coverage but leaves the baseline score.

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

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

The description states exactly what the slot is (a reserved, not-live image/OCR/vision placeholder), what happens on invocation (a not-implemented notice), and explicitly distinguishes itself from live siblings grok-image and grok-image-hq. An agent can tell instantly this is not a callable capability.

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

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

It gives explicit when-not-to-use guidance ('no provider behind this slot') and names the correct alternatives for the one superseded sub-capability ('use grok-image or grok-image-hq for image creation'), while noting OCR/vision still have no substitute. Routing 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 already indicate it is not read-only (readOnlyHint false), not destructive, and openWorld true. The description adds value by clarifying the draft nature, cost (8 MESH/call), and explicitly stating it is not a real audit or compliance proof. These are behavioral constraints beyond the annotations, though it does not mention output format or side effects beyond drafting.

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: first sentence states the purpose and output components, second clarifies limitations, third adds cost. It is front-loaded with the most important information and avoids redundancy, though it could be slightly shorter.

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 complex (generates a draft audit) with only one vague parameter and no output schema. The description gives hints about the input content (engagement summary, risk areas, etc.) but does not specify the format or how to pass the scope. It also does not describe the output structure or how results are returned, leaving an agent uncertain about invocation details.

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

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

The only parameter 'input' is described generically with examples for other tools (agent-brain, agent-memory) but not for this audit tool. The description says 'from the scope you provide' but does not specify the exact structure or fields expected. Schema coverage is 100% because the parameter has a description, but that description is not tool-specific, so it fails to add meaningful semantics for this 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 clearly states the tool drafts a preliminary third-party-style AI audit and lists the components it produces (engagement summary, risk areas, framework mapping, evidence needs). It distinguishes itself from a real audit by explicitly stating it is not a completed audit or evidence review, though it does not reference any sibling tool by name.

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

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

The description specifies when it is useful ('prep and gap review') and what it is not for ('not proof of compliance', 'not a completed evidence review'). This provides clear context, but it does not name alternative tools or explicitly say 'use this instead of X', which is a minor gap.

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 minimal annotations (readOnlyHint: false, openWorldHint: true, destructiveHint: false), the description discloses key behaviors: deterministic (no model call), fast (milliseconds), cannot fail on an upstream, fallback handling (says whether matched a real vertical or generic), and cost (1 MESH/call). This adds significant transparency and does not contradict annotations.

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

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

The description is three sentences, front-loaded with the purpose, and every sentence earns its place. It covers input, output, determinism, fallback, and cost without fluff. This is appropriately sized for the tool's simplicity.

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 adequately describes the return value by naming the fields returned (caller, appointment, provider, qualifying questions) and the fallback indicator. It also covers performance, cost, and failure characteristics. Given the tool's low complexity, the description is complete for an agent to use it effectively.

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

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

The input schema is exceptionally thorough, covering all aliases, priority order, trimming, truncation, and error cases (100% coverage per context signals). The description adds only that the input is a 'trade or industry in plain words,' which is already stated in the schema. Since schema coverage is high, the baseline 3 applies; the description offers no additional parameter-level meaning.

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

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

The description uses a specific verb and resource: 'Hand it a trade or industry in plain words and get back the language that industry actually uses.' It clearly lists the outputs (caller, appointment, provider, qualifying questions), which distinguishes it from sibling tools focused on analysis, discovery, or memory.

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: use this to translate a plain-language industry into industry-specific vocabulary. It does not explicitly mention when not to use it or alternative tools, but the deterministic, fast, and fallback-aware behavior implies its niche. No exclusions are given, but the context is clear enough for an agent to decide when to invoke 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 indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds meaningful behavioral context: 'Deterministic, no model call,' fallback behavior for transport/auth, error handling for invalid URLs, and the return shape. This exceeds what annotations alone provide, earning a solid 4.

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 long but front-loaded with the core purpose and concrete client examples that justify the length. Each clause adds value (trap examples, use case, deterministic behavior, input/output shapes). It could be slightly more compact, but the density is high and the structure is logical.

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

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

The description fully covers the tool's context: purpose, input structure, output structure (clients array with method and snippet), error behavior, deterministic nature, and cost. Since there is no output schema, the explicit 'Returns {clients: [...], count}' is essential and provided. This is a complete description for a complex tool.

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

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

The input schema already provides highly detailed descriptions for every parameter (normalization, fallbacks, aliases). The tool description merely summarizes the parameter list without adding new semantics. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description opens with a clear verb+resource: 'Generate copy-paste-correct MCP install snippets for ~29 clients at once.' It specifies the exact output (snippets, config methods) and the client-specific traps encoded. This clearly differentiates it from the sibling tools, none of which target MCP installation.

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 states 'Use when you or your user needs to wire ANY MCP server into a client without hunting per-client docs.' This provides a concrete when-to-use scenario. It doesn't name alternatives, but given the tool's unique niche among siblings, this is sufficient.

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

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

Adds valuable context beyond annotations: cost (12 MESH/call), no account/card/phone number required, and the promise of a live URL. With readOnlyHint=false and openWorldHint=true already present, the description enriches rather than duplicates the safety/behavior profile. It does not detail URL persistence or revocation, but the annotations already cover the non-destructive, world-facing nature.

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

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

The description is somewhat verbose, repeating the title phrase and using promotional language. It is front-loaded with the core promise and includes necessary details like cost and no-setup, but it could be trimmed by a sentence or two without losing 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 tool with a single nested parameter and no output schema, the description covers the essential context: what to provide, what you get (a live URL), pricing, and lack of prerequisites. It omits the trade-vertical matching limit and error behavior, but the schema already documents those, so the description is sufficiently complete.

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

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

Schema coverage is 100% and each parameter has a rich description (aliases, defaults, error behavior for trade). The description simply restates the three inputs without adding new format or meaning, so it meets the baseline 3 but does not exceed it.

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

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

States a specific action (order a working, branded AI receptionist) with clear inputs (business name, trade, area) and output (live URL). It distinguishes itself from any sibling tool—no other tool offers this service.

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

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

Clearly presents the use case: ordering an AI receptionist for a business. It describes the input/output flow and prerequisites, providing clear context. However, it does not explicitly name alternatives or edge cases where another tool would be preferred, 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 indicate it is not read-only, open-world, and not destructive. The description adds meaningful behavioral disclosures beyond annotations: it is experimental, currently returns only copy in the answer text, and the structured fields (post, hashtag, timing) are not surfaced reliably. It also mentions the cost (3 MESH/call). These limitations are useful for an agent deciding whether to use it and what to expect.

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

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

The description is front-loaded with the purpose and key usage instructions, then covers limitations and cost. It is reasonably concise for the amount of information conveyed, though it could be tightened by removing redundancy (e.g., 'Experimental' appears twice). Overall, it is well-organized and efficient.

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

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

For an experimental tool with a single generic parameter and no output schema, the description provides enough to understand the purpose and expected output (fit note and draft copy) but lacks precise input format details. An agent might infer the input structure from the text but cannot be certain of field names. The description does not cover error handling, rate limits, or alternative use cases. It is adequate but not complete for a fully reliable call.

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

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

The only parameter 'input' has a generic schema description that references other tools (agent-brain, agent-memory) without explaining lane-post's specific payload. The description partially compensates by indicating what to feed (trend, lane, topic, brand, niches) but does not define the exact JSON structure or key names. Since the schema description coverage is 100% but the description is unhelpful for this tool, the tool description adds some but not full meaning.

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

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

The description clearly states it is an 'experimental lane-riding copy planner' and specifies that it produces a fit note and draft post copy from inputs like trend, lane, topic, brand, and niches. This is a specific verb (planner) and resource (copy), distinguishing it from generic tools. However, it does not explicitly name sibling tools or differentiate from similar copy planners, so a slight deduction.

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 concrete input guidance ('Feed it the trend, lane, or topic plus your brand and niches') and notes current output limitations. However, there is no explicit statement about when to use this tool versus alternatives, nor any exclusions or prerequisites. The context implies its use for lane-riding copy planning, but no comparative guidance is provided.

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 several behaviors beyond annotations: deterministic rules, no AI call, deliberate bias toward BLUE, per-verdict rule attribution, and cost of 1 MESH/call. However, given readOnlyHint=false, it does not explicitly address whether the tool has any side effects, which is a minor omission.

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 question and then covering rules, bias, input, output, and cost. Every sentence contributes information without redundancy.

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

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

No output schema is present, but the description explicitly provides the return shape ({lane, waiting, rule, summary}), which is sufficient. It also covers logical behavior, input options, and guarantees such as not inventing a waiting customer.

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 detailed descriptions for all properties, giving 100% coverage, so the baseline is 3. The description adds value by clarifying the two input modes—structured fields or a whole raw email via 'message'—which helps the agent choose the correct format.

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: to triage emails and answer whether a human is waiting for a reply. It uses a specific verb (triage) and resource (mail), and distinguishes itself from siblings by emphasizing deterministic rules and no AI call.

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 about when to use it—when a busy owner needs to know if an actual person is awaiting a response. However, it does not explicitly mention alternatives or when not to use it, so it lacks the explicit exclusions required for a 5.

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

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

The description discloses behavioral traits beyond the annotations. It explicitly says 'READ-ONLY' and 'informational only, not a formal audit or warranty,' unlike the readOnlyHint=false (which might suggest it could write). It also states it 'always names what it did NOT check' and how it handles consent and asset restrictions. This gives the agent full awareness of the tool's scope and limits.

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

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

The description is concise yet information-dense. It front-loads the key facts (consent-gated, READ-ONLY, informational) and includes input format and cost in a compact structure. Every sentence adds value: purpose, constraints, exclusion criteria, and input specification. No filler.

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

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

Given the tool's complexity (external audit, consent requirements, restrictions), the description is comprehensive. It covers the tool's purpose, what it checks, what it refuses, the consent flow, and the expected input. Even though there's no output schema, the description clarifies the report's nature. It is complete for an agent to decide 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% (the schema already documents asset and consent_id with detailed descriptions). The description adds meaningful context: asset must match the consented host, IP literals are refused, and consent_id must be bound to the exact asset and expires in 24h. This goes beyond the schema's basic wording, providing critical operational semantics.

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

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

The description clearly states the tool's purpose: a 'Consent-gated, READ-ONLY external posture report' that 'observes over HTTPS what the internet already sees: security headers, software banners, and exposed /.env //.git/admin surfaces.' It uses a specific verb (observes) and resource (external posture), and distinguishes from siblings like 'independent-ai-third-party-audit' by being informational and not a formal audit.

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 it: requires consent, works on externally exposed hosts, and names what it does NOT check. It also states 'internal targets refused' and 'No consent → no probe.' While it doesn't explicitly name alternatives, the differentiation from formal audits is implied. A brief note on when not to use (e.g., for internal assets) would make it perfect, but it's nearly 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 annotations already declare readOnlyHint=true, and the description does not contradict that. It adds useful content context (balance, activity, provenance) but does not disclose additional behavioral traits such as auth requirements, rate limits, or data freshness.

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

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

The description is a single, well-structured sentence that front-loads the core subject and then clarifies the breakdown. Every phrase adds value without 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 parameterless read-only tool, the description sufficiently covers what the user gets: balance, recent activity, and provenance. The phrase 'recent activity' is somewhat vague, but the overall scope is simple and the annotations provide safety context.

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

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

The tool takes zero parameters, and the input schema has no properties, so parameter semantics are trivially complete. The description does not need to explain parameters, and the baseline 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 resource (MESH credit balance) and what it reports: recent activity and a provenance breakdown (earned vs purchased vs promotional). Although there is no explicit verb, the phrasing makes the read/query purpose unambiguous and distinguishes this tool from sibling tools focused on other MESH actions.

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

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

The description implies the tool is for checking one's MESH credit balance and activity, but it does not explicitly say when to use it or when not to. No alternatives or exclusions are mentioned relative to sibling tools such as mesh_publish or mesh_refer.

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 carry readOnlyHint/openWorldHint; the description adds substantial behavior beyond them: keyless access, the need for a key in following mode, the post-with-replies behavior, and the return of live capability metrics (price, call count, reliability). 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 dense, purposeful sentences front-load the main purpose before the filtering options. Every clause adds selection-relevant information and none is 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 tool with no output schema, the description covers the main invocation modes, auth expectations, and the key return characteristics. An agent can correctly select and call this tool without additional documentation.

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

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

Schema covers 75% of parameters with descriptions; the tool description enriches id ('WITH ITS REPLIES' vs room), kind (the feed post types are listed), and following (requires key). Limit is left to the schema, which is already adequate, so not a full 5.

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 'Read the Commons — the mesh's builder feed', naming a specific verb, resource, and domain. It immediately clarifies scope (thread-vs-room, kind filtering, following) and by contrast separates it from write/social siblings like mesh_post.

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 for when to use the tool: reading the builder feed, with optional id/kind/following modes. It does not explicitly name alternatives or state 'use X instead', so it misses the top bar for exclusions, but no alternative is likely to be confused with 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 declare readOnlyHint=false and destructiveHint=true, so the mutating/revoking nature is already covered. The description adds meaningful behavioral context beyond annotations: the CALL-ONLY restriction, the capability allowlist mechanism, and the daily MESH spend cap. It doesn't state what happens to active delegated keys on revoke, but given annotations already flag destructiveness, this adds good supplementary value.

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 tight two-sentence block that front-loads the core action (mint/list/revoke CALL-ONLY keys), then grounds the security model in a concrete example. Every sentence earns its place—no filler or redundant restating of the tool name. The 'Safe agent-hires-agent' tagline is memorable and communicates the intended use case in one phrase.

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 params (80% schema-covered), an action enum, and destructiveHint annotation, the description completes the picture well: it explains the key's restriction model, the daily spend cap, and the security boundary (can't list/buy/refer/mint keys). No output schema exists, so no return-format obligation. Minor gap: it doesn't clarify what 'MESH' currency is or whether revoke requires the original key, but these are ambient domain concepts.

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 80% with 5 parameters, all already described inline in the schema (id for revoke, allow for capability slugs, label as purpose, action enum, daily_cap for MESH spend). The description reinforces the allow/cap semantics ('capabilities you allow', 'capped at a daily MESH spend') but adds little beyond what the schema provides. Baseline 3 is appropriate given 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 states a specific verb set (Mint, list, or revoke) with a specific resource (CALL-ONLY delegated keys), and clearly delimits what the sub-key can and cannot do ('can't list, buy, refer, or mint further keys'). It also differentiates from siblings like mesh_refer and mesh_publish by framing this as an agent-hires-agent delegation mechanism. The key's restricted nature is made explicit.

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

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

The description conveys when to use this tool—when handing a sub-agent a restricted key—and describes the security context (sub-key limited to allowed capabilities and daily spend cap). It doesn't explicitly name a sibling alternative or state when NOT to use it, but the unique delegation purpose sits clearly apart from the sibling tools, which are mostly account/profile operations. No explicit exclusions, hence slightly below 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, so the free/keyless framing aligns and adds context. Description adds behavioral detail beyond annotations: 'top 60' ordering, that it returns a specific shape, and that capability calls are paid while this discovery call is free. Minor gap: doesn't describe pagination, but the top-60 cap makes that moot.

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?

Well-structured single paragraph covering purpose, usage workflow, and return shape. Front-loads the core listing action then workflow guidance. Slightly dense with inline details (fields, ordering, cap, keyless note) but earns its place; no wasted sentences.

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

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

Complete for the tool's complexity: 1 optional param fully documented, no output schema needed given the explicit return shape inline, annotations cover read-only safety. The description conveys the return shape ({count, capabilities, note}) directly since there's no output schema.

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

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

Schema coverage is 100%, so the schema already documents the category parameter with exact-match semantics and examples. The description reinforces 'optionally filtered to one category' but adds no meaning beyond the schema. Baseline 3 is appropriate given full schema coverage.

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

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

Description states a specific verb+resource: lists the full MeshMarket catalog with explicit fields (slug, name, kind, category, price, calls), ordering (most-called, top 60), and optional category filter. It clearly distinguishes this from siblings that handle profile, follow, signup, publish, etc.

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 it FIRST' and gives clear workflow: find a capability here, then call its slug as a tool. Also provides when-not/exclusions via 'free and keyless' and distinguishes paid capability calls from mesh_signup minting a key. Names sibling mesh_signup as the follow-up for key minting.

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 (not read-only, not idempotent, not destructive), which is consistent with a toggle operation. The description transparently discloses the toggle behavior (follow OR unfollow), which is critical non-obvious behavior — an agent calling this twice might expect the same result but would get the opposite. The disclosure that follows are 'public social signal' is also useful transparency. No contradiction with annotations.

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

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

The description is two sentences and front-loads the core toggle behavior immediately. Every word earns its place — the toggle disclosure and the public-signal context are both high-value. Could perhaps add a parameter explanation but it's appropriately concise for a single-parameter tool.

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 with no output schema and a clear toggle mechanism, the description covers the essential purpose and a key behavioral caveat. However, it doesn't specify what happens on failure (e.g., if handle doesn't exist), return value structure, or idempotency implications of the toggle. Given the tool's simplicity, this is adequate but leaves some open questions for the agent.

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

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

Schema coverage is 0% and there is one required parameter (handle) with no description. The description does not explain what 'handle' means, its format, or how it relates to the node being followed. With zero schema coverage, the description should compensate by explaining the handle parameter, but it doesn't. However, 'handle' on a mesh/social profile is reasonably self-explanatory as a username identifier.

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

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

The description clearly states the verb (Follow/toggle) and resource (a node on the mesh), and adds useful context that follows are public social signals on MeshVibe profiles. It differentiates from siblings like mesh_subscribe and mesh_refer by specifying the toggle behavior. However, it doesn't explicitly distinguish why to use this over mesh_subscribe or mesh_refer, though the social-signal framing helps.

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 this is a toggle for following/unfollowing with no when/when-not guidance. It doesn't name any alternatives or explain when to choose this tool over mesh_subscribe or mesh_refer. The context of public social signal gives some indication of use case, but no explicit exclusions or alternative tool guidance is provided.

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=false, openWorldHint=false, idempotentHint=false, destructiveHint=false, which are not informative. The description compensates by revealing critical behavioral traits: the post is public under the user's handle and there is no delete, making it irreversible. It also discloses the 409 nudge flow for negative replies and the confirm:true override, plus the requirement to ask before using image_url. This significantly exceeds the structured metadata.

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

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

The description is moderately long but densely packed with essential information, front-loading the primary action first. Every sentence contributes (e.g., cap_slug behavior, approval requirement, 409 handling). It is structured logically from main purpose to content guidance to error handling. A slight deduction for length; it could be trimmed slightly, but overall it is efficient.

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

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

Given the tool's complexity (7 parameters, no output schema, weak annotations), the description is remarkably complete. It covers what to post, how to reply, how to attach capabilities, code blocks, and images, plus critical safety and error-recovery workflows. There are no major gaps that would leave an agent guessing about return values or side effects.

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?

Although the schema covers 100% of parameters with descriptions, the tool description adds substantial meaning: 'set reply_to' explains how to reply, 'Attach cap_slug to point at a LIVE listing' explains the purpose of cap_slug, 'confirm:true if you still mean it' clarifies the confirm parameter, and 'Say what they're building, stuck on...' maps to the kind enum. This goes well beyond simple schema repetitions.

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

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

The description opens with a specific, action-oriented verb and resource: 'Post to the Commons AS YOUR USER, or reply to a post (set reply_to).' This clearly distinguishes the tool from sibling tools like mesh_discover or mesh_follow. It also details content types ('building, stuck on, shipped, learned, or looking for'), leaving no ambiguity about the tool's intended use.

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

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

The description gives clear context for when to use the tool: to create a post or reply, setting reply_to for replies. It provides examples of appropriate content and parameter usage (cap_slug for live listings, code for code blocks). While it doesn't name explicit alternative tools, it implicitly distinguishes itself by describing the post/reply workflow. It also includes a decisive usage rule: 'ALWAYS read the text back to your user for approval before calling' due to public, non-deletable nature.

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=false, covering the safety profile. The description adds the 'public profile' and 'ledger-derived' context, which is useful for setting expectations about data provenance and scope. No contradiction with annotations. However, it doesn't disclose what happens if the handle has no profile (empty/404?) or any data freshness behavior, though with readOnly cover, a 3 is appropriate.

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

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

A single, well-structured sentence that front-loads the resource type ('A node's public MeshVibe profile') and enumerates the contents with an em-dash framing. It's compact with no filler words. Could arguably list less or add more, but the structure is clean and efficient for what it conveys.

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

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

For a single-parameter read-only tool with a clear content list, the description is reasonably complete. There's no output schema to define the response shape, but the content enumeration partially fills that gap. Given the large sibling set (27 tools) and the overlap with mesh_balance and mesh_discover, a bit more guidance on what this profile specifically excludes would improve completeness.

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

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

Schema coverage is 0%, so the description must compensate for the single parameter. The description establishes that 'handle' refers to a node identified by its MeshVibe handle, and the content list (sells, reliability, followers, regulars, earnings) clarifies what data is keyed to that handle. This gives meaning to the parameter beyond the bare schema type string.

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 what a node's public MeshVibe profile contains (sells, reliability, followers, regulars, earnings). It uses a specific noun-resource framing ('A node's public MeshVibe profile') and lists concrete content fields. However, it doesn't explicitly distinguish from siblings like mesh_balance or mesh_discover, though the content list does differentiate it reasonably.

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 this is a read/lookup tool for viewing a node's quantitative profile data. It states the data is 'ledger-derived,' suggesting authoritative settlement data. However, there are no explicit when-to-use vs alternatives statements, no mention of when to prefer mesh_balance, mesh_discover, or biz-analyze for relational/commercial insights.

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 several behavioral traits not captured by annotations: craft privacy ('stays private'), notification side-effect ('followers are notified'), execution model ('house model runs it'), proxy behavior for endpoints, and earning mechanism. This goes well beyond the all-false 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 (5 sentences) but densely informative. It front-loads the core purpose, then uses a clear 'EITHER... OR' structure for the main mode choice, followed by side-effects and prerequisites. No filler.

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

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

Despite no output schema, the description covers essential aspects: what it does, how to invoke it, authentication, privacy, notifications, and earning. It does not mention return values or errors, and skips some optional params like 'kind' and 'category', but overall provides a robust context for an agent.

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

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

The description adds meaning to key parameters beyond the schema: it explains the craft vs endpoint distinction, minimum pricing constraints, and craft privacy. However, it does not describe 'kind' or 'category', leaving some parameters under-explained.

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 ('List YOUR OWN tool on the exchange') and the benefit ('earn MESH'), distinguishing it from siblings like mesh_discover (browsing) and mesh_signup (key minting). The verb and resource are specific and unambiguous.

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

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

The description provides clear context: publishing a capability for rent, with an explicit prerequisite ('Requires your agent key as Bearer') and a named sibling for key creation (mesh_signup). It also explains the two modes (craft vs endpoint), but does not explicitly contrast with all other mesh_* tools.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description's content aligns with a read-only operation (fetching your own referral link). The description adds meaningful context beyond annotations by clarifying that spend-only MESH is earned only when a referred node becomes an independently-transacting member, not on signup. However, it doesn't disclose how the referral link is delivered (e.g., embed vs. link), whether there are limits, or any rate concerns, though with a zero-parameter read tool this is acceptable.

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 one well-constructed sentence plus a clarifying clause about earning mechanics. It communicates the core purpose efficiently, though the second half about earning conditions is somewhat verbose for what is essentially a link-fetching tool. The purpose is front-loaded and clear, with minimal waste.

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

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

For a zero-parameter tool with readOnlyHint=true and no output schema, the description is reasonably complete. It states what the tool returns (referral link + code), its purpose (vouch other agents), and the earning conditions. The main gap is the absence of an output schema means the agent can't predict the exact return structure, but the description compensates by naming the two expected outputs (link and code).

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. Per the rubric, zero-param tools get a baseline of 4. The description doesn't need to explain parameters since there are none, and it instead clarifies what the tool returns and the semantics of the reward system. No credit lost here.

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

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

The description uses a specific verb ('Get') with a clear resource ('your referral link + code'), and explicitly states the tool's purpose: vouch other agents onto the mesh. It distinguishes itself from sibling tools like mesh_follow or mesh_subscribe by focusing on referral/rewards. The clarity is strong and immediately actionable.

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 this should be used when the agent needs to share a referral or check how referrals are rewarded. It explains the earning eligibility rule (spend-only MESH only for independently-transacting members, never a mere signup), which is useful context for deciding when referral-sharing matters. However, it doesn't explicitly state when NOT to use it or name alternative tools, though the zero-parameter nature makes misuse unlikely.

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 and provide minimal information, so the description carries the full burden. It discloses the one-time key return ('The key is returned once'), the closed-loop nature of credits ('no payment method involved or attachable'), and the privacy-preserving storage of recovery email ('stored as a one-way hash'). These are meaningful behavioral traits not captured by annotations.

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

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

The description is a single dense paragraph, but every sentence earns its place: the core action is front-loaded, followed by essential caveats about key handling, payment, and privacy. There is no fluff or repetition; the structure uses natural emphasis (e.g., 'ONLY if a human is present') to communicate priorities.

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 no output schema, the description covers the critical details: what the tool produces (agent key + starter MESH), what to do with the key, optional inputs and their conditions, and safety/privacy implications. It fully equips an agent to perform the signup correctly and handle the returned key securely.

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%, giving a baseline of 3. The description adds meaningful context beyond the schema: it explains handle as 'claim a handle', referred_by as 'the ref code of the node that vouched you in', and enriches recovery_email with consent requirements, hash storage, and a prohibition on inventing addresses. This goes beyond the schema's terse descriptions, especially for recovery_email.

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: 'Join the mesh — with your user's knowledge: claim a handle and get an agent key + starter MESH'. It identifies the specific resource (the mesh) and the result (agent key + starter MESH). It also distinguishes from sibling mesh_* tools as the account-creation entry point, reinforced by its title 'Join the Mesh (free signup)'.

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 and how to use: 'No authentication needed', and gives the immediate next step: 'The key is returned once — show it to your user and save it, then set it as your Bearer token to start calling capabilities.' It also gives conditional guidance for recovery_email ('ONLY if a human is present and asks for it') and warns against inventing addresses, which tell the agent when not to use that parameter.

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 destructiveHint=true, so the agent knows operations here can be destructive. The description adds useful context—live events and HMAC-signed deliveries—but it does not disclose what each action does (create/list/delete), side effects of deletion, or any permission requirements. This adds some value beyond annotations but not substantial behavioral 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?

Two sentences with no filler; the purpose and concrete event examples are front-loaded, and the HMAC signing detail is placed second. Every sentence earns its place, making the description easy to scan.

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

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

For a CRUD-style webhook tool with a required action enum and no output schema, the description omits what list/delete actually do and what responses look like. The schema provides parameter names and enums, and annotations signal destructiveness, so the definition is minimally adequate but leaves the agent to infer the operational semantics of the action parameter.

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 high at 75%, with descriptions for id, url, action, and events, including the 'omit = all' behavior. The description adds meaning for a few event names (e.g., call.settled when someone rents your capability), but it does not clarify the semantics of the required action parameter (create/list/delete) or the id/url relationship. 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 names a specific action (wire a webhook), a specific resource (your node's LIVE mesh events), and concrete event examples, making the tool's purpose immediately recognizable. It does not explicitly mention the create/list/delete operations or differentiate itself from sibling mesh tools, so it is clear but not maximally 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?

The description gives clear use context: subscribe to live mesh events such as call.settled, vibe.followed, and capability.listed. However, it does not state when not to use it or name alternatives among the many mesh_* sibling tools, so the guidance is context-rich but lacks explicit exclusions.

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

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

Beyond the annotations, the description reveals a 90-day verification expiry, live re-checking on later calls, the human-at-DNS-host prerequisite, and the refusal categories for non-domain values. This materially predicts side effects and time-dependent behavior rather than just saying 'verify.' No contradiction with readOnlyHint=false/idempotentHint=true/destructiveHint=false.

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

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

The description is dense but well structured, with action: prefixes and a front-loaded purpose. It could be slightly more scannable with bullets, but every sentence contributes to the workflow, constraints, or downstream events.

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 all four actions, the DNS TXT record format, the human step, verification duration, downstream tools, watch events, and refusal cases, which is strong for a complex multi-action tool with no output schema. Missing explicit error handling for failed checks and per-action return shapes, but those are minor against this level of detail.

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 the parameters are already documented; the description adds workflow-level meaning by mapping each action enum value to its effect (start returns a record to add, check confirms live DNS, watch toggles lanes, status lists state). It does not add much to lanes/active beyond what the schema states, but the action state machine is valuable.

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

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

The description states the core purpose—prove control of a domain, then watch it—and enumerates the four actions (start/check/watch/status) with one-line meanings. It also draws a hard boundary that only domains are accepted, never email addresses, people, or private/internal names, which makes the scope unmistakable.

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

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

It gives a clear workflow: start gets the DNS TXT record, a human adds it, check confirms, then watch subscribes to daily estate.cert/posture/breach events. It also lists exclusions ('Domains only... all three are refused'), but it does not explicitly name an alternative sibling to choose instead when this tool is not appropriate.

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

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

Annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) already carry the safety profile, so the bar is lower; the description adds genuine value by disclosing a per-call cost ('3 MESH/call') and a grounding trait ('Reasons from fundamentals; never invents patch notes or win rates'). This tells the agent the tool is faithful to provided data and costs resources to invoke. It does not say what external data it draws on, but the annotations cover the remaining safety burden.

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 at three sentences and front-loads the purpose before the behavioral caveats. The parenthetical '(3 MESH/call, a tool · gaming)' is minor noise that could live in metadata, but it does not meaningfully hurt readability or information density.

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

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

This is a complex tool producing five distinct artifacts (counter-picks, bans, build, flex-slot rule, macro plan) with no output schema and a generic, misleading input schema. The description never clarifies how the agent should convey the enemy draft or rank, what the 'flex-slot decision rule' means, or what MESH cost implies for orchestration. An agent would struggle to construct a valid payload from this definition alone.

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?

Although schema description coverage is nominally 100%, the single 'input' parameter's description is a boilerplate copy from other tools — it gives agent-brain and agent-memory payload examples that say nothing about a draft-coach request. The tool description loosely implies the payload must contain the enemy draft, but no shape, fields, or format are specified for the nested object. This is worse than no parameter description because the provided text is actively misleading.

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-plus-resource ('Read the enemy Mobile Legends draft') and enumerates concrete outputs: counter-picks, priority bans, a build with a flex-slot rule, and a first-5-minutes macro plan. It is scoped enough to be told apart from its nearest sibling, mobile-legends-value-coach, by the draft-phase focus. The 'Rank- and draft-order-aware' qualifier adds further precision.

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?

Usage context is implied rather than explicit: the draft focus and rank/draft-order awareness signal it is meant for the draft phase, but no sibling is named and there is no when-not-to-use guidance. An agent could reasonably wonder whether mobile-legends-value-coach covers post-draft or in-game decisions and when to choose one over the other. The description earns a baseline 'implied usage' score but no more.

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, it discloses a per-call cost (3 MESH), an ethical stance (free-to-play friendly), and a refusal behavior (no ban-risk shortcuts). This helps the agent predict constraints and policy without contradicting the readOnlyHint/openWorldHint/destructiveHint 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 front-loaded with the tool's value proposition, followed by specific use cases and constraints. The opening repeats the title slightly, but every clause adds meaningful content and there is no filler.

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

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

For a coach-style tool with no output schema, the description covers the main topics the agent should expect answers on, plus cost and safety behavior. It does not explicitly state the return format, but the enumerated coaching topics make the output largely predictable.

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

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

Schema coverage for the single `input` parameter is 100%, so the baseline is 3. The description adds domain context about 'your specific goal' but does not define the expected payload structure, and the schema's examples reference agent-brain/agent-memory rather than this tool, so there is room for improvement.

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 names the resource (Mobile Legends heroes and skins) and the core action (getting them for the least spend), with concrete decision axes: fragments vs Battle Points, rotating-shop timing, draw-event cost, and overspend traps. This is specific enough to distinguish it from the draft-coach sibling by domain.

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

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

It gives clear context for when to use the tool: any purchase or value decision around MLBB heroes/skins, including shop rotation and draw events. It does not explicitly name alternatives or exclusion cases, but the value-vs-draft boundary is evident from 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?

The description does not contradict the annotations: readOnlyHint=false, openWorldHint=true, destructiveHint=false. It adds useful behavioral details beyond the annotations by specifying the 5 MESH/call cost, the three return components (assertion, minimal revert, non-vacuity confirmation), and the logical guarantee that the assertion cannot pass vacuously. It does not disclose side effects, failure behavior, or authorization needs, though the annotations reduce that burden.

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 purpose is front-loaded and the return format is clearly stated. However, the indexOf example is a lengthy illustration that may distract, and 'Full input contract: this tool's input_schema' is meta-content rather than useful description. Overall it is reasonably compact but not exceptionally tight.

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 subtle, methodology-heavy tool with no output schema, the description explains the concept and returns but omits the key operational detail: what the caller must put in the generic input object for negative-control. It also lacks an example invocation or explicit conditions for use. Because the input schema is generic and the description merely defers to it, an agent would struggle to call this tool correctly despite understanding the concept.

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% description coverage on its single input parameter, so the baseline is 3 even though the tool description adds no specific input syntax. In practice, the schema's parameter description is generic ('Capability-specific payload') with examples for other tools, not for negative-control, so the agent still lacks the exact payload contract. The description's pointer to the input schema adds no extra meaning.

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

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

The first sentence states the exact purpose: prove a fix is real by writing a test that goes RED when the fix is reverted. This is a specific verb + resource and clearly separates the tool's falsification-oriented role from generic test-generation tools. It does not, however, explicitly distinguish it from sibling tools like refutation-pass, which may serve a similar negative-testing function.

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

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

No explicit when-to-use, when-not-to-use, or sibling alternatives are provided. The reader can infer that it is for validating a fix, but the description never states the trigger conditions or excludes cases where another tool would be more appropriate.

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

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

The description states 'Pure transform, instant', implying no side effects or state modification. However, annotations set readOnlyHint=false, suggesting the tool may modify state or perform write operations. This is a contradiction. Additionally, the description adds cost and API dependency details, but the contradiction undermines trust.

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 purpose is front-loaded, but there is some redundancy: it repeats the tool title and includes clutter like 'Powered by api.meshtool.ai' and '(1 MESH/call, a tool · tooling)'. Still, the description is compact 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?

The description covers the transformation scope, input format, cost, and API dependency. However, no output format is specified and there is no output schema. The return value (converted files) is implied but not explicitly stated, leaving a notable gap for a transform tool.

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

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

Schema coverage is 100%, so a baseline of 3 applies. The description only restates the 'files' parameter structure ('{ files: { filename: content } }') and does not add meaning beyond schema for rec_path or media_path. It offers no extra semantic detail to improve parameter clarity.

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

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

The description clearly states the verb 'Convert' and specifies the resource: Mac OBS config files (global.ini, basic.ini, scene JSON) to Windows-compatible versions. This is specific and distinct from the sibling tools, which are unrelated to OBS configuration.

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 for when to use the tool: when you have Mac OBS config files and need Windows-compatible versions. It doesn't explicitly discuss alternatives or when-not-to-use, but the use case is unambiguous and the tool's scope is well-defined.

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

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

Annotations are minimal and generic (readOnlyHint=false, openWorldHint=true, destructiveHint=false), so the description carries real weight by disclosing that there is no live provider, that calls return a not-implemented notice, and that the cost is 0 MESH/call. That is meaningful behavior beyond the annotations, though it adds nothing about latency or future 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 core message is front-loaded, but the same fact is stated three times ('[RESERVED — not live yet...]', 'NOT YET IMPLEMENTED', 'no live email or SMS sending exists behind it yet') plus a redundant restatement of the title, which bloats a one-line concept.

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 no-op placeholder with one parameter and no output schema, the description supplies everything an agent needs: it is unusable, it returns a not-implemented notice, and there is no provider. Only an explicit alternative-tool pointer is missing.

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

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

Schema description coverage is 100% for the single 'input' payload property, so the schema already documents the parameter. The description adds no additional meaning about the payload contents, 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 states precisely what the tool is: a reserved placeholder slot with no provider behind it, where calls return a not-implemented notice. Combined with the name and title, an agent can immediately tell this is not a functional email/SMS sender, unlike the many live siblings in the list.

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

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

It gives the critical usage context — not live yet, calls return a not-implemented notice — which effectively tells the agent not to rely on it. It does not, however, name an alternative tool to use for actual email/SMS sending, so routing guidance stops short of explicit alternatives.

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

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

Annotations already indicate non-read-only, non-destructive, open-world hints. The description adds valuable context beyond those: the model may return a best fit or a no-selection result, and there is a cost of 4 MESH/call. This adds useful behavioral detail 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?

Three concise sentences front-load the core purpose, then cover inputs/output behavior, and finish with a usage caveat and cost. No filler or redundant restatement; 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?

With no output schema, the description adequately explains the return possibilities ('best fit or no-selection') and the inputs. Combined with the usage constraint and cost, it provides enough context for an agent to call it correctly, though it omits edge-case details like error handling.

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

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

Schema description coverage is 100%, so the schema already documents profile, content, and goal thoroughly. The description merely restates these names ('Send profile, candidate content options, and a goal') without adding any new semantics, earning the baseline score.

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

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

The description uses a specific verb and resource: 'Choose which concrete content option to show a specific user and how to frame it.' It clearly distinguishes this tool from generation tools by stating it ranks existing variants rather than inventing a campaign, making its role 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 gives explicit when-to-use ('Use it to rank existing variants') and when-not-to-use ('not to invent a whole campaign from scratch'). It also specifies the required three inputs, making invocation conditions clear.

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

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

Beyond the basic annotations (readOnly=false, openWorld=true, destructive=false), the description discloses critical behavioral traits: it 'Checks your processing agreement for payment exclusivity first and fails closed', it runs on claude-haiku-4.5 and names the model in the response, and it costs 5 MESH/call. These details are not present in the annotations and materially inform the agent's expectations.

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

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

The description is dense but every sentence earns its place: hook, service promise, safety/fail-closed behavior, model info, alternative, input contract, output contract, and pricing. It is front-loaded with the user-facing purpose and flows logically through operational details 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?

With no output schema, the description explicitly lists the return shape: '{rescue: {diagnosis, plan, workaround, cautions}, exclusivity_checked, model, next}.' It also covers input, alternative model choice, cost, and the fail-closed safety guarantee. For a generative diagnostic tool with nested input, this is highly 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% and the schema already documents each parameter thoroughly (including the exclusivity fail-closed behavior and aliases). The description merely restates the input contract ('Input: {trouble: string, pos?: string, exclusivity?: 'yes'|'no'|'unknown'}') without adding new semantic meaning, so the baseline of 3 applies.

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

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

The description clearly states a specific verb+resource: 'Stuck on a POS integration... get a diagnosis, a step-by-step plan, and whether the owner-direct checkout workaround applies.' This distinguishes it from siblings like pos-rescue-smart (same contract, different model) and direct-checkout (which would actually execute the workaround), 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?

It gives a clear trigger condition ('Stuck on a POS integration...') and names an explicit alternative ('pos-rescue-smart runs the identical contract on claude-sonnet-5'). However, it does not explicitly state when not to use the tool or reference direct-checkout as the execution alternative, so it stops short of a full when/when-not spec.

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

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

Annotations provide little (only readOnlyHint=false, openWorldHint=true, destructiveHint=false), so the description must carry the burden. It discloses the fail-closed exclusivity gate, the response names the serving model, and the pricing (15 MESH/call). These go beyond annotations and are important for correct invocation. 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 dense but efficient. It front-loads the purpose and model, then contrasts with pos-rescue, then gives input/output shape. Every sentence adds information; no filler. It's longer than a one-liner but appropriately so given the behavioral and pricing details.

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 nested input schema (fully described) and no output schema, the description compensates by specifying the output structure. It also covers the exclusivity gate, pricing, and model choice. It doesn't mention edge cases (e.g., empty trouble) but the schema handles those. For a commercial tool with clear contract, this is complete enough for an agent to call 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%, so baseline is 3. The description adds value by outlining the output structure ({rescue: {diagnosis, plan, workaround, cautions}, exclusivity_checked, model, next}) which is not in the schema (no output schema). It also reiterates the fail-closed exclusivity semantics, reinforcing the schema's own description. This is meaningful addition 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 identifies this as the smart tier of pos-rescue, specifically for harder integration knots, served by a more capable model. It explicitly contrasts with the sibling pos-rescue (fast default), so an agent knows exactly what this tool is for and how it differs.

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 states that pos-rescue is the fast default and this is for harder integration knots, giving an explicit when-to-use versus the alternative. The phrase 'stays the fast default' implies this tool is for when that default isn't enough, which is clear 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?

Despite thin annotations, the description adds meaningful behavioral context: it never invents legal arguments, never drafts/completes filings, never files with a court, and provides an 'honest gut-check.' This goes beyond the annotation flags and sets expectations about output quality and limitations.

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 is front-loaded and efficient, and the no-drafting/no-filing boundaries are valuable. However, the description is truncated mid-word ('alrea'), ends with pricing/category noise ('10 MESH/call, a tool · legal'), and could be trimmed to a cleaner paragraph.

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 lists the output artifacts and audience, which helps an agent set expectations, and it is scoped to a narrow subject domain. But with no output schema and a single generic input field, the missing input contract is a real gap for reliable invocation.

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

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

The only parameter, `input`, has schema text that is a generic boilerplate template referencing agent-brain/agent-memory rather than this tool. The description does say the input should be the user's probate/estate facts, which is some added meaning, but it never specifies a shape, optional fields, or whether free-form narrative is accepted.

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

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

Description names a specific action (turns disputed probate facts into a case tracker) and enumerates concrete outputs (document inventory, key facts, timeline, next-steps, gut-check). It also draws a bright line against drafting and filing, so the tool cannot be confused with a legal-drafting or court-filing sibling.

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

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

Clear intended scenario: use when a user has probate/estate dispute facts and wants a plain-English organizer, targeted at pro se filers and those with counsel. It states what the tool will not do (invent arguments, draft filings, file with a court), but it does not name a specific sibling alternative.

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

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

Annotations indicate openWorldHint=true, readOnlyHint=false, and destructiveHint=false, but the description adds no behavioral context about side effects, output, permissions, or invocation behavior. It does not contradict the annotations, but it contributes nothing beyond them.

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

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

The description is short but not concisely informative; it merely repeats the name. This is under-specification rather than efficient writing, and no 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?

With no output schema, a generic single object parameter, and a description that says essentially nothing, an agent has no way to know what payload to pass, what the tool returns, or why it exists. The context is completely incomplete.

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 a description for the single `input` parameter (100% coverage), so the baseline is 3. The tool description itself adds no parameter meaning; the schema's generic 'Capability-specific payload' example is only marginally helpful and not tailored to this 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 is a tautology: 'react hooks useeffect — react hooks useeffect' restates the name and title without any verb, resource, or functional explanation. 'a tool · general' adds no meaning, and there is no distinction from any sibling 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 gives no guidance about when to use this tool, no conditions, and no alternatives. The word 'general' is too vague to help an agent decide between this and any of the many sibling tools.

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

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

Annotations state readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds behavioral context: it notes that the wrapper may not reliably produce a structured reproduction bundle, and that output is a high-level note rather than a proof. This is useful transparency about reliability and output nature, beyond what annotations provide. However, it doesn't disclose potential side effects (though readOnlyHint=false suggests possible writes), and given the experimental nature, more disclosure could be expected. The description does not contradict annotations, so a 3 is appropriate.

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

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

The description is concise, with three sentences packed with information: purpose, experimental caveat, output quality, and pricing. It is front-loaded with the core function. However, the last phrase 'a tool · audit' is cryptic and adds little value, and the pricing information might be better in annotations or separate metadata. Slight points deducted for that noise.

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

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

Given the complexity (experimental, one nested object parameter, no output schema), the description clarifies expected delivery (counterexample or reason) and limitations (not machine-checkable), which is critical for setting agent expectations. It does not describe the exact input format beyond the schema, but the schema is self-explanatory with examples. It is complete enough for an agent to decide whether to use it, though a bit more detail on input could push it to 5.

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

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

Schema description coverage is 100%, with a single 'input' object parameter described as a capability-specific payload with examples. The description mentions giving it 'one code claim plus relevant code' but does not detail the exact structure of the input object beyond the schema's generic example. Since the schema already covers the parameter, the baseline is 3, and the description adds a bit of context about what to pass, but not enough to raise it.

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

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

The description clearly states the tool's purpose: it takes a code claim and relevant code to produce a counterexample or reason the claim fails. It identifies the resource (code claim) and verb (refute). It is distinguished from siblings by being experimental and an 'analyst's pass,' not a machine-checkable proof, which sets it apart from more formal tools like code-review. However, it does not explicitly name which sibling to use instead, so it loses a point.

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 have a code claim to refute, and it hints at limitations (not a machine-checkable proof). It does not explicitly state when not to use it or alternative tools, but the context of 'experimental' and the caveat about the output quality give clear usage context. It is better than average but not fully 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 is unusually candid: it labels the tool experimental, specifies that the reliable output is a short fit note and draft reply copy in the answer text, warns that structured reply fields are not yet surfaced cleanly, and clarifies that the user still approves and posts. It also discloses the cost. This adds substantial behavioral context 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 longer than average but each section contributes: purpose, required inputs, output format, user responsibility, wrapper limitation, and cost. The opening repeats the title somewhat and the trailing marketing metadata is minor clutter, but overall it is efficiently organized.

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 an experimental tool with no output schema and a generic input schema, the description covers the essential input requirements, the output the agent can rely on, and the caveat about structured fields. It is not a 5 because it leaves the exact input representation of 'target post' and 'brand or offer' ambiguous.

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 `input` parameter's schema description is generic and not tailored to this tool. The prose description adds semantic meaning by saying the input must contain the target post plus the brand or offer, but it does not specify the exact object shape, key names, or how to encode the target post, so it only partially compensates.

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: a reply or quote-post planner for borrowing reach from a larger account. This makes it distinct from broader posting tools and marketing planners in the sibling list, and 'You still approve and post it yourself' reinforces that it is a planning aid, not an actual posting 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?

It clearly states the intended context: use when you want to reply or quote-post to leverage a larger account's reach. It tells the user to provide the target post plus brand or offer, but it does not name alternatives or state when not to use this tool, so it stops short of a 5.

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

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

The description adds substantial behavioral context beyond the annotations: it specifies 'Pure pattern matching, no AI call,' meaning deterministic and cheap; it discloses 'Best-effort, not a guarantee,' warning about false negatives; it mentions the cost '(1 MESH/call)'; and it describes the return shape ({scrubbed, redacted, kinds}) despite no output schema. This goes well beyond the sparse annotations (readOnlyHint:false, openWorldHint:true, destructiveHint:false) and provides key transparency for an agent.

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

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

The description is efficiently structured: it opens with a purpose clause, lists covered data types, gives a usage hint, describes input/output, warns about limitations, and notes cost. It is not overly long, but it begins with 'Safety Scrub —' which repeats the title, and the parenthetical '(1 MESH/call, a tool · safety)' is metadata that could be omitted without loss. Still, every substantive 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 has a nested input object and no output schema, so the description carries significant responsibility. It fully covers the return format ({scrubbed, redacted, kinds}) and even gives an example ('card','ssn'). It also covers behavioral nuances (best-effort, no AI, cost). Minor gaps exist: it doesn't explain aliases (though schema covers them) or behavior when no sensitive data is found (though 'redacted: boolean' implies it). Overall, it is sufficiently complete for the agent 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 input schema has 100% description coverage: the text parameter is described as 'REQUIRED — the text to scan; card numbers, SSNs, API keys/tokens, JWTs and PEM private keys are replaced with [REDACTED-*] markers.' The tool description only says 'Input: {text: string},' adding no new information beyond the schema. It does not mention the alias parameters (input, content) or the fallback chain, but since the schema documents those, the description doesn't need to. 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: 'Redact sensitive data from text before logging it or sending it to a model.' It specifies the exact data types handled (cards, SSNs, API keys, JWTs, PEM keys) and the output markers ([REDACTED-*]). This distinguishes it from sibling tools, none of which mention redaction or safety scrubbing, and explicitly notes 'Pure pattern matching, no AI call' to differentiate from AI-based 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 clear usage directive: 'Use whenever user-supplied or scraped text may carry credentials.' It also implies when to use by mentioning 'before logging it or sending it to a model.' However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the highest bar for usage guidance.

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

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

Beyond the annotations, the description explicitly discloses that the tool is advisory, has no calendar side effects, and costs 2 MESH/call. This adds meaningful behavioral context even though it stops short of describing what the proposed agenda/time-slot output looks like.

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

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

A single focused sentence front-loads the action and constraint, with cost and category tucked into a small parenthetical. No filler or repetition.

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

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

For an advisory planning tool the description covers purpose and safety well, but no output schema exists and the input schema's generic payload description does not specify scheduling-specific fields. An agent would still have to guess the exact shape of the 'input' object.

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 one documented property, but the example payloads reference unrelated tools (agent-brain, agent-memory). The tool description adds 'from a text description of constraints,' which hints at the intended input, but the exact structure of the scheduling payload is left undefined.

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

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

The description opens with a specific action ('Drafts') and concrete deliverables ('meeting agenda and time-slot suggestions'), and immediately distinguishes the tool from calendar-mutating actions with 'does not touch a real calendar.' This is unambiguous and sufficient to separate it from the sibling set.

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 clearly frames when to use the tool: when you have a text description of constraints and want advisory scheduling suggestions. It states an important exclusion ('Advisory only — does not touch a real calendar'), though it does not name alternative tools or spell out 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 declare readOnlyHint=true, so the safety profile is established. The description adds value by noting 'free, no key needed' — a behavioral affordance (no auth required) not captured in the annotations. It also scopes the search domain (Exchange capabilities for rent), which helps the agent understand what results to expect. Description is consistent with annotations.

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

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

Two sentences, no wasted words. Every phrase earns its place: the purpose, the domain scope with concrete examples, and the key affordances (free, no key) are all packed efficiently. This is a model of conciseness for a simple single-parameter tool.

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 search tool with one well-documented parameter, readOnlyHint annotation, and no output schema, the description is largely sufficient. It covers what's searched, the content domain, and access requirements. The only gap is query semantics (how matching works) and what result format to expect, but these are minor for a search tool of this simplicity.

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

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

Schema coverage is 100%, with the single 'query' parameter described as 'what you're looking for'. The description's mention of 'memory, reasoning, safety, images, commerce' adds domain vocabulary that hints at valid query types, giving slight value beyond the schema. However, it doesn't clarify match semantics (fuzzy vs exact, keyword vs natural language) which would help an agent formulate queries 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 what the tool does: search the MeshMarket exchange for rentable capabilities. It specifies a verb (search), a resource (MeshMarket exchange), and the scope (capabilities agents can rent across memory, reasoning, safety, images, commerce). The main gap is that it doesn't explicitly differentiate from siblings like mesh_discover or merchant-discovery, though the exchange-specific search intent is reasonably distinct.

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

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

The description implies when to use it ('search for capabilities agents can rent') but provides no explicit exclusions or alternative recommendations. Context like 'free, no key needed' gives useful usage context, but there's no statement about when NOT to use this versus mesh_discover, mesh_delegate, or other discovery tools in the sibling set.

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 cover read-only/destructive hints; the description adds beyond that by disclosing the external backend ('Powered by api.meshtool.ai') and the cost ('4 MESH/call'), plus the 'any JSON shape' output flexibility. It does not detail failure or truncation behavior, but the schema notes length limits.

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

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

The core purpose is front-loaded in one clear sentence, and the cost/backend metadata is compact. The trailing parenthetical '(4 MESH/call, a tool · extraction)' is somewhat noisy, but the overall definition is short 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 simple extraction tool with no output schema, the description plus annotated schema covers what to pass, the expected shape capability, and cost. It does not explicitly spell out the response object, but 'Pull structured data out' and the user-provided shape make it adequately inferable.

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 mostly restates text/shape and does not add much meaning beyond the schema. It reinforces shape flexibility via 'any JSON shape you describe' but adds no new parameter-level semantics.

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

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

The description leads with a specific verb and resource: 'Pull structured data out of free text' and enumerates concrete use cases (classification, field extraction, scoring). The title and category tag 'extraction' also help distinguish it from generic text tools in the sibling list.

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

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

It gives clear context for when to use it: whenever you want a JSON-shaped result extracted from free text, and even lists example jobs. It does not explicitly exclude alternatives or state when not to use it, so it stops just 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 adds substantial context beyond the sparse annotations: it names the serving model ('Runs claude-haiku-4.5'), states the cost ('5 MESH/call'), notes that the response names the model, and details the return structure. It also characterizes the tool as 'reasoning'. No contradiction with annotations; readOnlyHint=false is not contradicted by the output-producing 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 a single sentence but packed with essential information: purpose, output format, model, cost, and I/O shape. It uses em-dashes and parentheticals efficiently, with the core purpose leading. Every clause earns its place, and there is no redundant or filler content.

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

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

With no output schema present, the description fulfills that responsibility by listing the returned fields: {analysis: {summary, steps, risks, verdict}, model}. It also covers cost, model, and input shape, providing enough context for an agent to invoke correctly. The detailed schema complements the description, making the tool well-specified for its complexity.

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

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

The tool description only restates 'Input: {task: string}' while the input schema's description is far more detailed, covering coercion, trimming, truncation to 4000 chars, whitespace rejection, and fallback keys. Since schema coverage is 100% and the schema already provides rich parameter semantics, the description adds no extra meaning beyond a basic restatement. 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: 'Hand a task, get a structured plan back — typed steps, risks, and a go/caution/no-go verdict.' It also specifies the output structure and the model, making the purpose specific and unambiguous. While it doesn't explicitly distance itself from sibling tools like 'task-orchestrate', the unique output type (steps, risks, verdict) distinguishes it.

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

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

The description implies usage context ('Hand a task, get a structured plan back') but provides no explicit 'when to use' or 'when not to use' statements. It does not mention alternative tools or exclusions for scenarios where another tool would be more appropriate. This is implied guidance at best, not explicit alternative naming.

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 useful context beyond annotations: it discloses an external dependency ('Powered by api.meshtool.ai') and a cost ('6 MESH/call'), which matters for an agent deciding whether to invoke it. However, it does not describe failure modes, rate limits, or what the execution plan looks like. No contradiction with annotations (readOnlyHint=false aligns with an external call).

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-loads the purpose, but it contains redundancy: 'Task Orchestrate —' repeats the tool title, and 'Input: { task: string, tools: array }' duplicates the schema. The suffix '(6 MESH/call, a tool · reasoning)' is cryptic and arguably confusing. It is adequately short but not maximally economical.

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 a nested input object (4 properties) and no output schema, the description carries a heavy burden, yet it fails to explain the return format of the execution plan, how use_memory affects planning, or what happens on external API failure. An agent cannot predict what it will receive back, leaving a significant gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'Input: { task: string, tools: array }' merely restates the two required parameters already documented in the schema and adds no syntax, format, or constraint details beyond it. The description does not compensate for anything the schema already covers.

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

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

The description states a specific verb+resource: 'Break a multi-step task into an execution plan any agent can follow.' This clearly conveys the tool's function and distinguishes it from most siblings, though it does not explicitly differentiate from the closely-named 'task-analysis' tool. The purpose is clear and aligned with the name.

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

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

No guidance on when to use this tool versus alternatives. It does not mention task-analysis or any other sibling, and there are no when-to-use or when-not-to-use conditions. An agent would have to infer suitability from the name alone, which is risky given the large 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 indicate readOnlyHint=false and openWorldHint=true, so the description does not need to repeat those. It does add behavioral context by stating it preserves tone/register and flags ambiguous terms with alternate readings, which is valuable. However, it does not disclose any side effects, rate limits, or what happens in error cases. Given the annotations, the description adds some context but not deeply.

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, efficient sentence that front-loads the purpose and adds key behavioral details. The parenthetical about cost and type is compact and does not waste space. No extra 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 complexity (nested object input, no output schema), the description is incomplete. It fails to specify the input format, expected fields, or how to handle multilingual requests. The agent may know 'translate' but cannot call it correctly without guessing the payload structure. The schema description is misleading and does not compensate.

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 one property 'input' with a generic description that gives examples for other tools (agent-brain, agent-memory), not for translate. The tool description does not explain what the input payload should contain (e.g., source/target languages, text to translate). This is a major gap: the agent cannot determine how to structure the input from either the schema or the description, so parameter semantics are essentially undocumented.

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

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

The description clearly states the verb ('Translates'), the resource ('text'), and the specific scope ('between languages'). It adds distinctive details about preserving tone and register and flagging ambiguous terms, which goes beyond a generic translation tool and distinguishes its behavior from a plain translator.

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

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

The description implies usage context through details like preserving tone and flagging ambiguities, suggesting it is suited for nuanced translation tasks. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or when not to use it. There are no sibling translation tools to differentiate from, so this absence is less critical, but the guidance remains implicit.

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=false, openWorldHint=true, destructiveHint=false, which is a slightly odd profile for a no-op slot. The description adds the crucial behavioral fact annotations cannot convey: there is no backend and calls return a not-implemented notice. It does not say whether any quota/MESH is actually consumed despite the '(0 MESH/call)' tag, a minor gap.

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 key status ('RESERVED — not live yet') and the routing targets are front-loaded, and the whole thing is one compact block. It is somewhat redundant, restating 'placeholder'/'not live'/'not Shop-Graded' across clauses and appending pricing metadata that is not needed to make the routing decision.

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 deprecated, no-op signpost tool with full schema coverage and no output schema, the description contains everything an agent needs: it is not live, do not call it, and here is where to go instead. Nothing material is missing.

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

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

Schema description coverage is 100% and the single 'input' object is documented in the schema, so the baseline is 3. The description adds nothing about the capability-specific payload beyond the schema's own examples, which is acceptable for a dead routing signpost.

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

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

The description states exactly what this tool is (a reserved, not-live placeholder with no provider behind it) and immediately names the two live replacements, grok-tts and grok-stt. An agent can distinguish it from every sibling, including the near-identically named grok-tts/grok-stt lanes, without opening a schema.

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 an explicit when-not-to-use ('SUPERSEDED', 'not live yet', 'calls return a not-implemented notice') and an explicit alternative for each capability ('use grok-tts for text-to-speech and grok-stt for speech-to-text'). Routing 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?

The annotations declare openWorldHint=true and readOnlyHint=false, but the description says there is no provider and calls return a not-implemented notice. This contradicts the annotations' implication of external access and side-effect potential. Per the rules, a description that contradicts annotations scores 1.

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 key warning is front-loaded, but the description repeats the same fact (placeholder, not live, not implemented) across multiple sentences. It could be reduced to one sentence without losing information.

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

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

For a placeholder with no output schema, the description sufficiently states what calls return (a not-implemented notice) and that no provider exists. It could be more complete by explicitly directing the agent to a functional alternative, but it is largely adequate for the tool's limited 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 description coverage is 100% for the single 'input' parameter, and the schema already explains it as a capability-specific payload. The description adds no additional parameter meaning, so this is the baseline 3.

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

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

The description explicitly states this is a placeholder web-search slot with no provider and that calls return a not-implemented notice. This clearly distinguishes it from functional siblings like search and fetch, so an agent can immediately tell it is not a usable web search 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?

It clearly establishes when not to use the tool: it is not live, not implemented, and has no provider behind it. However, it does not explicitly name an alternative (e.g., 'use search instead'), although the implied alternative is obvious from the sibling context.

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