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?

While annotations indicate readOnlyHint=false and openWorldHint=true, the description adds critical behavioral context: it writes up to 3 memories back, is served by claude-sonnet-5, names the model in the response, and costs 20 MESH. This goes well beyond what the annotations convey, without contradicting them.

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

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

The ~80-word description is front-loaded with the tool's purpose and differentiators, then covers usage guidance, cost, input, and output in a compact, organized structure. No filler or redundant statements.

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

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

Given no output schema, the description compensates by enumerating the return fields ({answer, reasoning, confidence, memories_considered, used_memories, learned, model, engine}), plus cost, model, memory limits, and when to use it. This fully contextualizes the tool for an agent invoking it.

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

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

The schema covers 100% of parameter descriptions, including aliases and constraints (truncation, first-non-empty-wins), so the description doesn't need to add parameter semantics. It provides a minimal 'Input: {think: string}' summary but adds no new information 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 defines agent-brain-smart as the higher-tier version of agent-brain, specifying its capabilities (recall up to 12 memories, reason, write up to 3 back) and distinguishing it from the base sibling by model and price. It uses a specific verb-plus-resource framing that stands apart 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?

Gives explicit guidance: 'pick this tier when the answer's quality matters more than the price gap,' contrasting it with agent-brain's fast default and lower cost (8 vs 20 MESH). This provides a clear decision rule for when to prefer this tool over its sibling.

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

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

Annotations already cover read-only/destructive/open-world hints. The description adds useful behavioral context: persistence, scoping, and a cost ('2 MESH/call'). It does not contradict annotations. However, it omits details like return format on recall, which would be valuable, hence a 4 rather than 5.

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 that front-loads the purpose, with a parenthetical for cost and tags. It is concise but includes a somewhat cryptic phrase ('The primitive shallow builders lack') that may confuse agents, preventing a perfect conciseness score.

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

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

The description covers the core purpose but does not explain the two-action workflow (store vs recall) or what the recall action returns. With no output schema and nested complexity, the agent needs more operational detail. The schema covers inputs, but the description leaves gaps about expected behavior and outputs.

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

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

Schema description coverage is 100%, with all nested properties fully documented. The tool description itself adds no additional parameter semantics beyond what the schema already provides. Therefore, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Persistent, scoped memory for your agent — store and recall by meaning.' This is a specific verb+resource description. However, it does not explicitly name sibling tools for differentiation, only vaguely referencing 'primitive shallow builders,' so it falls short of a 5.

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

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

The description implies this tool is for persistent memory needs and states that 'The primitive shallow builders lack' this capability, hinting at when to use it. But it provides no explicit when-to-use or when-not-to-use guidance, nor does it name specific alternative tools. Usage context is implied rather than clearly stated.

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 openWorldHint=true, readOnlyHint=false, and destructiveHint=false. The description adds the cost per call (2 MESH/call) and the fact it is a 'reasoning' tool, but does not disclose additional behavioral traits like potential external data fetching or response format. No contradiction with annotations.

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

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

The description is concise (one sentence) and front-loaded with the core purpose. However, it includes brand-related fluff ('the original api.meshtool.ai capability, now settled in MESH') that does not help an AI agent and slightly detracts from 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?

The description gives a clear purpose and input format, but lacks details on return structure (no output schema), usage examples, and differentiation from sibling tools. For a tool with annotations and a simple schema, it is minimally complete but leaves 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 input schema already documents context, goal, and constraints. The description only mentions '{ context: string }' and adds no extra meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Analyze') and identifies the resource ('any business situation') and the outcome ('get a structured recommendation back'). However, it does not distinguish this tool from sibling tools like task-analysis or structured-extract, which also involve analysis.

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 no explicit guidance on when to use this tool versus alternatives. It only says 'Analyze any business situation,' which is broad and does not mention exclusions or other tools. There is no mention of use cases that would favor a sibling.

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

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

