Server Quality Checklist

Tool Scores

• task-orchestrateC
  2.9/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description mentions '3 MESH/call' pricing and credits 'api.meshtool.ai' as the backend, adding cost context. It also frames the output as 'an execution plan any agent can follow,' disclosing the result is a plan (not execution). However, it doesn't describe failure modes, timeouts, or what happens with ambiguous/underspecified tasks.

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

  Conciseness4/5

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

  Compact single-paragraph description with front-loaded purpose statement. The pricing note and attribution are concise additions. One minor inefficiency: the '·' separated tag 'a tool · reasoning' at the end is cryptic and adds little value.

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

  Completeness3/5

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

  No output schema exists, so description should explain what the returned plan looks like — it says 'execution plan any agent can follow' but doesn't specify format (steps? JSON? ordering constraints?). Pricing is disclosed which is helpful. For a tool with one nested-input parameter and clear schema, this is adequate but the output format gap is notable.

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

  Parameters3/5

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

  With 100% schema description coverage, baseline is 3. The schema already documents task (what needs to happen) and tools (tools/services available). The description adds 'array' type hint for tools but doesn't add semantic value beyond what schema provides. The optional context parameter is undocumented in both schema and description for meaning.

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

  Purpose3/5

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

  The description states it breaks a multi-step task into an execution plan, which is a specific verb+resource. However, it's somewhat generic and doesn't clearly distinguish from siblings like task-analysis or mesh_delegate — the difference between 'planning' (task-orchestrate) vs 'analyzing' (task-analysis) vs 'delegation' (mesh_delegate) is not articulated.

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

  Usage Guidelines2/5

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

  No guidance on when to use this vs alternatives. It notes input requirements (task, tools array) but doesn't explain scenarios where orchestration is appropriate versus when an agent should just execute directly, nor does it mention limitations or edge cases. The alternatives given by siblings are numerous but no exclusions or preferred contexts are stated.

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

• agent-memoryB
  3.1/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the description doesn't carry the full safety burden. The description adds the pricing note (2 MESH/call), which is useful cost transparency not in annotations. However, it doesn't clarify whether 'store' writes over existing memories, how scoping works, or what recall returns — leaving behavioral questions unanswered beyond what annotations already imply.

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

  Conciseness3/5

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

  The description is compact at roughly two sentences, but it includes marketing-style phrases ('The primitive shallow builders lack') and a pricing tag that, while informative, feels promotional and not technical. The core functional sentence is efficient, but the self-promotional framing takes space that could clarify behavior. Reasonably concise but not tightly structured.

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

  Completeness3/5

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

  For a two-action (store/recall) tool with a nested object, 100% schema coverage, and three annotations, the description covers the essentials but is thin on practical details. It doesn't say what recall returns (results format), whether storage is global or per-workspace, or how 'scoped' memory behaves. Given no output schema, the description should disclose more about what the agent can expect back from a recall call, making this incomplete but not inadequate.

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

  Parameters3/5

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

  Schema description coverage is 100% — the schema itself documents the 'query', 'action', and 'content' parameters with descriptions and the action enum. The description adds the insight that recall is 'by meaning' (semantic rather than keyword), which adds value beyond the schema. But the description doesn't deepen parameter understanding significantly; it's a baseline 3 with slight credit for the semantic-recall clarification.

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

  Purpose4/5

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

  The description states this is persistent, scoped memory for storing and recalling 'by meaning', which clearly identifies the purpose as a semantic memory store. It distinguishes itself from 'shallow builders' by contrast, though it doesn't name a specific sibling alternative. The verb 'store and recall' plus the resource 'agent memory' is clear enough.

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

  Usage Guidelines2/5

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

  The description implies when to use it (when you need persistent semantic memory) and contrasts with shallow builders, but it offers no explicit guidance on when NOT to use it or what alternatives exist among the many sibling tools (task-analysis, agent-brain, structured-extract). The 'scoped' mention hints at constraints but doesn't explain what scope means or how it differs from agent-brain or task-analysis.

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

• mesh_followB
  3.4/5.0
  Behavior4/5

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

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

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

  Conciseness4/5

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

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

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

  Completeness3/5

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

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

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

  Parameters2/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines3/5

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

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

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