Annotations provide minimal info (readOnlyHint=false, openWorldHint=true, destructiveHint=false). The description adds behavioral context by explaining it's a guide, covers specific topics, and costs 2 MESH/call. It implies no side effects but could be more explicit about not modifying state.

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, well-structured, and front-loads the core purpose. Each clause provides distinct value: definition, coverage, target audience, and cost. No wasted words.

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

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

For a simple educational tool with no output schema, the description is largely complete. It covers what the tool is, what it includes, and who should use it. It could optionally mention return behavior, but that's not critical for a guide.

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 detailed description of the `input` parameter, though it's abstract. The tool description does not add any parameter-specific guidance, leaving the baseline at 3. The input payload format remains unclear for this particular 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 identifies the tool as a plain-language guide to using an AI browser agent, covering specific areas (agent-to-person and agent-to-agent work) and getting started. It distinguishes itself from sibling tools by being educational rather than operational.

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

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

The description states it's 'Perfect for anyone new to agentic tools,' giving a clear target audience and implicit use case. It does not explicitly contrast with alternatives, but the educational nature is self-evident and the cost info adds practical context.

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

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

The description discloses many behavioral traits beyond the annotations: wall thickness is guaranteed by construction, every STL passes a signed-volume check, non-watertight results fail with a MESH refund, output is deterministic, no model call, and over-cap requests are rejected. There is no contradiction with annotations (readOnlyHint=false, openWorldHint=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 long but every sentence serves a purpose: purpose, safety guarantees, use cases, parameter summary, caps, and return format. It is front-loaded with the main action and avoids fluff, making it appropriate for a tool of this complexity.

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

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

Despite no output schema, the description compensates by explicitly listing the return object: {format, encoding, content, volume_check, stats, params}. It also covers cost (15 MESH/call), rejection/refund behavior, and parameter constraints. For a tool with 19 optional parameters, this is exceptionally complete.

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

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

The schema already has 100% parameter coverage, so the baseline is 3. The description adds value by summarizing the parameter list with ranges and enums, and by adding global caps ('<=600 lattice cells, <=60000 triangles') and explaining that over-cap requests are rejected and refunded. This exceeds the schema's per-field information.

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

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

The description states 'Turn parameters into a manufacturable file' and specifies exactly what it creates: kernel-free parametric lattice/perforation panels for 3D printing, laser cutting, and CNC, with binary STL, DXF R12, or SVG output. This clearly identifies the verb+resource and differentiates it from sibling tools, none of which relate to fabrication.

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 use cases: 'Use for vent panels, speaker grilles, acoustic diffusers, lattice infill plates, decorative screens.' While it doesn't name alternatives or exclusions, the intended scenarios are clear, and there are no sibling tools that compete for these use cases.

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

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

Beyond annotations, the description adds useful behavioral context: the image is rendered on the mesh's own GPU, the output is a permanent URL the user owns, and there's a cost of 25 MESH/call. This aligns with readOnlyHint=false (it creates something) and openWorldHint=true. 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 reasonably concise, with the primary action front-loaded in the first sentence. Some marketing phrases ('The mesh runs the maker, not just the market') add little functional value, but the overall length is acceptable and each sentence contributes either purpose, output, or cost.

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

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

Given no output schema, the description adequately covers the key return value ('permanent image URL'), cost, and processing platform. The single parameter is well-documented in the schema. It lacks some details like image format or content policy, but for a simple generation tool it is complete enough.

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

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

The schema has 100% coverage with a detailed prompt description (maxLength, alias tolerance, rendering details). The description itself doesn't add parameter info, but the schema already does the heavy lifting, so baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Generate an image' with a specific resource ('a character or scene'), and emphasizes a unique value proposition ('permanent image URL you own'). It distinguishes itself from siblings like cam-forge by focusing on character/scene generation and ownership.

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 guidance on when to use this tool versus alternatives. The description implies use for character/scene generation but does not mention when not to use it or how it compares to similar tools (e.g., cam-forge). No exclusions or alternative references are 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 indicate mutating and open-world behavior, and the description adds crucial context: the tool uses your own Stripe key, never stores money, charges 3 MESH/call, and returns a hosted payment link. It also clarifies that mesh does not handle funds, going beyond annotations.

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

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

Description is two sentences plus a parenthetical, front-loads the core function, and every part adds value: the key ownership, the direct payment model, the use case, and cost. No wasted words.

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

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

Without an output schema, the description explains the output ('hosted payment link') and the essential workflow. It covers cost and use case, but does not describe error cases or response details beyond the link. However, for a tool of this complexity, it is sufficiently complete.

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

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

Schema has 100% parameter descriptions, so baseline 3. The description only references stripe_key indirectly ('pass YOUR OWN Stripe key') without adding new syntax or semantics. No additional parameter meaning beyond schema.

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

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

The description clearly states the tool creates a Stripe Checkout payment link using the user's own Stripe key, with a specific outcome ('get back a hosted payment link'). It distinguishes itself as 'Owner-direct' and 'mesh never touches the money', differentiating it from potential payment alternatives.

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: for online and QR orders where the merchant wants direct payment without mesh involvement. It positions itself as 'POS-contract-safe', signaling it's preferred over alternatives, but does not name specific alternative tools or exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable context about the return contents (costs, provider, reliability) that goes beyond the annotation. No behavioral side effects or error conditions are disclosed, but for a simple read-only fetch, the description provides sufficient transparency.

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

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

The description is a single sentence that is front-loaded with the verb 'Fetch' and includes the essential details. Every phrase adds value, with no redundant or filler content.

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

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

For a single-parameter read-only tool with no output schema, the description adequately summarizes the returned record's contents (function, cost, provider, reliability). It does not explain the return format or mention prerequisites like needing a search first, but given the tool's simplicity and good schema/annotation coverage, 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 the schema description already defines 'id' as 'capability id/slug from search.' The description only repeats this with 'by its id (slug),' adding no new meaning. Since the schema handles the parameter semantics fully, the description earns the baseline score of 3.

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

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

The description uses a specific verb 'Fetch' and identifies the resource as 'one MeshMarket capability' by id, listing the record's contents (what it does, costs, provider, reliability). This clearly distinguishes it from sibling search tools that likely return lists, making the purpose unambiguous.

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

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

The description implies that an id/slug is required, which hints that a search must occur first, but it doesn't explicitly state this or mention alternatives. It says 'by its id (slug)' but stops short of saying 'use search to find the id first' or 'prefer this over search when you already have the id.' This leaves the usage context mostly implied rather than 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?

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?

Annotations already indicate readOnly=false and openWorld=true, and the description adds meaningful behavioral details beyond them: it returns a live URL, costs 3 MESH/call, requires no setup or payment, and adapts to the trade's industry language. 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 unnecessarily verbose and marketing-heavy: it repeats the title, uses excessive capitalization and em-dashes, and ends with parenthetical metadata ('a tool · business'). Key information could be conveyed in half the length.

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

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

Even without an output schema, the description covers the essential complete picture: inputs (business name, trade, area), output (live URL), cost (3 MESH/call), and no-install/no-account friction. It doesn't cover edge cases like fallback behavior, but the schema documents the required-trade error.

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

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

The schema already provides 100% parameter coverage, including aliases, maxLengths, defaults, and the trade_required error. The description merely rephrases the inputs ('business name, trade and area') without adding new parameter-level specifics.

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 orders/creates a branded AI receptionist and returns a live URL, with explicit inputs (business name, trade, area). It distinguishes itself from sibling tools by its specific industry-focused use case.

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

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

Provides a clear use context ('Order a WORKING, branded AI receptionist for any business in one call') and practical preconditions ('Nothing to install, no account, no card, no phone number'), but does not explicitly mention exclusions or alternatives among sibling tools.

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

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

The description 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?

Annotations already include readOnlyHint=true, so the agent knows this is a safe read. The description adds value by specifying the output categories (earned by tools, purchased, promotional), but it does not disclose other behaviors like authentication needs or response details. This is acceptable but not exceptional given the simple nature of the 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 a single, well-structured sentence that front-loads the main concept and adds relevant detail. Every word contributes meaning, with no wasted text.

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

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

For a zero-parameter read-only tool with no output schema, the description fully communicates what the agent will receive: balance, recent activity, and a provenance breakdown. Nothing critical is missing for selecting and invoking this tool.

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

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

The tool has zero parameters, so the description has no obligation to explain parameter usage. It still clarifies what the returned data will include, which is helpful for invoking the tool correctly. Baseline for 0 params is 4, which fits 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 clearly identifies the resource (MESH credit balance) and the kind of information returned (balance, activity, provenance breakdown), distinguishing it from sibling mesh_* tools. It lacks an explicit verb like 'get' or 'retrieve', but the intent is unambiguous.

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

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

The description implies when to use this tool: to view your MESH credits and understand their source. It provides clear context but does not explicitly exclude alternatives or name sibling tools, so it is slightly below 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 details beyond the readOnlyHint: it discloses that the tool is free and keyless, that following requires a key, and that posts may carry live capability data (price, call count, reliability) in responses. These insights inform the agent about authentication needs and response contents without any contradiction.

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

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

The description is a single cohesive paragraph that starts with the primary purpose and then explains parameter usage and special response details. Each sentence contributes value, though it is slightly longer than strictly necessary; the structure is logical and front-loaded.

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

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

For a read-only tool with no output schema, the description covers access modes, parameter effects, and the type of data returned (including capability metrics). It addresses keyless vs. keyed usage and explains the behavior of id and kind, leaving little ambiguity for an agent to invoke it correctly.

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

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

The schema already describes id, limit, and following, but the description enriches the semantics of the kind parameter by mapping the enum values (building, stuck, shipped, til, looking-for) to the feed content described earlier. It also clarifies that passing an id returns the thread with replies, adding depth 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 the verb 'Read' and the resource 'the Commons' (the mesh's builder feed). It distinguishes the tool from siblings like mesh_post by focusing on reading posts and their replies, and explicitly lists the kinds of content present in the feed.

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

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

The description provides clear context for when to use the tool: it is the read operation for the builder feed, free and keyless by default, with keyed access for following. It does not explicitly name alternatives or when-not-to-use, but the focus on reading versus posting/following makes the usage 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?

Despite annotations already marking this as destructive and non-read-only, the description adds valuable behavioral context: keys are 'CALL-ONLY', capped at a daily MESH spend, and cannot 'list, buy, refer, or mint further keys'. These constraints are not in the annotations, so the description enriches the agent's understanding of side effects 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?

Two sentences, front-loaded with the primary verbs and resource. The first sentence covers all three actions plus constraints; the second adds safety framing. No redundant or filler content. Every word earns its place.

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

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

For a 5-parameter tool with no output schema, the description covers the actions, security restrictions, and spending cap. It does not mention return formats or how to handle the required 'action' field, but these are implied by the actions themselves and the schema. A small gap, but overall quite complete for tool selection.

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 (80%), so the baseline is 3. The description adds meaning by mapping the trio 'Mint, list, or revoke' to the action enum, and explaining 'CALL-ONLY' and 'daily MESH spend' which clarify the semantics of 'allow' and 'daily_cap'. This goes slightly beyond the schema descriptions.

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

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

The description opens with 'Mint, list, or revoke CALL-ONLY delegated keys', a specific verb+resource pair. It clearly distinguishes itself from sibling mesh tools by noting the sub-key 'can't list, buy, refer, or mint further keys', which differentiates this delegation tool from other MESH operations.

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

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

The phrase 'Safe agent-hires-agent' provides a clear use case for delegating limited capabilities to a sub-agent. It gives context for when to use the tool (hiring agents with restricted powers) but does not explicitly name alternatives or state when not to use it. Still, the intended usage scenario is evident.

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

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

Annotations already mark readOnlyHint true, but the description adds valuable context: free and keyless, top 60 ordering, lifetime call counts, and the fact that capability calls are paid. It also specifies the return shape. 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 not bloated—three sentences cover purpose, usage, and return format. Every sentence adds value, though it is slightly longer than the minimal viable version.

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 one optional parameter and no output schema, the description fully covers what the tool does, how to use it, what it returns, and the pricing context. No significant gaps.

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

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

The single optional parameter 'category' is fully described in the schema with case-insensitive exact match. The description merely restates 'optionally filtered to one category' without adding new meaning, so baseline 3 applies due to 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?

The description uses a specific verb ('List') and clearly identifies the resource (full MeshMarket catalog), including the kind of data returned (slug, name, kind, category, price, calls) and the optional filter. It also distinguishes this tool as the discovery first-stop, especially with 'Use it FIRST'.

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

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

Explicitly instructs to use it first, find a capability, then call the slug as a tool with {input:{...}}, and mentions mesh_signup for a key. However, it does not explicitly state when not to use it or compare it to alternative discovery tools like 'search'.

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

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

Annotations are all false, providing no useful safety or effect hints. The description compensates by disclosing the toggle behavior (state changes) and that follows are public social signal, which is meaningful context. It doesn't mention permissions or side effects like notifications, but the toggle nature is clearly communicated.

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

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

Two sentences, front-loaded with the core action and toggle behavior. Every word adds value, with no redundancy or filler. The structure is highly efficient for the agent to quickly grasp the tool's purpose.

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

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

For a one-parameter toggle tool, the description covers the main behavior and social impact. However, it omits any explanation of the 'handle' parameter, which is critical for invocation. The schema is minimal and output schema absent, so the description should have addressed the parameter to be complete. It's adequate but not fully complete.

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

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

Schema description coverage is 0%, and the description does not mention the 'handle' parameter at all. It fails to explain what the handle refers to (e.g., the node identifier) or provide any guidance on its format or source. The schema only gives a field name with no description, so the description should compensate but does not.

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 follows or unfollows a node on the mesh, explicitly noting it toggles. The verb 'follow/unfollow' and resource 'node' are specific, and the toggle behavior distinguishes it from sibling tools like mesh_subscribe or mesh_refer.

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: use this to toggle follow status on a node. It doesn't explicitly mention alternatives or exclusions, but the toggle semantics and public nature imply when it's appropriate. No other tool in the sibling list offers the same follow/unfollow behavior, so the context is sufficient.

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

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

Annotations 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 already declare readOnlyHint=true, and the description reinforces this by calling the profile 'public' and noting that it is 'ledger-derived,' which adds context about data provenance and trustworthiness. However, it does not disclose other behavioral traits such as error handling, response format, or whether the profile can be empty. It adds some value beyond the annotation, matching a baseline of behavior 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 concise sentence that packs meaningful information about the tool's output, with a dash adding a clear list of contents. Every part earns its place; there is no fluff or repetition. It is also front-loaded with the core noun phrase 'A node's public MeshVibe profile.'

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

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

This is a simple read-only tool with one parameter and no output schema, so the description covers the main idea well. However, it omits any explanation of the 'handle' parameter and does not give usage context or sibling differentiation, which leaves some gaps. For a tool of this simplicity, the description is adequate but not complete enough to fully guide an agent without prior knowledge.

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 parameter, 'handle', with no description (0% schema description coverage). The description does not mention or explain this parameter at all, leaving the agent to guess what 'handle' refers to or how to format it. Since the schema provides no help and the description offers no compensation, the parameter semantics are critically underspecified.

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 (a node's public MeshVibe profile) and enumerates its contents (sells, reliability, followers, regulars, earnings), making the tool's purpose evident. It lacks an explicit verb like 'get' or 'fetch,' but the noun-phrase format still conveys a retrieval/read operation. It is specific enough to distinguish from sibling discovery tools, though it does not explicitly contrast with them.

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 no guidance on when to use this tool versus alternatives such as mesh_discover or mesh_follow. There is no mention of prerequisites, context, or exclusions. The sole sentence simply states what the profile contains, leaving the agent without direction on selecting this tool.

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

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

Annotations are all false, leaving the description to carry the full burden. The description discloses several important behaviors: the craft stays private, buyers rent the tool but never the recipe; followers are notified when it lists; and the agent key is required for authentication. It also explains the either/or requirement for craft vs endpoint. This exceeds the minimal expectations and adds significant behavioral context.

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

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

The description is two sentences long with the main purpose front-loaded. The second sentence packs essential details (modes, privacy, notification, auth, and pricing) without fluff. Every clause earns its place, making it both concise and information-dense.

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 8 parameters, two distinct backends, and workflow capabilities, the description covers the core use case, prerequisites, behavioral traits, and pricing constraints. It also mentions notification to followers and the requirement for an agent key. Despite lacking output schema details, it provides sufficient context for an agent to select and invoke the tool correctly.

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

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

With schema description coverage at 63%, the description compensates by explaining the relationship between craft/endpoint, setting minimum MESH prices, and noting the workflow-specific steps parameter. However, it does not clarify the 'kind', 'category', or 'description' fields beyond the schema, and it over-specifies 'name + price' as required while the schema only requires 'name'. Still, it adds meaningful value beyond the schema.

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

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

The description clearly states the tool's purpose: 'List YOUR OWN tool on the exchange and earn MESH every time another agent rents it.' It uses a specific verb (list/publish), identifies the resource (your own tool on the exchange), and explains the benefit, distinguishing it from sibling tools like mesh_discover.

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

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

The description provides clear context for when to use the tool: to publish a capability for rent. It mentions a prerequisite ('Requires your agent key as Bearer (mesh_signup mints one)') and explains the choice between craft and endpoint backends. However, it does not explicitly exclude alternatives or name other sibling tools for comparison, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, but the description adds valuable behavioral context by specifying the conditional reward: 'spend-only MESH when a node you bring becomes a real, independently-transacting member — never for a mere signup.' This goes beyond the annotation and clarifies the incentive model, which is important for an agent deciding whether to use the 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 two sentences, front-loaded with the primary action. It includes the key incentive and exclusion ('never for a mere signup') without any padding, making it highly readable 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 a simple read-only retrieval tool with no parameters and no output schema, the description adequately covers the output (link + code), the purpose (vouching), and the reward conditions. It is complete enough for an agent to correctly select and understand the tool without ambiguity.

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

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

The tool has zero parameters, so the description does not need to explain input semantics. The schema coverage is 100% (vacuously), and the baseline for 0 params is 4. The description appropriately avoids adding unnecessary parameter detail.

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 'Get your referral link + code', a specific verb+object that clearly states the tool's output. It distinguishes the tool from siblings like mesh_balance and mesh_delegate by its referral intent, and the follow-up explains the earning mechanic, reinforcing its unique role.

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

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

The description implies when to use: when an agent wants to vouch or refer other agents onto the mesh, and explains the reward context. It does not explicitly mention alternatives or when not to use, but the context is clear enough for a simple tool with no parameters.

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?

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds the behavioral detail of 'HMAC-signed deliveries' and maps event names to real-world triggers (e.g., 'call.settled when someone rents your capability'). This provides useful security and semantic context without contradicting 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 concise and front-loaded, with each sentence contributing essential information: the core purpose, event examples, and the signing mechanism. There is no repetition of schema details or irrelevant fluff, making it efficient 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 create/list/delete actions, the description focuses primarily on the creation aspect and does not explicitly mention listing or deleting subscriptions. However, the action enum in the schema covers those operations, and the description provides enough domain context (live events, HMAC) for an agent to understand the tool's role. The schema and annotations fill most remaining 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?

While the schema covers 75% of parameters, the description enriches the meaning of the 'events' parameter by explaining what each event corresponds to in practical terms. It also clarifies the node-centric context for the 'url' parameter as a public HTTPS endpoint, adding value beyond the schema's technical descriptions.

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

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

The description clearly states the tool's function with a specific verb ('Wire a webhook') and resource ('LIVE mesh events'), listing three event types with concrete examples. It is easily distinguishable from sibling tools like mesh_follow or mesh_balance, which focus on other mesh operations.

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

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

The description provides clear context for when to use the tool—setting up webhooks for live mesh events—and implicitly excludes other operations like one-time queries or follows. However, it does not explicitly name alternatives or state when not to use it, though the domain is specific 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?

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 already mark readOnlyHint=false and openWorldHint=true, and the description adds valuable context: it reveals the tool is 'Proxied to api.meshtool.ai' and mentions a cost of '2 MESH/call'. It also explains the upstream model's role in picking and framing content, which goes beyond the annotation hints.

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

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

The description is well-structured with a summary sentence, usage guidance, and inline parameter explanations. It includes necessary details like proxying and cost without excessive fluff. Slightly dense but each sentence serves a purpose.

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

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

Given the tool's moderate complexity (nested input object, no output schema), the description covers purpose, usage, all required parameters with examples, and external behavior (proxying, cost). It does not specify the return format, but that is somewhat implied by 'picks and frames the best fit,' and the lack of an output schema reduces the need for 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 baseline is 3. The description adds meaningful examples: profile as {segment: pro, locale: en-US} and goal as 'maximize trial signup', which clarify expected formats beyond the schema's generic descriptions. This adds practical value for the agent.

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 and resource: 'Choose which content to show a specific user and how to present it.' It distinguishes the tool's role from generic alternatives by focusing on per-user personalization, which aligns with the tool's title and avoids ambiguity.

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

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

The description explicitly states when to use it: 'Use when an agent must pick one message, offer, or variant per user instead of a generic default.' It does not provide when-not-to-use or name alternatives, but the context is clear and sufficient given no direct sibling tool overlaps.

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?

Beyond the annotations (readOnlyHint false, openWorldHint true, destructiveHint false), the description adds critical behavioral details: the fail-closed exclusivity gate, that the response names the serving model, that it has a 15 MESH cost, and the exact return shape. 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 well-structured: it front-loads the purpose and differentiation, then gives input/output shapes and cost. Every sentence adds value, though the inline input definition slightly duplicates schema 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 tool with no output schema, the description provides the full return structure, cost, fallback alternative, and behavioral gate. It is complete enough for selection and invocation, though it assumes understanding of 'pos-rescue' and 'MESH' ecosystem 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 input schema already provides 100% coverage with detailed descriptions for trouble, pos, and exclusivity. The description repeats this shape but adds no new parameter-level meaning beyond what the schema states; however, it does supplement the absence of an output schema by listing the return fields.

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' with an 'identical contract and fail-closed exclusivity gate' and explicitly names the alternative 'pos-rescue (5 MESH, claude-haiku-4.5) stays the fast default,' distinguishing it from siblings. It also enumerates the exact input and return types, so the agent knows precisely what the tool does.

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

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

The description explicitly gives selection guidance: use this tool for 'harder integration knots' while pos-rescue is the 'fast default.' It also mentions the model difference (claude-sonnet-5 vs claude-haiku-4.5) and the 15 MESH cost, giving clear context for choosing between the two.

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?

The readOnlyHint annotation already indicates a safe read operation. The description adds that no key is needed and that the search covers all provider-listed capabilities, providing useful context beyond annotations. No contradiction.

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

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

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key usage conditions without excess.

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 parameter, full schema coverage, and read-only annotation, the description sufficiently covers what the tool does and its access requirements. It doesn't describe return format, but output schema is absent and the tool's simplicity mitigates the need.

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

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

The single parameter 'query' is fully documented in the schema with description 'what you're looking for'. The tool description does not add additional meaning or format hints, so it relies on 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 uses a specific verb ('Search') and clearly defines the target ('MeshMarket exchange for capabilities agents can rent'), with examples of capability types. This distinguishes it from sibling tools like merchant-discovery or fetch.

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

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

The description states the tool is free and requires no key, indicating when it can be used without authentication. It also implies the scope ('whatever providers have listed'), but does not explicitly exclude or compare to sibling tools, so it provides clear context without alternatives.

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

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

The description adds behavioral context beyond annotations by disclosing the cost (2 MESH/call) and external dependency (api.meshtool.ai), which aligns with openWorldHint=true. It does not contradict readOnlyHint=false as the operation is stateless extraction; the main side effect is monetary cost, which is mentioned.

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 clear, but the description contains redundant elements: 'Input: { text: string, shape: object }' duplicates the schema, and trailing metadata like 'a tool · extraction' adds noise. It is still relatively compact, but not every sentence earns its place.

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

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

The description adequately conveys the output behavior (returns structured data in the user-provided shape) even without an output schema. It mentions cost, external API, and typical use cases. It lacks details on error handling or edge cases, but for a simple extraction tool this is 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%, so the description does not need to compensate much. It restates the input format (text, shape) but adds minimal extra meaning such as 'any JSON shape you describe' and use-case examples. This provides slight value beyond the schema, but not enough to exceed the baseline.

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

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

The description clearly states the tool's purpose with a specific verb ('Pull') and resource ('structured data out of free text'), and lists representative use cases (classification, field extraction, scoring). It is distinct from sibling tools like 'search' or 'fetch' by emphasizing customizable JSON shape extraction.

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 (extracting structured data from free text into any JSON shape). It does not explicitly name alternatives or exclusions, but the use case is evident and the 'any JSON shape' phrasing highlights its flexibility. This exceeds a vague statement but stops short of explicit guidance.

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

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

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?

Annotations already cover read-only/destructive hints, and the description adds useful context: it is powered by an external API and costs 3 MESH per call. However, it does not disclose whether the tool executes the plan or only returns it, nor any side effects on state, memory, or external systems.

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 quite short and front-loaded with the core purpose, but includes redundant 'Task Orchestrate —' and marketing-ish 'a tool · reasoning' text. The external API and pricing info are useful but could be more tightly integrated.

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

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

Given no output schema, the description does not explain what the execution plan looks like or how the agent should use the result. It also lacks guidance on how this relates to sibling tools like task-analysis or agent-brain, leaving the agent to infer integration and output expectations.

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 fully documents parameters. The description only restates 'Input: { task: string, tools: array }', adding no extra semantic detail about parameter usage, formatting, or relationships.

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

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

The description uses a specific verb+resource: 'Break a multi-step task into an execution plan any agent can follow.' This clearly conveys the core function. However, it does not differentiate from the sibling tool 'task-analysis', which may serve a similar planning/analysis role.

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

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

There is no explicit statement about when to use this tool versus alternatives, nor any exclusion criteria. The phrase 'multi-step task' only implies usage context, but no clear when/when-not 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 indicate readOnlyHint=false and openWorldHint=true, but the description doesn't clarify what side effects or external interactions might occur. It mentions the cost per call but doesn't describe the return format or behavior. The educational nature is implied but not substantiated with behavioral details beyond what the annotations suggest.

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

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

The description is relatively brief, with three sentences and a parenthetical, and it front-loads the core purpose. Some phrases like 'No jargon, no hype' add flavor but are not strictly necessary. Overall, it's well-structured 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?

The tool lacks an output schema, and the description doesn't explain what the return value looks like or how to format the input. The nested object parameter is unexplained. Given the minimal annotations, the description should compensate, but it leaves critical gaps, making the tool difficult to invoke correctly.

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

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

The only parameter 'input' has a schema description that is generic and references other tools (agent-brain, agent-memory), not this guide. The description of the tool itself provides no guidance on what to supply for this specific guide. This is highly confusing and leaves the agent without a clear way to construct valid input.

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

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

The description clearly states that the tool provides plain-language guidance on browser AI agents, covering how they work and how to get started. It specifies the topic and audience, making the purpose understandable. However, it lacks a direct action verb like 'returns' or 'explains', and doesn't differentiate from the sibling tool '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 implies use for people new to agentic tools who want straightforward information, but it doesn't provide explicit when-to-use or when-not-to-use guidance. It also doesn't mention alternatives among the sibling tools. The context is present but not fully developed.

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