• obs-migrateB
  3.4/5.0
  Behavior3/5

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

  Annotations are minimal: readOnlyHint=false (it performs a transform, consistent), openWorldHint=true, destructiveHint=false. The description adds 'Pure transform, instant' clarifying it's a non-destructive, synchronous operation. It also discloses 'Powered by api.meshtool.ai' indicating an external API dependency and '1 MESH/call' stating a cost metric. However, it doesn't explain whether the output is returned directly or stored, or what happens to files on failure. Some useful context beyond annotations, but modest.

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

  Conciseness4/5

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

  The description is compact at roughly two sentences plus usage metadata. It front-loads the core purpose, then adds cost/metric detail ('1 MESH/call') and API attribution. Every sentence earns its place, though the trailing '(a tool · tooling)' tag is arguably noise. Efficient overall.

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

  Completeness3/5

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

  For a stateless, single-input transform tool, the description mostly covers what's needed. However, there is no output schema, so the description should clarify the return format (e.g., does it return converted files? a manifest? errors on unsupported files?). The description doesn't address output shape, which matters given the input is a multi-file map and the transform is the entire point. The nested object structure and 1 required param keep complexity moderate, but the missing output contract is a notable gap.

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

  Parameters3/5

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

  Schema description coverage is 100% — the single 'input' param has an embedded description for 'files' (the required map) and 'rec_path' (Windows recording output path). The description adds brief context about the file types expected ('global.ini, basic.ini, scene JSON') which complements but doesn't substantially extend the schema. Since the description lists the same file types as the schema's files field, marginal added value; baseline 3 is appropriate.

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

  Purpose4/5

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

  The description states a specific verb+resource: 'Convert Mac OBS config files (global.ini, basic.ini, scene JSON) to Windows-compatible versions.' It clearly identifies what files are processed and the conversion direction (Mac→Windows). It doesn't explicitly distinguish from siblings, but none of the sibling tools perform config migration, so no differentiation is needed. The purpose is clear and specific.

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

  Usage Guidelines3/5

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

  The description implies when to use it (when migrating OBS configs from Mac to Windows) but doesn't provide explicit exclusions or alternate tool references. It mentions 'Pure transform, instant' suggesting a stateless conversion, but doesn't explain what happens to the original files or if there are prerequisites. The implied usage is clear from the domain-specific focus, but no explicit when/when-not guidance is given.

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

• task-analysisB
  3.4/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, which are somewhat contradictory for an analysis tool. The description does add context about MESH pricing (5 MESH/call) and labels it 'a tool · reasoning,' which is useful. The openWorldHint=true suggests it may perform actions beyond reasoning, which isn't clarified in the description.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the purpose. The pricing note and tool category label are brief additions that add useful context without bloat. The use of the em-dash style with the ASCII arrow formatting is a minor stylistic choice but doesn't hurt readability.

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

  Completeness3/5

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

  For a tool that produces a 'structured plan,' there is no output schema and the description only vaguely describes the output (typed steps, risks, a verdict). The nested input object with just one 'task' field is simple, but the agent has limited understanding of what constitutes a well-formed response or how to interpret the verdict. Given the openWorldHint annotation, more clarity on side effects would help.

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

  Parameters3/5

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

  Schema coverage is 100% with a single 'input' object containing a 'task' field. The description adds the concept of producing typed steps, risks, and verdict but doesn't detail the required input structure beyond what the schema already provides. The description does nothing to help the agent understand how to format the task input.

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

  Purpose4/5

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

  The description clearly states the tool takes a task and produces a structured plan with typed steps, risks, and a verdict. This is a specific and descriptive statement of purpose using a 'hand a task, get a structured plan back' idiom. However, it doesn't explicitly distinguish itself from the sibling 'task-orchestrate' tool, which likely has overlapping functionality.

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

  Usage Guidelines3/5

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

  The description implies the tool is for analyzing tasks and producing plans, but it doesn't state when to use this vs. alternatives like task-orchestrate or agent-brain. No explicit when/when-not guidance is provided, leaving the agent to infer appropriate usage from the sibling tool names.

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

• character-forgeA
  3.5/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false (it's a mutating/generating action producing a cost) and openWorldHint=true (broad outputs). The description does mention the cost (25 MESH/call) and that it runs on serverless silicon, which adds useful operational context. However, it doesn't disclose behaviors like rate limits, GPU queue wait time, image size/resolution defaults, or what happens if the prompt fails content moderation.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the purpose ('Generate an image'), then adds the differentiating detail (own GPU / FLUX / serverless silicon), the output promise (permanent image URL you own), and cost info. It's efficient at ~50 words with minimal filler, though the trailing tag 'a tool · media' and the playful 'not just the market' phrasing add minor noise.

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

  Completeness3/5

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

  Given openWorldHint=true and the generative nature of the tool, the description covers purpose, output format (permanent URL), cost, and compute location. However, with no output schema and no disclosed details about image dimensions, resolution, generation time, or moderation behavior on unsafe prompts, there are notable gaps an agent might need for reliable invocation and expectation-setting.

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

  Parameters4/5

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

  With only 1 required parameter (prompt) and 100% schema description coverage, the schema already documents the prompt field clearly ('what to draw — describe the character or scene'). The description reinforces this by saying 'describe a character or scene'. There's minimal additional semantic value needed since the schema fully covers the single parameter; the description aligns with it.

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

  Purpose4/5

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

  The description clearly states the tool generates an image on the mesh's own GPU using FLUX, from a text prompt describing a character or scene. The verb-resource pair (generate image / describe character) is specific. It doesn't explicitly distinguish from sibling cam-forge, but the FLUX/silicon detail and unique positioning make the purpose reasonably distinct.

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

  Usage Guidelines3/5

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

  The description tells the user to 'describe a character or scene' and implies this is a text-to-image generation tool. However, it does not give explicit when-to-use or when-not-to-use guidance versus alternatives like cam-forge, nor does it mention any input constraints such as prompt length, style guidance, or image aspect ratio to receive good results.

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

• mesh_profileA
  3.5/5.0
  Behavior3/5

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

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

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

  Conciseness4/5

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

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

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

  Completeness3/5

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

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

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

  Parameters4/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines3/5

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

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

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

• mesh_subscribeA
  3.5/5.0
  Behavior3/5

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

  Annotations show destructiveHint=true and readOnlyHint=false, and the description aligns with these (subscription creation/deletion is a state-changing operation). The HMAC-signed delivery note adds useful security context. However, the description doesn't disclose that delete is destructive, that URL must be publicly reachable (vs localhost), or behavior like overwriting existing subscriptions for the same URL. With annotations present, a 3 is fair—it adds context but not deep behavioral detail.

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

  Conciseness4/5

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

  Two sentences, front-loaded with the core purpose and concrete event examples, ending with the HMAC signature note. It's efficient and readable. Minor deduction: the event examples and the HMAC note could arguably be merged, but overall it's appropriately sized with no filler.

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

  Completeness4/5

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

  For a tool with 4 params, 75% schema coverage, no output schema, and a destructive-hint annotation, the description covers purpose, event types, and delivery security well. It's complete enough to understand what the tool does and what events it handles. It doesn't describe return/confirmation behavior, but with no output schema, the description could arguably note that listing returns subscriptions—though this is a minor gap given overall clarity.

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

  Parameters3/5

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

  Schema description coverage is 75%, so the schema already documents url, id, and events reasonably well. The description adds context about what 'events' mean by giving examples of event types. However, it doesn't clarify the 'action' parameter semantics (create/list/delete) in prose, nor the id requirement for delete, nor that omitting events subscribes to all. Schema does moderate work, so baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool wires webhooks to live mesh events, listing three concrete event types (call.settled, vibe.followed, capability.listed) with human-readable context for each. The verb 'wire' + 'webhook' + 'live mesh events' is specific and distinct from sibling creation tools. It loses a point for not naming the tool as subscribe/manage directly or noting it also handles listing/deleting subscriptions beyond creation.

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

  Usage Guidelines3/5

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

  The description explains what events the webhook receives and mentions HMAC-signed deliveries, but does not specify when to use this tool vs alternatives. It lacks exclusions or guidance on prerequisites (e.g., needing a registered node), and doesn't contrast with a poll-based or other delivery mechanism. Sibling names like mesh_follow, mesh_publish, mesh_refer suggest related but distinct actions, yet no when-to-use or when-not-to-use distinction is offered.

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

• structured-extractA
  3.5/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds that it costs 2 MESH/call and is powered by api.meshtool.ai, which is useful cost/source context. However, it doesn't disclose error behaviors, rate limits, or what happens with unsupported JSON shapes — the annotations already cover the safety profile, so the addition of cost info gives modest value.

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

  Conciseness4/5

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

  The description is a single compact sentence plus a compact 'Input:' note with the parameter list and cost. It front-loads the core purpose and packs cost, source, and input structure efficiently. Minor noise from '(a tool · extraction)' trailing label, but overall efficient.

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

  Completeness4/5

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

  The tool's purpose is simple (text + shape in, structured data out), annotations cover the safety profile, and schema coverage is full. The description covers the input contract and cost. Without an output schema, the description could clarify return behavior more, but for a straightforward extraction tool with 100% schema coverage, it is reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both 'text' and 'shape' parameters documented in the schema. The description adds that text is 'string' and shape is 'object' with the expected semantic meaning, but doesn't add beyond what the schema provides. Given full schema coverage, baseline 3 is appropriate.

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

  Purpose4/5

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

  The description states the tool extracts structured data out of free text into a user-defined JSON shape, mentioning classification, field extraction, and scoring. This clearly states the verb (extract/pull), resource (free text), and output (JSON shape). It distinguishes broadly from sibling tools like agent-memory or task-analysis, though it doesn't 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.

  Usage Guidelines3/5

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

  The description clearly shows it's for pulling structured data out of free text and lists the required inputs (text and shape). It implies usage for text-to-structured-data conversions but doesn't explicitly state when NOT to use it or name alternative tools for different scenarios (e.g., classification vs extraction vs scoring). No exclusions or alternatives are given.

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

• biz-analyzeA
  3.6/5.0
  Behavior3/5

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

  Annotations declare openWorldHint=true, readOnlyHint=false, destructiveHint=false. The description adds the cost context (2 MESH/call) which is useful, and clarifies it's a reasoning/analysis tool. However it doesn't disclose what the 'structured recommendation' looks like (does it return a plan, a decision tree, a cost-benefit table?), whether follow-up refinement is possible, or whether the output supports multiple passes. With annotations present covering the safety profile, the description adds moderate value but could state more about the recommendation format.

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

  Conciseness4/5

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

  The description is a single dense sentence that front-loads the core purpose, includes the cost, input format, and heritage context (original api.meshtool.ai capability). Each phrase earns its place, though the '(2 MESH/call, a tool · reasoning)' suffix is somewhat meta/noisy and could be trimmed. Still, it's compact and efficient.

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

  Completeness3/5

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

  The tool takes freeform business context and returns an unstructured recommendation with no output schema. Given the open-ended nature, the description reasonably covers the main use case. However, it doesn't clarify whether the recommendation is a single definitive answer or a multi-step plan, when a simpler sibling (like task-analysis) might be preferred, or what quality/citation guarantees exist. For a generic analysis tool, this is adequate but could add boundary guidance.

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

  Parameters3/5

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

  Schema coverage is 100% (only 1 top-level param, 'input', well documented with its nested goal/context/constraints fields). The description adds value by clarifying required input is 'context: string' in plain language. However, the description only mentions the required context field and doesn't explain the optional goal and constraints parameters, which are already documented in the schema. With full schema coverage, baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb ('Analyze') plus resource ('any business situation') and clearly explains the output ('get a structured recommendation back'). It also names the input format (context: string) and the cost (2 MESH/call). This distinguishes it from siblings like task-analysis, agent-brain, and structured-extract, which handle other analytical purposes.

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

  Usage Guidelines3/5

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

  The description implies use for business-situation analysis with the phrase 'Analyze any business situation,' and the sibling context shows many situation-specific tools (pos-rescue, merchant-discovery), but no explicit when-to-use vs alternatives guidance is provided. It does not state when NOT to use this tool or mention alternatives, leaving the agent to infer from the 'any business situation' phrasing.

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

• instant-receptionistA
  3.8/5.0
  Behavior4/5

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

  The description discloses key behavioral traits beyond annotations: it costs 3 MESH per call, requires no account/card/phone number, and returns a live URL. These details add meaningful context and align with the openWorldHint=true annotation, with no contradiction.

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

  Conciseness3/5

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

  The description is somewhat repetitive, starting with the title phrase 'Instant Receptionist — a working app in one call' and then repeating similar wording. It is a single long sentence with multiple clauses and parentheses, which could be streamlined for clarity.

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

  Completeness4/5

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

  Given the lack of an output schema, the description does a good job explaining the output (a live URL) and the key input expectations. It also covers cost and prerequisites. However, details about ongoing behavior, cancellation, or data lifetime are absent, which would make it more complete.

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

  Parameters3/5

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

  The input schema only provides a generic 'Capability-specific payload' description, which is not helpful. The tool description mentions giving 'a business name, trade and area,' which adds some meaning, but it does not specify exact field names or structure, leaving ambiguity.

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

  Purpose5/5

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

  The description clearly states the tool orders a working, branded AI receptionist and returns a live URL. It identifies a specific verb ('Order') and resource ('branded AI receptionist'), distinguishing it from sibling tools like agent-brain or biz-analyze.

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

  Usage Guidelines3/5

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

  The intended use case is implied: use this tool when you need a ready-made AI receptionist for a business. However, it does not explicitly contrast with alternatives or state when not to use it, leaving room for clearer guidance.

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

• searchA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is established. The description adds value by noting 'free, no key needed' — a behavioral affordance (no auth required) not captured in the annotations. It also scopes the search domain (Exchange capabilities for rent), which helps the agent understand what results to expect. Description is consistent with annotations.

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

  Conciseness5/5

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

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

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

  Completeness4/5

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

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

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

  Parameters3/5

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

  Schema coverage is 100%, with the single 'query' parameter described as 'what you're looking for'. The description's mention of 'memory, reasoning, safety, images, commerce' adds domain vocabulary that hints at valid query types, giving slight value beyond the schema. However, it doesn't clarify match semantics (fuzzy vs exact, keyword vs natural language) which would help an agent formulate queries effectively.

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

  Purpose4/5

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

  The description clearly states what the tool does: search the MeshMarket exchange for rentable capabilities. It specifies a verb (search), a resource (MeshMarket exchange), and the scope (capabilities agents can rent across memory, reasoning, safety, images, commerce). The main gap is that it doesn't explicitly differentiate from siblings like mesh_discover or merchant-discovery, though the exchange-specific search intent is reasonably distinct.

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

  Usage Guidelines3/5

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

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

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

• safety-scrubA
  3.9/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds useful context: 'Best-effort, not a guarantee' (honest limitation), 'Pure pattern matching, no AI call' (no side effects/API cost), and '(1 MESH/call)' cost estimate. It does not fully detail edge behaviors like what happens with borderline patterns or performance on large text, but with annotations carrying the safety profile, this is adequate.

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

  Conciseness4/5

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

  The description is compact and well-front-loaded, with the core purpose in the first clause. It packs the data-type list, output contract, limitations, and cost into a dense but readable block. Slightly crowded with the trailing meta fields ('a tool · safety', '1 MESH/call'), but no wasted words overall.

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

  Completeness4/5

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

  For a single-param, no-output-schema tool with 100% param coverage, the description covers the essentials: what data types get scrubbed, the output shape, and the best-effort caveat. The lack of output schema means the return-format explanation (scrubbed/redacted/kinds with example) is genuinely valuable. No significant gaps for a tool of this complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the single param (input.text) is fully documented in the schema. The description restates the text param ('Input: {text: string}') and lists return fields (scrubbed, redacted, kinds) with an example. It adds little beyond schema but does clarify the exact redaction behavior. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states a specific verb+resource: 'Redact sensitive data from text before logging it.' It names exact data types (card numbers, SSNs, API keys, JWTs, PEM keys) and output markers ([REDACTED-*]). It distinguishes from AI-based scrubbing by explicitly noting 'Pure pattern matching, 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.

  Usage Guidelines4/5

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

  It provides clear when-to-use guidance ('Use whenever user-supplied or scraped text may carry credentials') and notes the scoping constraint ('before logging it or sending it to a model'). However, it lacks explicit when-NOT-to-use guidance or named alternatives from the sibling set, relying on implicit context.

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

• fetchA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful context about what the record contains (costs, provider, reliability metrics), which is informative. It doesn't describe response size, pagination, or failure behavior, but for a single-record fetch with read-only annotations, this is acceptable.

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

  Conciseness5/5

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

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

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

  Completeness4/5

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

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

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

  Parameters3/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

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

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

• industry-vocabularyA
  4/5.0
  Behavior5/5

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

  The description adds substantial behavioral context beyond annotations: it is deterministic, makes no model call, answers in milliseconds, cannot fail on an upstream, and explicitly reports whether it matched a real vertical or fell back to generic. It also mentions cost (1 MESH/call). These are valuable operational details not present in the annotations.

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

  Conciseness4/5

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

  The description is front-loaded with the core purpose in the first sentence, followed by efficiency, reliability, and cost details. It is reasonably concise, though the parenthetical '(1 MESH/call, a tool · business)' adds some clutter. Every sentence contributes meaningful information.

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

  Completeness3/5

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

  The description covers the tool's output (industry terms, match/fallback status) and performance characteristics, but given there is no output schema and the input schema is generic, the ambiguity about input format is a gap. For a tool with one simple input, the description is nearly complete, but the object/string mismatch makes it incomplete.

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

  Parameters3/5

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

  The input schema has one parameter with a generic, tool-agnostic description ('Capability-specific payload...'), which offers no specific meaning. The tool description adds that the input should be a trade or industry in plain words, but it does not resolve the mismatch between the schema (object type) and the description (plain words), leaving ambiguity about the exact expected structure. The description partially compensates for the schema's lack of specificity but not fully.

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

  Purpose5/5

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

  The description clearly states the tool's function: taking a trade/industry in plain words and returning the industry-specific language (caller, appointment, provider, qualification questions). It uses a specific verb ('hand it') and resource ('industry-vocabulary') and distinguishes itself from siblings like agent-memory or task-analysis by focusing on industry terminology.

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

  Usage Guidelines3/5

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

  The description implies usage ('Hand it a trade or industry') but does not explicitly state when to use it versus alternatives or when not to use it. There is no mention of exclusions or comparison with sibling tools, so the guidance is inferred from the purpose rather than explicit.

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

• mesh_balanceA
  4/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, and the description does not contradict that. It adds useful content context (balance, activity, provenance) but does not disclose additional behavioral traits such as auth requirements, rate limits, or data freshness.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the core subject and then clarifies the breakdown. Every phrase adds value without filler.

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

  Completeness4/5

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

  For a parameterless read-only tool, the description sufficiently covers what the user gets: balance, recent activity, and provenance. The phrase 'recent activity' is somewhat vague, but the overall scope is simple and the annotations provide safety context.

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

  Parameters4/5

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

  The tool takes zero parameters, and the input schema has no properties, so parameter semantics are trivially complete. The description does not need to explain parameters, and the baseline of 4 is appropriate.

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

  Purpose5/5

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

  The description clearly identifies the resource (MESH credit balance) and what it reports: recent activity and a provenance breakdown (earned vs purchased vs promotional). Although there is no explicit verb, the phrasing makes the read/query purpose unambiguous and distinguishes this tool from sibling tools focused on other MESH actions.

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

  Usage Guidelines3/5

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

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

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

• mesh_signupA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false, but the descriptions adds important context: free/closed-loop credits, 'no payment method involved or attachable', 'no authentication needed', and the one-time key return behavior. This significantly clarifies what side effects and constraints exist beyond what annotations convey.

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

  Conciseness4/5

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

  The description is reasonably compact for the amount of critical setup information it conveys (key handling, no payment, bearer token setup). It front-loads the core purpose and adds operational detail. Slightly dense but every sentence adds value.

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

  Completeness4/5

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

  For a 2-param tool with 100% schema coverage and no output schema, the description covers the essential user-facing workflow: claims handle, receives one-time key, setup instructions. It explains the referred_by param's optionality. It could be slightly stronger on what happens if the handle is already taken, but for a free signup tool this is adequate.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both params (handle, referred_by). The description adds value by explaining the meaning of referred_by ('the ref code of the node that vouched you in') which matches the schema. Baseline 3 is appropriate since the schema carries the documentation load.

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

  Purpose5/5

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

  The description states a specific verb+resource: 'Join the mesh — with your user's knowledge: claim a handle and get an agent key + starter MESH.' It clearly distinguishes this signup tool from siblings like mesh_profile, mesh_balance, and others. The title 'Join the Mesh (free signup)' reinforces the purpose precisely.

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

  Usage Guidelines4/5

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

  The description explains when to use this tool — to sign up, with no authentication needed, and provides clear setup guidance for what the agent should do with the returned key (show to user, save it, set as Bearer token). It doesn't explicitly name when NOT to use it or list alternatives, but for a signup tool that's an acceptable gap given the unique purpose among siblings.

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

• personalizeA
  4.1/5.0
  Behavior4/5

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

  Annotations declare openWorldHint=true (an open-world tool that can create new entities) and destructiveHint=false, readOnlyHint=false. The description adds meaningful behavioral context: it explains the tool is 'proxied to api.meshtool.ai' and notes a cost of '2 MESH/call', which is helpful operational transparency. It also clarifies the tool doesn't compute the choice itself but delegates to an 'upstream model.' This adds value beyond the annotations.

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

  Conciseness4/5

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

  The description is appropriately sized at roughly three sentences, front-loaded with the core purpose before diving into parameters and implementation details. The parameter list adds practical value rather than padding. Minor redundancy exists where the parameter descriptions partially duplicate what the schema already covers, but overall it's efficient and well-organized.

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

  Completeness4/5

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

  Given the tool has no output schema, the description provides enough context about the expected interaction model (send user info + candidates, get back a selected/framed option). It documents all parameters, cost, and proxying behavior. For a moderately complex tool with nested objects, the description covers the key decision points an agent needs. It could note output format or error handling, but these gaps are minor given the simplicity of the tool's contract.

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

  Parameters3/5

  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 all three required parameters (profile, content, goal). The description adds marginal value by briefly restating each parameter's purpose ('profile: object — what you know about the user; content: string[] — options to choose from; goal: string — what to optimize'). The goal parameter gets an example in both schema and description ('maximize trial signup'). While these reinforce the schema, the description doesn't meaningfully extend it with formatting details or edge cases, so a baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Choose which content to show a specific user and how to present it.' It specifies the action (personalize content), the resource (specific user), and the mechanism (upstream model picks and frames the best fit). It also provides a concrete use-case: 'Use when an agent must pick one message, offer, or variant per user instead of a generic default.' This distinguishes it from generic output tools among siblings.

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

  Usage Guidelines4/5

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

  The description explicitly says when to use: 'Use when an agent must pick one message, offer, or variant per user instead of a generic default.' It provides clear context for appropriate usage. However, it does not explicitly name alternative tools or explain when NOT to use it beyond the implication that it's for per-user selection rather than generic defaults.

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

• merchant-discoveryA
  4.2/5.0
  Behavior4/5

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

  Discloses it's a proxy (proxied to Grand Reserve), costs 3 MESH/call, and that 'the mesh never sells' — clarifying the referral-only business model. Annotations provide openWorldHint=true and destructiveHint=false but not readOnlyHint, so description's disclosure of the mesh proxy and pricing adds real value beyond structured data. Could add rate-limit or auth behavior, but the core traits are well disclosed.

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

  Conciseness5/5

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

  Single dense paragraph, front-loaded with the core value proposition, followed by concrete input/output schemas and proxy/cost info. Every sentence adds information — no filler. The inline code-style object shapes are efficient and scannable.

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

  Completeness4/5

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

  For a complex tool (nested objects, no output schema, proxied mesh call), the description covers the input contract, the card return shape with all fields, the proxying target, and pricing. The output shape explanation compensates for the absence of an output schema. Minor gap: no error/edge-case behavior, but reasonably complete for this complexity level.

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

  Parameters3/5

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

  Schema coverage is 100% (only 'input' parameter), but the schema's own description of 'input' is generic ('Capability-specific payload') and unhelpful. The tool description fills this gap by specifying the actual shape: {message: string, prefs?: object} and the return structure with cards fields. This is valuable meaning beyond the generic schema, though still somewhat thin on parameter format details.

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

  Purpose5/5

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

  The description clearly states it answers natural-language questions about wine/cigars/spirits and returns curated picks with live inventory, prices, ratings, and buy links. It distinguishes itself from siblings like search, fetch, and mesh_discover by framing it as an 'AI sommelier' that curates across a mesh of merchant servers. Named as 'Discovery and referral only' which clarifies its unique cap.

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

  Usage Guidelines4/5

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

  The description explains what domain it applies to (alcohol products) and that it's a discovery/referral tool that deep-links to merchants' sites, not selling directly. It doesn't explicitly name alternative tools for when NOT to use it, but the domain specificity and mesh-proxy context imply clear usage. Slight gap: no explicit alternative naming, but context is adequate.

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

• mesh_delegateA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=false and destructiveHint=true, so the mutating/revoking nature is already covered. The description adds meaningful behavioral context beyond annotations: the CALL-ONLY restriction, the capability allowlist mechanism, and the daily MESH spend cap. It doesn't state what happens to active delegated keys on revoke, but given annotations already flag destructiveness, this adds good supplementary value.

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

  Conciseness5/5

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

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

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

  Completeness4/5

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

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

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

  Parameters3/5

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

  Schema coverage is 80% with 5 parameters, all already described inline in the schema (id for revoke, allow for capability slugs, label as purpose, action enum, daily_cap for MESH spend). The description reinforces the allow/cap semantics ('capabilities you allow', 'capped at a daily MESH spend') but adds little beyond what the schema provides. Baseline 3 is appropriate given high schema coverage.

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

  Purpose5/5

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

  The description states a specific verb set (Mint, list, or revoke) with a specific resource (CALL-ONLY delegated keys), and clearly delimits what the sub-key can and cannot do ('can't list, buy, refer, or mint further keys'). It also differentiates from siblings like mesh_refer and mesh_publish by framing this as an agent-hires-agent delegation mechanism. The key's restricted nature is made explicit.

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

  Usage Guidelines4/5

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

  The description conveys when to use this tool—when handing a sub-agent a restricted key—and describes the security context (sub-key limited to allowed capabilities and daily spend cap). It doesn't explicitly name a sibling alternative or state when NOT to use it, but the unique delegation purpose sits clearly apart from the sibling tools, which are mostly account/profile operations. No explicit exclusions, hence slightly below 5.

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

• pos-rescueA
  4.2/5.0
  Behavior4/5

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

  The description adds meaningful behavioral context: it discloses the tool is a diagnostic/consultative service (not a direct action), notes the pricing ('5 MESH/call'), and hints it's part of the broader tool-a-commerce ecosystem. With annotations declaring readOnlyHint=false and openWorldHint=true, the description complements rather than contradicts them. It doesn't detail failure modes or edge cases but is appropriate for a diagnostic tool.

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

  Conciseness5/5

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

  The description is a single, dense paragraph that front-loads the value proposition and enumerates outputs in a compact list. No wasted words—every phrase contributes (the vendor list, the deliverables, the pricing, the workaround angle).

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

  Completeness4/5

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

  For a 3-field nested payload with 100% schema coverage and no output schema, the description sufficiently sets expectations: it frames what problems it solves, what deliverables it produces, and the ecosystem context. The workaround mention ties it to related tools. It could name sibling tools explicitly, but is otherwise complete for its complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both 'pos' and 'trouble' parameters, including the 'pos' format hints and the exclusivity enum semantics with its 'fails closed' note. The description adds the workflow context (what you get back) but adds no parameter-specific detail beyond the schema; baseline 3 is correct.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: helping users stuck on POS integrations (Toast, Square, Clover, Micros) get a diagnosis, step-by-step plan, and workflow applicability. It names specific resources and a distinct output ('diagnosis, plan, workaround check') that distinguishes it from sibling tools like direct-checkout or install-matrix.

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

  Usage Guidelines4/5

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

  The description tells users when to use it ('stuck on a POS integration') and what to provide ('describe the trouble'). It also signals the diagnostic-plan-workaround output. However, it doesn't explicitly exclude alternatives or name direct-checkout as the sibling to pick for the actual checkout path, though 'whether the owner-direct checkout workaround applies' implies that relationship.

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

• cam-forgeA
  4.3/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds substantial behavioral context: guarantees wall thickness by construction, watertight STL with signed-volume integrity check, non-watertight results FAIL with mesh refunded, deterministic same-bytes output, and over-cap request rejection. The only gap is it doesn't disclose the 15 MESH/call cost or auth requirements beyond the cost line in parentheses.

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

  Conciseness4/5

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

  The description is information-dense but well-organized: opens with the core value proposition, then behavioral guarantees, use cases, parameters, caps, and return format. It front-loads the key action (generative fabrication tool) and packs substantial detail into a compact block. Slightly long but every sentence carries distinct information.

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

  Completeness4/5

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

  For a 1-nested-parameter, complex tool with 100% schema coverage, the description covers purpose, guarantees, failure modes, caps, return shape, and use cases. No output schema exists, so it handily lists the return fields (format, encoding, content, volume_check, stats, params). It could add the 15 MESH/call pricing detail more explicitly rather than as a parenthetical aside.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema documents all parameters well. The description adds aggregate context (all input in mm, default values, coordinate meanings like density fraction and jpos organic look) but the per-parameter detail lives in the schema. This is the baseline-3 scenario where the schema does the heavy lifting and the description supplements with overall ranges and semantics.

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

  Purpose5/5

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

  The description has a very specific verb+resource: 'Turn parameters into a manufacturable file' for fabrication, listing exact output formats (STL, DXF, SVG) and use cases (vent panels, speaker grilles, acoustic diffusers). It clearly distinguishes from siblings like character-forge and mesh_follow by emphasizing kernel-free parametric fabrication output.

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

  Usage Guidelines5/5

  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 for vent panels, speaker grilles, acoustic diffusers, lattice infill plates, decorative screens') and lists hard caps (<=600 cells, <=60000 triangles) with rejection behavior. It also notes deterministic output and no model call, clarifying it's a parametric generator rather than a mesh-altering tool like mesh_follow.

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

• direct-checkoutA
  4.3/5.0
  Behavior4/5

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

  Despite annotations already declaring readOnlyHint=false and openWorldHint=true, the description adds meaningful behavioral value: it clarifies the cost (3 MESH/call), the architectural model (owner-direct, mesh never touches funds), and that it returns a hosted payment link. The openWorldHint=true is reinforced by the description's emphasis on the external Stripe integration. No annotation contradiction present.

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

  Conciseness4/5

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

  The description is compact and front-loaded, leading with the tool purpose and core value proposition in the first sentence. The parenthetical (3 MESH/call, a tool · commerce) adds useful metadata but is slightly cluttered. No wasted sentences, but the format is a bit informal/marketing-toned which slightly detracts from precision.

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

  Completeness4/5

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

  For a single-parameter tool with complete schema coverage, the description adequately explains the purpose, cost model, security model, and output (hosted payment link). No output schema exists, so the description's statement about returning a payment link is important and present. It could potentially mention failure modes (invalid Stripe key) but is reasonably complete for this tool's complexity.

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

  Parameters4/5

  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 clarity beyond the schema by emphasizing the security posture of passing YOUR OWN Stripe key (bolded, repeated in both description and schema), reinforcing the critical safety property of the stripe_key parameter. The amount_cents and description parameters are self-explanatory integers/strings, though the description doesn't add much beyond schema for those.

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

  Purpose5/5

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

  The description clearly states the tool creates a hosted Stripe payment link using the owner's own Stripe key, with the mesh never touching funds. It explicitly positions this as the POS-contract-safe way to take online and QR orders, distinguishing it from other commerce tools like pos-rescue and merchant-discovery.

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

  Usage Guidelines4/5

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

  The description clearly explains when to use this ('the POS-contract-safe way to take online and QR orders') and highlights the key safety benefit (guests pay the owner directly, mesh never touches money). It doesn't explicitly name alternatives or exclusion criteria, but the commerce-specific framing among siblings like pos-rescue and merchant-discovery provides reasonable distinction.

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

• mesh_referA
  4.3/5.0
  Behavior4/5

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

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

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

  Conciseness4/5

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

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

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

  Completeness4/5

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

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

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

  Parameters4/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

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

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

• mesh_discoverA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the free/keyless framing aligns and adds context. Description adds behavioral detail beyond annotations: 'top 60' ordering, that it returns a specific shape, and that capability calls are paid while this discovery call is free. Minor gap: doesn't describe pagination, but the top-60 cap makes that moot.

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

  Conciseness4/5

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

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

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

  Completeness5/5

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

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

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

  Parameters3/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines5/5

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

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

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

• install-matrixA
  4.5/5.0
  Behavior4/5

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

  Annotations declare openWorldHint=true, readOnlyHint=false, destructiveHint=false. The description adds meaningful behavioral context beyond these: 'Deterministic, no model call' clarifies it's not generative/AI-dependent, and it discloses the exact return shape (clients array with method, snippet, config_path?, notes?). It also reveals edge-case handling (Antigravity name normalization), which is valuable transparency.

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

  Conciseness4/5

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

  The description is dense but well-structured: it front-loads the primary action and value proposition, then gives usage context, then input/return shape. It's on the longer side but every sentence carries information — client quirks, determinism, defaults, and return format all justify their presence. Slight redundancy between schema param examples and description examples, but minor.

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

  Completeness4/5

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

  The tool is moderately complex (nested input object, multiple output variants), and the description covers the action, output shape, parameter semantics, and special case handling. Without an output schema, describing the return structure ({clients:[...], count}) is helpful. It could add more on error cases or what happens with unsupported transports, but given 100% schema coverage and a clear description, this is adequate.

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

  Parameters4/5

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

  Schema description coverage is 100%, with detailed per-parameter descriptions (e.g., server_url required URL, name normalization to lowercase a-z0-9 for Antigravity, auth enum meanings). The description adds value by mapping parameters to behavior: transport defaults to streamable-http, auth bearer variants add Authorization headers. It also documents default behaviors (name derived from URL host) beyond what the schema states.

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

  Purpose5/5

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

  The description uses a specific verb ('Generate') with a clear resource (MCP install snippets for ~29 clients) and explicitly states the tool's unique value: per-client config-key traps already encoded. It distinctively differentiates itself from siblings by naming exact client quirks (Antigravity, Gemini CLI, AnythingLLM, etc.) and defining the deterministic no-model-call property.

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

  Usage Guidelines5/5

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

  Explicit 'Use when' guidance is given: 'when you or your user needs to wire ANY MCP server into a client without hunting per-client docs.' It clearly scopes the use case and differentiates from alternatives by noting the value proposition over manual doc-hunting. The when-not/exclusion case isn't explicitly stated, but the use case is concrete enough that exclusions are implied.

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

• mesh_publishA
  4.6/5.0
  Behavior5/5

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

  The description discloses several behavioral traits not captured by annotations: craft privacy ('stays private'), notification side-effect ('followers are notified'), execution model ('house model runs it'), proxy behavior for endpoints, and earning mechanism. This goes well beyond the all-false annotations.

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

  Conciseness5/5

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

  The description is concise (5 sentences) but densely informative. It front-loads the core purpose, then uses a clear 'EITHER... OR' structure for the main mode choice, followed by side-effects and prerequisites. No filler.

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

  Completeness4/5

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

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

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

  Parameters4/5

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

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

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

  Purpose5/5

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

  The description clearly states the action ('List YOUR OWN tool on the exchange') and the benefit ('earn MESH'), distinguishing it from siblings like mesh_discover (browsing) and mesh_signup (key minting). The verb and resource are specific and unambiguous.

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

  Usage Guidelines4/5

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

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

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

• agent-brainA
  4.7/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false — the description adds meaningful context: that the tool writes up to 3 new memories back (mutation behavior), mentions the 8 MESH/call cost, and describes the full return fields. It adds value beyond annotations by explaining the memory-writeback side effect and pricing.

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

  Conciseness5/5

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

  Single dense paragraph, front-loaded with purpose, includes a worked example, cost, sibling differentiation, input/output summary and return fields — no wasted words. Every sentence earns its place, though it is information-dense.

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

  Completeness5/5

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

  Complete for a tool with a single parameter and no output schema: describes input, output fields, memory behavior, cost, and usage distinction. No output schema exists, so it appropriately enumerates return fields ({answer, reasoning, confidence, memories_considered, used_memories, learned, model}).

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

  Parameters4/5

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

  Schema coverage is 100% and the description adds semantic context for the 'think' parameter by explaining the flow (memories recalled first, conclusions stored automatically). The description reinforces schema meaning rather than duplicating it, which is appropriate given full coverage.

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

  Purpose5/5

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

  The description clearly states the tool reasons over a question with persistent memory: recalls memory, reasons with Claude, writes back new memories. It specifically distinguishes from sibling 'agent-memory' which 'covers plain store/recall', and names sibling 'mesh_profile' as context. The verb+resource+scope is very specific.

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

  Usage Guidelines5/5

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

  Explicitly states when to use ('decisions that should build on what the agent already knows') and explicitly distinguishes from the alternative ('agent-memory covers plain store/recall'), naming the sibling tool. This is textbook usage guidance with an explicit when-to-use and alternative.

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