Zambo AI Tools

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

With no annotations, the description carries the burden and it discloses relevant operational details: output is machine-readable, returns a specific set of sections, and rate limits are stated ('5 free/day. Zambo Pass: unlimited'). It does not explicitly state whether this invocation has side effects or costs beyond the quota, but the free-tier and read-only caution provide useful context.

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

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

The core statement is front-loaded, followed by structured sections for returns, use cases, limits, and when-to-use/when-not-to-use. A few phrases are promotional ('Instantly gives any agent expert context on anything') and the 'when user's request matches this capability' line is near-tautological, but overall the length is justified.

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

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

The description covers what the tool returns, when to use it, when not to, and the free usage limit, and an output schema exists to carry return-format details. It could be more explicit about authentication or side effects, but for selecting and invoking the tool the essentials are present.

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

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

Schema description coverage is 100%, so the schema already documents topic, url, depth, and focus. The description adds broader context about what a briefing contains but does not add parameter-level meaning beyond the schema. Baseline 3 is appropriate.

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

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

The first sentence identifies a specific action and object: 'Generate a comprehensive machine-readable structured briefing on any URL, product, company, API, codebase, or topic.' It also lists the exact output categories (capabilities, endpoints, pricing, etc.), so an agent can infer what the tool produces. It doesn't explicitly differentiate from siblings like zambo_brief or zambro_analyze, so it stops short of a 5.

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

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

The description gives concrete contexts ('onboarding a new agent to a codebase, competitive intelligence, understanding any API before calling it') and explicit when-not-to-use rules ('unrelated work, missing required inputs, or when a safer read-only route is more appropriate'). It does not name a specific sibling alternative, so the guidance is clear but not fully alternative-based.

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

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

No annotations are provided, so the description carries the full burden. It discloses meaningful payment behavior: exact payments trigger immediate handoff, while escrow records delivery confirmation for manual settlement review. It does not mention that a hire involves an on-chain USDC payment, that listing creates a public listing, or what side effects each action has beyond the payment mechanics.

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

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

The description is reasonably brief but contains redundancy: 'Browse, hire, or list agents' is stated twice in slightly different forms. The 'When to use' portion is somewhat generic filler. It is well-organized with the main purpose first, but it could be tightened without losing value.

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

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

Given the tool's complexity—15 parameters, three actions, and a payment-retry flow—the description gives the high-level marketplace and payment context, and the rich schema descriptions fill in parameter sequencing (e.g., listing_id from browse, hire_id from a 402 challenge). The main gap is an explicit end-to-end flow explanation, but the schema compensates significantly, and an output schema exists.

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

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

Schema description coverage is 100%, and each schema property already includes per-action context (e.g., 'For hire:', 'For list:', 'For hire payment retry:'). The description itself adds little parameter-level meaning, so the baseline of 3 applies. It does not need to compensate for schema gaps because there are none.

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

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

The description opens with specific verbs and a resource: 'Browse, hire, or list agents on the Zambo Agent Marketplace.' It clearly identifies the three modes and adds marketplace-specific context (x402, USDC on Base). However, it does not explicitly differentiate itself from sibling marketplace/search tools like find_agent or zambo_ask.

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

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

There is an explicit 'When to use' and 'When not to use' section, which is helpful, but the guidance is generic: 'when the user's request matches this capability' is tautological, and 'a safer read-only route' does not name which sibling tool should be used instead. It provides context but not concrete alternatives.

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

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

With no annotations present, the description carries the disclosure burden, and it does reveal important non-obvious behavior: identity persists across clients, model updates, and chain migrations, and other agents can query the track record. It does not fully explain save semantics such as overwrite vs. merge or whether wallet state is persisted by save, which keeps it from a 5.

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

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

The structure is clear: value proposition, actions, call format, and usage guidance are front-loaded and labeled. However, it is wordy, includes a marketing line ('This is the difference between a disposable chatbot...'), and contains a tautological when-to-use sentence that do not earn their place.

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

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

For a stateful 5-parameter tool, it provides enough to invoke correctly: required handle and action, optional parameters tied to save, action-specific outputs, and an example call. Since an output schema exists, not detailing return payloads is acceptable; the main residual gap is what happens for an unknown handle or an empty save payload.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description's ACTIONS section mostly repeats the schema's enum descriptions. The CALL FORMAT example adds minor invocation guidance but does not materially enrich parameter meaning beyond the schema.

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

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

The description opens with a specific verb and resource ('Establish a persistent agent identity') and names the three actions, so an agent can clearly see what the tool does. It does not explicitly distinguish itself from sibling tools like agent_brief or axis_reputation_check, though the cross-client persistence framing makes the capability reasonably distinct.

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

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

It supplies concrete use-case context ('Start a task in Claude Desktop, continue in Cursor, hand off to Telegram') plus an explicit When to use / When not to use block. It does not name sibling alternatives, and the positive guidance is partly tautological ('when the user's request matches this capability'), so it stops short of a 5.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses the return payload, but remains silent on whether calling the tool has side effects, mutates state, requires particular permissions, or is itself read-only. The phrase 'safer read-only route' hints at a safety distinction without clarifying this tool's own profile.

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

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

The first two sentences are informative and front-loaded. The 'When to use' sentence repeats the tool name and makes a tautological capability claim, so not every sentence earns its place, though the description is still reasonably tight overall.

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

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

For a small 2-parameter tool with a 100%-covered schema and an output schema, the basics are covered: required input, optional focus, and the return concept. The main gaps are the lack of an explicit read-only or side-effect statement and the absence of sibling alternatives, leaving selection safety somewhat incomplete.

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

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

Schema description coverage is 100%, so both agent_purpose and focus are already documented. The description only reinforces that agent_purpose drives the recommended workflows and adds no new parameter-level detail, especially not for focus.

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

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

The description uses a specific verb ('Brief') and names the resource ('complete Zambo + x711 stack'), and it states the deliverable: an onboarding package with stack capabilities, tool inventory, and recommended workflows. It does not, however, differentiate this tool from closely named siblings like agent_brief or zambo_agent_bootstrap.

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

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

There is an explicit 'When to use' and 'When not to use' section, but the positive condition is circular: 'call axis_agent_onboard when the user's request matches this capability.' The negative guidance mentions unrelated work, missing inputs, and a safer read-only route, but names no concrete alternative tool or decision rule.

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

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

With no annotations provided, the full burden falls on the description. It is clear that the tool generates configuration artifacts rather than deploying them, and it lists notable output features, but it does not disclose whether invocation has external side effects, requires credentials/prerequisites, or is reversible.

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

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

The description is compact and front-loaded with the core purpose and output. The 'When to use' line repeats the capability almost tautologically, and the 'When not to use' clause is generic, keeping it from a 5.

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

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

Given the presence of an output schema and full schema coverage, the description covers the key invocation context: what it does, what it outputs, and its place after axis_spark_to_swarm. It is slightly incomplete on prerequisites and side effects, but the remaining context is adequate for an agent to select and call the tool.

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

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

Schema coverage is 100%, and each of the four parameters already has an explanatory description and one has an enum. The tool description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb and resource: it wires two AI agents via Entangler.tech and generates a deploy-ready Entangler config with enumerated components (CHRONOS logging, PULSE monitoring, identities, schema, failure handling). It also refers to axis_spark_to_swarm, which helps separate it from the many sibling agent/coordination tools.

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

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

It explicitly positions the tool in a workflow: use after axis_spark_to_swarm to wire the agents that tool planned, and it provides generic when-not-to-use conditions. The main weakness is the circular 'when user's request matches this capability' phrasing and the unnamed read-only alternative.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the output and the chain relationship, but it does not clarify whether generating the proof has side effects, requires special permissions, persists state, or is purely computational. The phrase 'safer read-only route' even implies this tool may not be read-only, without explaining what it actually mutates or writes.

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

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

The first two sentences are efficient and informative, front-loading the tool's purpose and return value. The third sentence, however, is padded with tautological guidance ('when the user's request matches this capability') and generic caveats that do not earn their place.

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

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

The description benefits from 100% schema coverage and the presence of an output schema, so parameter and return details are largely covered. However, the missing side-effect disclosure and vague usage guidance leave gaps: an agent still cannot tell when this is preferable to similar chain/proof tools, or what operational requirements exist.

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

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

Schema description coverage is 100%, so the schema already documents spark_hash and execution_log. The description adds minimal semantic value by referencing 'Zambo Spark (strategy)' and 'x711 execution log,' but it does not explain formats, constraints, or relationships beyond what the schema already provides.

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

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

The description uses a specific verb and resource: 'Generate a cryptographic proof chain' linking 'Zambo Spark (strategy) → x711 execution log' and returns a single SHA-256 provenance hash. This is clear, but it does not explicitly differentiate from sibling tools such as proof_certify, zambot_chain, or zambot_verify, so it misses the top score.

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

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

The description includes a 'When to use' and 'When not to use' section, but the guidance is generic and tautological: 'call axis_chain_proof when the user's request matches this capability.' It mentions avoiding unrelated work, missing required inputs, and preferring a 'safer read-only route,' but it does not name specific alternative tools or concrete conditions for choosing this one.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool returns 'ranked results with integration paths,' but it does not disclose whether this is a read-only lookup, whether it triggers cross-system side effects, or what the 'safer read-only route' implies about this tool's own behavior. That ambiguity is a notable gap for a tool that searches across multiple networks.

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

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

The core description is concise and front-loaded, but the 'When to use' and 'When not to use' lines add boilerplate without specific content. The sentence 'call axis_cross_search when the user's request matches this capability' is pure filler, and the general warnings about unrelated work and required inputs do not earn their place.

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

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

The input schema is fully covered and an output schema exists, so return-value details are not required in the description. However, the tool lacks specific alternatives and leaves its read-only/safety status ambiguous, especially given the 'safer read-only route' phrasing. It is adequate for simple invocation but not complete for confident tool selection among many similar search-related siblings.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by mapping the three network enum values to domains: Zambo (strategy/tools), x711 (execution/compute), and Entangler (coordination), which the schema itself does not explain. This helps an agent choose the correct value for the network parameter.

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

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

The first sentence names a specific verb ('Search') and a specific resource ('capabilities and tools across Zambo, x711, and Entangler simultaneously'), which clearly conveys the cross-network scope. It does not explicitly name a sibling alternative, but the simultaneous multi-network search is a strong differentiator among tools like capability_search and the zambo_* family.

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

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

The 'When to use' line is tautological: 'call axis_cross_search when the user's request matches this capability' provides no actionable selection criteria. The 'When not to use' advice is generic ('unrelated work', 'missing required inputs', 'safer read-only route') and never identifies which sibling or alternative tool should be used instead, so an agent gets little real selection guidance.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that the tool flags misalignment and provides auto-correction recommendations, implying it does not directly apply corrections. However, it never explicitly states whether the operation is read-only, what access is required, or any side effects, leaving meaningful gaps for a monitoring tool.

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

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

The core two sentences are front-loaded and informative, stating the monitoring purpose and output behavior. The appended when-to-use/when-not-to-use boilerplate is tautological and does not earn its place, adding noise without routing value.

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

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

With an output schema present and a clear core description, the basic call contract is covered. However, the generic usage guardrails and the lack of differentiation from similarly named drift tools mean an agent in a large sibling catalog still lacks enough context to reliably select this over alternatives.

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

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

The schema already documents both parameters with clear descriptions (spark_hash as the original hash, current_outputs as a swarm summary), and schema coverage is 100%. The description mirrors this vocabulary but adds no additional format, constraint, or usage detail beyond what the schema provides.

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

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

The description states a specific verb ('Monitor') and resource ('running agent swarm... vs its original Zambo Spark'), and adds detail about comparing behavior against the strategy plan and flagging misalignment with recommendations. However, it does not differentiate from the similarly named sibling 'zambot_drift', so an agent cannot tell them apart without further inspection.

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

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

The 'When to use' clause is circular ('when the user's request matches this capability') and the 'When not to use' clause lists generic cautions such as 'unrelated work' or 'a safer read-only route' without naming alternatives. No concrete conditions or sibling comparisons are provided, so this offers little actionable routing guidance.

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

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

With no annotations, the description carries the behavioral disclosure burden. 'Get' implies a read-only retrieval, and the description adds useful context that it is 'Free, no auth' and that the main Zambo MCP URL already exposes the underlying tools. It does not explicitly state side effects, reversibility, or failure behavior, but for a zero-parameter config accessor this is a reasonable baseline.

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

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

The opening sentence is informative and front-loaded, and the 'Free, no auth' note is useful. However, the 'When to use' sentence is redundant with the tool's stated purpose, and the list of exclusions in 'When not to use' is padded with obvious advice. The description earns its place but contains noticeable filler.

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

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

This is a simple zero-parameter tool with an output schema, so the description does not need to explain return values. It covers what the tool returns, when to call it, when not to call it, and its auth/access profile. It could be more concrete about what the returned configuration contains, but the output schema likely fills that gap.

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

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

The tool has zero parameters, so the baseline is 4. There is no parameter behavior to explain, and the description correctly focuses on the tool's purpose and access characteristics rather than inventing parameters. Nothing about the input schema needs additional elaboration.

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

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

The description uses a specific verb and resource: 'Get the dedicated Axis bridge configuration,' and clarifies that it is the config for the Axis bridge across Zambo.dev, x711.io, and Entangler.tech. It also distinguishes this tool from the main Zambo MCP URL, which already exposes the tools. It could be sharper about what makes this dedicated config different beyond 'explicitly needs it,' but the core purpose is clear.

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

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

The description includes an explicit 'When to use' and 'When not to use' section, which is helpful. However, the when-to-use guidance is tautological ('when the user's request matches this capability'), and the not-to-use guidance is generic ('unrelated work,' 'safer read-only route'). It does convey that the dedicated config should be returned only when the client explicitly needs it, giving some usable direction.

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

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

It discloses the persistence angle ('the Entangler MEMORIA write call to persist it') and the return-package contents, which is helpful given no annotations. However, it is ambiguous whether the tool itself executes the memory write or merely returns a call for the agent to execute; auth, reversibility, and failure implications are unstated.

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

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

The opening sentence and return-value sentence are efficient and front-loaded. The When-to-use section repeats the tool name and tells the agent to call it when the request 'matches this capability,' adding filler without new information.

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

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

With an output schema and 100% param coverage, the description covers the core flow and a safety caveat ('safer read-only route'). Missing are concrete prerequisites, examples, and clear write-execution semantics for a mutating tool with no annotations, leaving the agent to infer behavior.

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

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

Schema description coverage is 100%, and the description mostly restates the schema ('context, result, or state'), enum layers, and optional Spark hash. The only added param-level insight is 'any direction', which doesn't materially go beyond the schema's required from_layer/to_layer enums.

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

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

The first sentence names a specific operation—package and hand off context across layers—and pins it to Entangler MEMORIA. The explicit directions (Zambo→x711, x711→Entangler, Entangler→Zambo) plus return-package details distinguish it from generic memory utilities, though it doesn't name a differentiating sibling.

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

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

It includes both 'When to use' and 'When not to use' sections, which is more than most tools. But the when-to-use clause is tautological ('when the user's request matches this capability'), and the exclusions are generic ('unrelated work', 'safer read-only route') without naming concrete alternative tools.

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

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

With no annotations, the description correctly signals that this is a mutating submit operation and mentions cryptographic proof, which adds behavioral context. It does not disclose prerequisites, permission requirements, idempotency, or reversibility; for a write tool with no annotation coverage this is a notable gap, so 3.

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

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

The purpose is front-loaded, but the second sentence is decorative ('Closes the loop...') and the 'When to use' sentence largely restates the capability without adding information. Compact, but with some filler.

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

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

With an output schema and 100% parameter coverage, the description doesn't need to explain return values or parameters. However, it leaves ambiguous what qualifies as a valid spark_hash/outcome for this registry and how this tool relates to the many similar axis/zambot siblings, so it is only minimally complete.

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

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

Schema covers all three parameters with descriptions, so the baseline is 3. The tool description adds no parameter-specific detail beyond the schema, so no increase.

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

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

Clearly states the action (submit real-world outcomes) and the target (Zambo Proven Spark Registry), and situates it in the workflow loop. It does not name or differentiate from closely related sibling tools like zambot_outcome or zambot_registry, so it earns a 4 rather than 5.

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

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

Provides an explicit 'When to use' and 'When not to use' section, but the trigger is tautological ('matches this capability') and the exclusions are generic (unrelated work, missing inputs). It mentions preferring a read-only route when appropriate, but names no specific alternative sibling, leaving routing mostly to inference.

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

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

With no annotations provided, the description carries the full disclosure burden. It does communicate a read-style behavior ('Check', 'Returns a trust score and outcome history') and scope ('all three Axis layers'). However, it does not state side effects, failure behavior for unknown identifiers, permission requirements, or rate limits, so transparency is only partial.

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

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

The first sentence is well front-loaded and informative. The 'When to use' sentence is redundant, and the 'When not to use' sentence is generic and vague, adding boilerplate rather than useful content. Overall it is reasonably short but contains filler.

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

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

For a one-parameter tool with an output schema, the definition provides a workable amount of context, including the output shape and scope. However, it lacks guidance on how to distinguish this from similar axis_* and zambo verification tools, and it does not state whether the operation is strictly read-only or what happens on invalid identifiers. These gaps leave the description merely adequate.

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

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

Schema description coverage is 100%, so the input schema already documents 'identifier' as 'Swarm ID, Spark hash, or agent identifier'. The description adds little parameter-specific meaning beyond connecting the tool to provenance chain data, which is enough for the baseline but not a real enhancement.

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

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

The description states a specific action ('Check the reputation and track record'), a clear resource ('agent swarm or workflow'), and a distinctive method ('using provenance chain data'). It also names the kind of output ('trust score and outcome history'), making the tool's purpose identifiable. It does not explicitly differentiate it from related axis_* siblings, so it stops short of a 5.

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

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

The 'When to use' guidance is circular: 'call axis_reputation_check when the user's request matches this capability' restates the tool rather than identifying concrete triggering conditions. The 'When not to use' note mentions 'a safer read-only route' but never names an alternative tool, so an agent gets little practical routing help.

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

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

With no annotations, the description carries the full burden and does add meaningful context: the plan is executable, spans web search/live data/on-chain transactions/payments, and involves Zambo (strategy) plus x711.io (execution). The critical gap is side-effect clarity — it never states whether calling this tool merely produces a plan or can trigger payments/on-chain actions, which matters given the domain list.

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

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

Front-loaded with the value proposition ('Turn any goal into a full executable multi-agent workflow plan') and reasonably compact overall. However, the when-to-use section wastes words on tautology ('when the user's request matches this capability') and generic exclusions ('unrelated work, missing required inputs'), so not every sentence earns its place.

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

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

For a tool this complex — multi-agent orchestration touching payments and on-chain execution — the description covers purpose and output content but omits the side-effect behavior entirely. An output schema exists, which covers return values, but how the returned plan should be consumed and what calling this tool actually triggers remain unexplained.

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

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

Schema description coverage is 100%, so both parameters are already documented with concrete descriptions (natural-language goal, quick/full depth). The description reinforces the natural-language input ('Plain English in') but adds nothing about depth or format beyond the schema, keeping it at the baseline for high-coverage schemas.

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

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

States the core function concretely — 'Turn any goal into a full executable multi-agent workflow plan' — and names the output artifacts (agent roles, tool assignments, execution sequence). 'Best first Axis tool for any new workflow' gives it an identity among a large sibling list. However, it never contrasts with similarly named swarm/spark tools (zambo_swarm, zambot_spark, axis_swarm_pattern), so differentiation is positional rather than functional.

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

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

Includes explicit 'When to use' and 'When not to use' sections, and the read-only exclusion ('safer read-only route') is a genuinely useful guardrail. But the when-to-use clause is tautological ('when the user's request matches this capability') and no alternative sibling tool is named, leaving the agent with mostly boilerplate routing guidance.

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

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

With no annotations, the description must carry the behavioral burden, but it never states whether this call mutates state, deploys agents, invokes x711 tools, or is purely a design/read-only operation. 'Safer read-only route' implies it may not be read-only, increasing the need for an explicit side-effect disclosure.

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

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

The core purpose and output list are front-loaded, and the routing guidance is compact. Minor filler exists (the tautological 'when the user's request matches this capability' and restating 'missing required inputs' that the schema already conveys).

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

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

The description covers the main capability, optional topology, and expected outputs, and an output schema exists. It remains incomplete around behavioral side effects and lacks a concrete trigger example or named sibling distinction, which matters for a complex fleet-design tool with many related zambo/axis siblings.

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

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

Schema coverage is 100% and every parameter already has a description, so the baseline is 3. The description adds only marginal restatement of 'objective and number of agents' and lists topology values already captured by the schema enum.

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

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

The description opens with a specific verb and resource ('Design a full multi-agent fleet architecture on Entangler.tech') and enumerates concrete outputs (agent roles, topology, coordination config, x711 assignments, Zambo Spark anchor). It doesn't explicitly name sibling alternatives, so it stops short of full 5, but 'full trifecta architecture in one call' distinguishes it from piecemeal setup tools.

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

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

It provides explicit When to use / When not to use sections, including a caution to prefer a safer read-only route when appropriate. However, the positive trigger is tautological ('when the user's request matches this capability') and no sibling tool is named as an alternative.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly: it states what the dispatcher returns, that it can incur x402 USDC micropayments, that FREE tools have a 10/day no-key limit, and that results include provenance. It also warns about a common caller mistake: 'Do NOT use `args` — the param is `input`'. This goes well beyond what structured fields would reveal.

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

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

The description is longer than average, but it is well-structured with capital-letter labels (CALL FORMAT, FREE, PAID, MCP config, Returns, When to use) that make it scannable and front-loads the most critical information: how to call the tool and the required parameter names. Some tool-list content is duplicated in the schema, but the FREE/PAID categorization and per-tool pricing add information not present in structured fields.

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

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

Given that there are no annotations, the description is unusually complete: it provides call format, required parameters, examples, free vs paid access, rate limits, payment mechanism, return contents, chainability to other Axis tools, exclusion conditions, and even MCP configuration. The presence of an output schema means return-value details do not need to be spelled out further, and nothing essential for an agent to invoke this tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantic value: it specifies the exact call shape, underscores that `input` accepts queries/URLs/addresses/tasks, and provides two worked examples. The 'Do NOT use args' warning is particularly valuable because the schema alone would not tell an agent that `args` is a common but wrong parameter name.

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

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

The description names a specific verb and resource: it 'dispatches any x711.io tool' and 'returns live results + provenance chain'. It is clearly distinguished from the many sibling tools by framing itself as a generic dispatch layer rather than a single-purpose tool, and it reinforces this with concrete examples such as axis_tool_dispatch({tool: "web_search", input: "latest MCP tools 2026"}).

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

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

The description provides explicit when-to-use and when-not-to-use guidance: 'call axis_tool_dispatch when the user's request matches this capability' and 'do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate'. It also includes FREE vs PAID guidance to help an agent determine whether a target x711 tool is usable without a key. The only limitation is that the 'safer read-only route' alternative is not tied to a specific sibling tool name.

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

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

No annotations are provided, so the description carries the full burden. It discloses the paywall (Zambo Pass, $49/mo, 500 calls/day), suggests a free alternative, and notes when not to use it. However, it does not explicitly state whether the tool is read-only (the phrase 'safer read-only route' implies potential side effects, which is ambiguous for a scoring tool). It also omits failure/error behavior. Still, the key behavioral traits are covered.

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

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

The description is front-loaded with the core purpose and outputs, which is good, but it includes redundant marketing text ('Get pass: https://zambo.dev/pricing') and repetitive usage guidance that could be tightened. It is not wasting space, but it is longer than necessary for the value it adds.

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

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

With an output schema present, the return structure is already specified. The description adds the meaningful context of prerequisites (Zambo Pass), call limits, and a fallback tool. It also warns against misuse (missing inputs, unrelated tasks). For a 2-parameter tool, this is fairly complete, though it could mention error cases like invalid wallet or expired pass.

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

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

Schema coverage is 100%, so the schema already documents both parameters (email, wallet) with descriptions. The tool description adds only the clarification that wallet can be an ENS name, which is already in the schema. It does not enrich parameter meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description opens with a specific action ('Score any Base chain wallet address from 0–1000') and lists the concrete outputs (score, label, breakdowns across activity/diversity/DeFi/NFT/token quality). It also distinguishes itself from siblings by explicitly naming the alternative bounty_scan, so an agent can tell them apart without inspecting other schemas.

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

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

The description gives explicit 'When to use' and 'When not to use' sections, including a concrete alternative (bounty_scan) for users without a pass. It also states conditions to avoid (unrelated work, missing required inputs, safer read-only routes), leaving little to inference.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns specific errors, estimated savings, and a negotiation script, and it clarifies scope (works for multiple bill types). It does not mention any destructive side effects, which is appropriate for an audit tool, and it is consistent with the absence of annotations. The description adds useful context about the return format and breadth of applicability.

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

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

The description is effectively structured: it opens with the core purpose, then gives examples of bill types, and ends with usage guidance. It is a bit wordy with the repeated 'When to use' phrasing, but each sentence contributes value. It is front-loaded with the primary function and avoids extraneous detail.

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

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

Given the existence of an output schema (not shown, but declared), the description does not need to detail return values. It covers the essential information an agent needs: what the tool does, what it returns, when to use it, and when not to. It also provides a comprehensive example in the bill_description parameter description. Minor gaps like handling edge cases or prerequisite permissions are not critical for this audit tool.

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

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

Schema description coverage is 100%, so each parameter is already documented in the schema. The main description does not add new semantics for parameters beyond what the schema provides; it reinforces the purpose but does not clarify parameter formats or edge cases. According to the rubric, baseline 3 is appropriate when the schema covers everything, and this description does not go beyond that.

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

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

The description states a specific verb and resource: 'Audit any bill, subscription, or service charge for errors, overcharges, and negotiation opportunities.' It enumerates the types of bills (phone, cable, internet, etc.) and explicitly names the output (errors, savings, negotiation script). This is unambiguous and distinguishes it from any sibling tool that might involve similar domains.

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

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

The description provides explicit 'When to use' and 'When not to use' clauses, including 'missing required inputs' and 'when a safer read-only route is more appropriate.' It does not name a specific alternative tool, but the reference to a read-only route is a clear class of alternatives. This is nearly a 5, but falls short due to lack of named sibling tools.

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

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

With no annotations provided, the description carries the full burden and does disclose key behavioral traits: 'Free, no auth required' and the output shape ('Returns a list of claimable positions with estimated USDC value'). It does not explicitly state that the scan has no side effects, but the wording strongly implies a read-only operation.

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

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

The description is efficiently structured with the core action and coverage front-loaded, followed by a clear 'When to use' / 'When not to use' section. The phrase 'call bounty_scan when the user's request matches this capability' is somewhat tautological but does not add significant bloat.

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

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

For a single-parameter scan tool with an output schema available, the description covers the essential context: scope (chains and protocols), output nature, cost/auth, and usage conditions. Minor gaps such as not mentioning any rate limits or execution time are acceptable given the tool's simplicity.

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

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

Schema description coverage is 100%, so the parameter 'address' is already fully documented in the schema. The tool description adds context about what address scanning covers (bounties, airdrops, etc.) but does not provide any additional syntax or format guidance beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb ('Scan') and resource ('a wallet') and enumerates exactly what it finds: unclaimed DeFi bounties, airdrops, claimable rewards, and yield opportunities across 36+ protocols on 5 named chains. The return value is also specified (claimable positions with estimated USDC value), clearly distinguishing this from sibling tools like contract_scan.

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

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

The description provides explicit when-to-use and when-not-to-use guidance: call it when the request matches the capability, avoid it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate. It does not name specific alternative sibling tools, which keeps it just short of a 5.

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

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

There are no annotations, so the description carries the full burden. It does reveal that the tool checks both pass types and returns active:true for both, and gives a full spec URL. However, it does not explicitly state whether the call is read-only, what happens when no pass is active, or any error/auth requirements, leaving some behavioral gaps.

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

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

The description is bloated with a long list of pass features (50 ZAMBOT Sparks/month, 5 ProvibeCode audits, BaseHawk API limits, etc.) that are more product documentation than tool invocation guidance. The 'When to use' phrasing is redundant, and the 'When not to use' is boilerplate, so not every sentence earns its place. It does have some structure (When to use / When not to use) but is overly long for a simple check.

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

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

For a one-parameter check with a full output schema, the description covers the purpose, the distinction between Zambo Pass and Day Pass, and the intended pre-bulk-API use case. It also points to a full spec URL for more detail. Missing cases like an inactive email are likely covered by the output schema, so the description is sufficiently complete.

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

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

The input schema already provides 100% coverage with a clear description for the single 'email' parameter. The tool description adds little beyond restating that it checks the email for an active pass, so it stays at the baseline for a well-documented schema.

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

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

The description opens with a clear verb and resource: 'Check whether an email address has an active Zambo Pass or Day Pass.' It explicitly states the return value for both pass types. However, it does not name a sibling tool (e.g., zambo_check or day_pass_activate) to differentiate from, so it doesn't fully distinguish among the many zambo-related tools.

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

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

It offers practical guidance with 'Use before bulk API calls to know actual rate limits', a real invocation context. The 'When to use' line is tautological ('when the user's request matches this capability'), and the 'When not to use' line is generic ('unrelated work', 'missing required inputs', 'a safer read-only route is more appropriate') without naming a specific alternative tool. So the when is partially clear, but alternatives are not.

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

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

With no annotations provided, the description carries the full burden and does so exceptionally well. It discloses irreversible on-chain burning of $ZAMBO, auto-expiry, audit/track-record persistence, and per-capability pricing, giving an agent a clear picture of side effects and costs before calling.

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

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

The content is logically ordered and informative, but it includes promotional filler such as 'This makes Zambo the economic layer for agent capabilities — not just another MCP endpoint.' This sentence does not help an agent and wastes tokens, so not every sentence earns its place.

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

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

Given the financial stakes of burning tokens, an output schema, and 100% parameter coverage, the description supplies everything an agent needs to decide, construct, and invoke the call. It covers pricing, constraints, side effects, call format, and explicitly states when not to use the tool.

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

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

Schema coverage is 100% and already documents capability pricing, email identity tracking, and duration defaults/maximums, so the baseline is 3. The description adds a call format example and reinforces semantics, but it does not add significant new meaning beyond what the input schema already provides.

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

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

Clearly states it temporarily elevates an agent by renting a premium capability for a fixed window, with a concrete list of available capabilities and pricing. However, it does not explicitly differentiate itself from sibling tools like capability_search or day_pass_activate, relying instead on a generic description of what it does.

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

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

Includes an explicit 'When to use / When not to use' section with concrete exclusion conditions: unrelated work, missing required inputs, or when a safer read-only route is more appropriate. It stops short of naming alternative tools directly, so the routing guidance is clear but not tool-specific.

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

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

Because no annotations are provided, the description carries the full burden of disclosing behavior. It explains that the search covers 100+ tools, returns up to 8 results with relevance scores, descriptions, taglines, and callable API endpoints, and occurs via one MCP connection. This gives an agent a clear picture of what to expect without needing the output schema.

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

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

The description front-loads the core purpose well, but the 'When to use' sentence restates the tool's purpose in a tautological way. The 'When not to use' clause is also generic and vague. There is some redundancy, though the overall length is still reasonable for a search/discovery tool.

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

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

Given that the tool has an output schema and a simple two-parameter input schema, the description covers the essential context: what the tool searches, what it returns, and broad routing guidance. The main slight gap is the somewhat confusing relationship with zambo_universal, but it does not critically impair an agent's ability to use the tool.

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

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

Schema description coverage is 100%, so the input schema already documents both q and query parameters well, including examples and the alias relationship. The description adds little parameter-specific meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Search') and identifies the exact resource ('all 100+ Zambo Stack tools'), making the tool's purpose immediately clear. It also signals its outcome — returning up to 8 relevant products with scores and endpoints — and distinguishes it from zambo_universal, a key sibling.

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

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

The description includes explicit 'When to use' and 'When not to use' sections, which is strong guidance. However, the alternative to this tool is only vaguely named (zambo_universal, 'a safer read-only route'), and the sentence 'call capability_search when the user's request matches this capability' is tautological and adds little.

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

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

No annotations are provided, so the description carries the full burden. It discloses output behavior in detail (issue severities, locations, security vulnerabilities, overall score), but does not explicitly state whether the tool is read-only, executes code, or has side effects/privacy implications. The 'safer read-only route' phrase hints at caution but doesn't clarify the tool's own behavioral profile.

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

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

The description is front-loaded with purpose and return details, but it is repetitive: 'Use when user shares code...' is followed by the nearly redundant 'When to use: call code_review when the user's request matches this capability.' Some sentences could be trimmed without losing information.

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

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

Given the output schema exists and all parameters are described in the schema, the description covers the key selection and invocation context. It explains what the tool returns, when to call it, and when not to. The only notable gap is the vague read-only alternative reference, but it does not prevent correct use.

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

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

Schema coverage is 100%, so the input schema already documents code, focus, context, and language with descriptions. The tool description adds no additional parameter meaning beyond what the schema provides, which matches the baseline for fully covered parameters.

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

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

The description clearly states the tool performs deep code review and enumerates specific outputs: severity-rated issues, security flags, performance notes, and fix suggestions. The resource and action are unambiguous, and no sibling tool appears to cover the same capability.

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

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

The description gives concrete trigger phrases ('review this', 'what's wrong with', 'is this secure', 'how can I improve') and a when-not-to-use section. It lacks named alternative tools, and the 'safer read-only route' reference is vague, but the selection guidance is otherwise clear.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses that the tool returns ready-to-post copy rather than publishing it, and it states the rate limit '3 free/day'. This is helpful for an AI agent deciding whether invocation is appropriate, though it doesn't detail side effects or auth needs.

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

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

The description is well-structured: capability first, then outputs, then the rate limit, then usage guidance. The 'When to use' sentence is redundant and could be trimmed, but the rest is efficient and front-loaded.

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

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

For a content-generation tool with an output schema and high schema coverage, the description provides the key operational facts: what it generates, for which platforms, what artifacts it returns, and the free usage limit. It does not elaborate on tone defaults, but the schema covers those, leaving only minor gaps.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds some conceptual framing—it clarifies that 'product' can be a feature, achievement, or idea and that output includes hooks, threads, hashtags, and timing—but it doesn't deepen per-parameter semantics beyond what the schema already provides.

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

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

The description uses a specific verb ('Generate') plus a clear resource ('complete, platform-optimized content strategy') and enumerates concrete outputs: ready-to-post copy for X, LinkedIn, GitHub, Discord, and newsletter. This makes the tool easy to distinguish from siblings like thread_craft or email_write.

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

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

The description explicitly gives when-to-use and when-not-to-use conditions, including 'unrelated work', 'missing required inputs', and 'safer read-only route'. However, the when-to-use line is somewhat tautological ('when the user's request matches this capability') and it names no concrete sibling alternatives.

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

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

With no annotations, the description carries full behavioral burden. It discloses outputs (risk level, red flags, clause location, negotiation points) and the plain-English style, but does not mention side effects, data handling, or any non-obvious behavior.

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

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

The first sentence is strong and front-loaded, but the later 'When to use' section is redundant with the earlier 'Use when...' sentence. Some boilerplate could be trimmed without losing value.

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

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

The description covers what the tool does, when to use it, and what results to expect, and the input schema and output schema fill in the remaining details. It is complete enough for an agent to invoke this tool correctly in the intended scenarios.

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

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

Schema description coverage is 100%, and the schema already documents all three parameters with their meanings. The description adds no additional parameter-specific meaning, which is acceptable given the baseline for high coverage.

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

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

The description clearly states the tool scans contracts and legal documents for red flags, with a specific verb, resource, and outcome. It is distinct from generic siblings like doc_intel or pdf_extract, but does not explicitly name or contrast a sibling tool.

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

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

The description gives explicit conditions: use when the user pastes a contract, TOS, NDA, lease, or employment agreement. It also provides when-not-to-use guidance, though it does not name specific alternative tools, only a vague 'safer read-only route'.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds useful context: 'Live, verified index', 'Verified daily — dead links auto-removed', and 'Free, no auth'. However, it never explicitly states that the tool is read-only or describes side effects, rate limits, or response behavior beyond 'matched recommendations'.

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

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

The purpose is front-loaded and the list of example programs is illustrative, but the description overstays a bit: the long program list is redundant after '29+ active programs', and the 'When to use' sentence is close to tautological. It is not poorly structured, but not every sentence earns its place.

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

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

Given the simple optional-parameter shape, full schema coverage, and presence of an output schema, the description is reasonably complete for an agent to invoke the tool. The main gap is weak usage guidance, but the schema and output schema cover the operational details.

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

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

The schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds only 'Pass your tech stack' but does not elaborate on stage or min_value, so it does not meaningfully extend what the schema already provides.

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

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

The description clearly identifies the resource (AI and cloud startup credit programs) and the action ('get matched recommendations'), and it gives concrete examples of included programs. It does not explicitly distinguish credithunt from sibling tools like zambo_compare or zambo_live, so it stops short of a 5.

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

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

The description includes 'When to use' and 'When not to use' sections, which is useful, but the guidance is generic ('when the user's request matches this capability') and never names alternatives or concrete selection criteria. The note about 'missing required inputs' is also misleading since all parameters are optional.

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

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

Since no annotations are provided, the description carries the full burden. It discloses that the tool grants instant 24h access, requires prior payment and a valid tx_hash, and points to non-crypto alternatives. It doesn't cover failure modes or idempotency, but for this activation-style tool the key behaviors are clearly visible.

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

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

The description is dense but well organized with (A)/(B) options, a clear step sequence, and alternate payment links. Some redundancy exists — the 'When to use' sentence largely restates the purpose — but the critical information is front-loaded and scannable. It could be tightened without losing value, but it remains reasonably concise for the complexity.

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

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

The description covers payment addresses, exact amounts, quote endpoint prerequisite, required inputs, activation outcome, and fallback payment options. The only minor gap is that it doesn't explicitly state how the tool determines which blockchain a tx_hash belongs to, but that isn't necessary for correct invocation. Since an output schema exists, return-value details aren't expected.

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

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

The schema already documents both parameters at 100% coverage, giving a baseline of 3. The description adds operational meaning beyond the schema: it explains that the email links the pass to the account, that the tx_hash comes from a wallet or explorer after payment, and that zambo-quote should be called first for the $ZAMBO amount. That extra context justifies a 4.

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

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

The description opens with a concrete action and resource: 'Activate a 24-hour unlimited Zambo Pass for $1.49.' It clearly identifies the tool's purpose and outcome. However, it does not explicitly differentiate it from sibling tools like builder_pass_check or capability_rent, so it stops short of the highest clarity score.

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

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

The description provides explicit 'When to use' and 'When not to use' sections, including exclusions for missing required inputs and safer read-only alternatives. It also gives a clear sequence: pay first, call zambo-quote for the $ZAMBO amount, then invoke with email and tx_hash. No alternative tool is named, so it doesn't fully meet the top-score rubric.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses rate limits (3/day free, unlimited with Zambo Pass), access constraints (publicly accessible URL only), and a detailed return set. It does not cover data handling or failure modes, but the key operational behaviors are exposed.

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

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

The description is long but well-sectioned with output fields, use-case examples, quota info, and usage guidance. Most sentences carry useful information, though the 'When to use: call doc_intel when the user's request matches this capability' sentence is filler and prevents a 5.

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

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

Given the output schema and three optional parameters, the description covers input modes, outputs, quota, access requirements, and exclusions. It leaves minor ambiguity about whether at least one of url/text is expected and what happens when both are absent, but it is largely complete.

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

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

Schema description coverage is 100%, and the schema already explains url, text, and email well. The description mostly restates those definitions and adds only minor constraints like 'publicly accessible URL', so it adds modest value beyond structured fields. Baseline 3 applies.

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

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

States a specific action ('extract structured intelligence') and enumerates the resource scope: contracts, reports, PDFs, articles, READMEs, legal docs, or raw text. Also lists concrete outputs, which makes the tool's identity distinct from sibling extraction tools.

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

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

The 'Perfect for' examples give clear intent contexts like 'summarize this PDF' and 'extract key risks from this contract', but the explicit 'When to use' line is tautological. No alternative sibling tools are named, and the when-not guidance ('unrelated work', 'safer read-only route') is too generic to route an agent well.

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

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

With no annotations provided, the description carries the full burden. It discloses the output shape (subject line + full email body) and notes tone-matching, which is useful. However, it does not state whether the tool sends emails, persists anything, or has side effects, and there is no caution about its generative nature. This is minimally adequate but not rich.

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

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

The opening is front-loaded and the trigger phrases are useful, but there is clear redundancy: 'When to use: call email_write when the user's request matches this capability' restates the obvious and adds no information. A tighter description would improve the score.

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

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

For a relatively simple generation tool with a full input schema and an output schema, the description covers the main use cases and provides usage guidance. It could add details about how tone/type/length interact or clarify edge cases, but nothing essential is missing for a correct call.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description confirms tone-matching and purpose-built behavior but adds no significant detail beyond the schema, so the baseline 3 is appropriate.

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

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

The verb 'Write any email' plus the explicit list of email types (cold outreach, salary negotiation, complaints, etc.) makes the tool's scope clear, and mentioning that it returns a subject line and full body gives a concrete picture. It does not explicitly contrast with siblings like 'write' or 'zambo_compose', so it falls short of the 5-point bar for distinguishing from siblings.

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

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

The description offers useful trigger phrases ('write an email', 'help me email', 'draft a message to', 'how do I respond to') and includes a 'When not to use' section covering unrelated work, missing inputs, and read-only alternatives. However, the 'When to use' sentence is tautological and no specific sibling tool is named as an alternative, so it does not fully earn a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: the tool is free, requires no auth, allows unlimited searches, and accesses a public registry. It does not explicitly state that the tool is read-only or that it has no side effects, but the 'search' characterization and 'public phone book' framing strongly imply a safe, non-mutating operation.

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

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

The description is front-loaded with the core purpose and then organizes supplementary details into clear usage sections. It is longer than strictly necessary, and the when-not-to-use guidance is somewhat generic, but each sentence contributes useful context such as cost, auth, and downstream routing.

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

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

The tool is simple with 3 well-documented parameters and an output schema, so the description does not need to explain return values. It covers purpose, usage, search scope, output fields, and downstream integration with axis_tool_dispatch. The only notable gap is the lack of named alternatives for related search tools, but the description is still sufficiently complete for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the input schema fully documents query, limit, and capability. The description adds context by mentioning search by 'capability, name, or description,' which aligns with the query parameter, but it does not add meaning beyond what the schema already provides for any parameter.

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

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

The description clearly states the tool searches the Zambo Agent Registry by capability, name, or description and returns handle, endpoint URL, wallet address, and online status. It names a specific verb, resource, and scope, but does not explicitly differentiate it from related sibling search tools such as capability_search or axis_cross_search.

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

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

The description provides explicit when-to-use and when-not-to-use guidance, including avoiding unrelated work, missing inputs, or when a safer read-only route is more appropriate. However, it does not name specific alternative search tools or clarify what constitutes a 'safer read-only route,' so the guidance is clear but not fully explicit about alternatives.

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

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

With no annotations, the description carries the full burden, and it does well by stating it returns 3 complete recipes with specific attributes, is free and unlimited, and frames itself as a generation/retrieval operation rather than a mutation. It does not discuss side effects or auth, but this is a low-risk recipe-generation tool.

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

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

The first sentence is strong and front-loaded, but the later 'When to use' sentence is circular, and 'do not call it for unrelated work' is generic filler. The description is informative but has several sentences that could be cut without losing decision value.

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

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

The description covers the required input, output composition, dietary flexibility, and cost, and an output schema exists to fill in return structure. It is slightly incomplete only in not referencing the 'meal_plan' sibling or explicitly noting default servings, which the schema already provides.

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

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

The input schema already documents all four parameters with examples and defaults, achieving 100% coverage. The description adds ingredient-context flavor and dietary flexibility, but it does not meaningfully extend the meaning of 'vibe', 'servings', or 'dietary' beyond the schema.

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

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

The description clearly states the tool's function: turn ingredients into a dinner plan with 3 recipes, instructions, cook time, difficulty, and shopping list. It is specific about verb and resource, but it does not explicitly differentiate itself from the sibling 'meal_plan' tool.

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

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

It gives concrete 'Perfect for' examples and a when-to-use/not-to-use section. However, the core rule 'call fridge_forge when the user's request matches this capability' is tautological, and no alternative sibling is named or compared, leaving the choice vs 'meal_plan' ambiguous.

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

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

With no annotations provided, the description carries the disclosure burden. It communicates read-only behavior ('Retrieve', 'Returns'), the report's markdown format, and the completion prerequisite. However, it does not state what happens if called before completion, whether authentication is needed, or how rate limits interact with the call.

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

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

Purpose and return contents are front-loaded efficiently in the first two sentences. However, the 'When to use' line is tautological ('when the user's request matches this capability') and the 'When not to use' text is vague filler, adding noise without actionable detail.

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

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

For a single-parameter read tool with an output schema, the description covers the report contents, the required prerequisite, and the rate limit. It lacks explicit handling of incomplete audits, but the status-first instruction mitigates that gap. Overall, little critical context is missing.

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

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

Schema description coverage is 100% — audit_id is clearly described as 'The audit_id returned by ghost_audit_site'. The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb ('Retrieve') and resource ('full markdown report for completed Ghost Audit'), then enumerates the exact contents (score 0-100, findings, stage-by-stage analysis, fixes). It differentiates from ghost_audit_status by naming it as a prerequisite, making the read/report purpose unambiguous.

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

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

Provides an explicit prerequisite ('Call ghost_audit_status first to confirm the audit is complete') and includes when-to-use and when-not-to-use sections. The when-not guidance is somewhat generic ('unrelated work', 'safer read-only route'), but the status-first instruction gives concrete contextual direction.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses the ~90-second async behavior, immediate SSE streaming, the three returned artifacts, and quota/pricing constraints. It also warns that a safer read-only route may sometimes be more appropriate, which is a useful risk signal.

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

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

Information is organized and front-loaded with the action, outputs, stages, timing, and constraints. It is slightly wordier than necessary—purchase details and the tautological 'when the user's request matches this capability' line add noise—but most sentences carry operational value.

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

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

Given a single simple parameter and no annotations, the description supplies enough operational context: expected latency, streaming semantics, result artifacts, quota, cost, and fallback guidance. An agent can invoke this tool and set user expectations without consulting additional documentation.

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

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

Schema coverage is 100%, and the schema already documents the URL format and the https:// requirement. The description adds only the 'any website' scope, which does not materially expand parameter meaning; the baseline score of 3 is therefore appropriate.

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

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

States a specific action ('Run Achilles 10-stage ghost audit on any website') and enumerates the output categories, making the purpose unmistakable. However, it never explicitly distinguishes itself from sibling tools like ghost_audit_report or ghost_audit_status, so it stops short of full differentiation.

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

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

Includes an explicit 'When to use' and 'When not to use' block, but the guidance is largely generic: 'when the user's request matches this capability', 'unrelated work', 'missing required inputs'. It gives no concrete trigger conditions and does not name the alternative tools an agent should prefer instead.

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

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

With no annotations provided, the description carries the behavioral transparency burden. It discloses return states ('complete' vs 'running' with elapsed time), polling behavior, and typical duration. It does not cover failure states or persistence, but this is adequate for a simple status-check tool, especially with an output schema present.

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

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

The core information is front-loaded and clear, but the closing 'When to use' and 'When not to use' sentences are boilerplate and tautological ('call ghost_audit_status when the user's request matches this capability'). Some sentences do not add meaningful value.

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

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

For a low-complexity tool with one parameter and an output schema, the description covers purpose, input provenance, polling cadence, expected completion time, and status semantics. It does not explicitly point to ghost_audit_report for downloading the report, but the mention of 'ready to download' is sufficient context.

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

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

Schema coverage for the single parameter is 100%, and the schema already states that audit_id is 'returned by ghost_audit_site'. The description repeats this same provenance without adding substantial new meaning, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Check the status of a running Ghost Audit.' It clearly identifies the input (audit_id returned by ghost_audit_site) and the expected status outcomes, so an agent can distinguish it from ghost_audit_site and ghost_audit_report.

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

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

The description provides clear operational guidance: 'Poll every 15-30 seconds after starting an audit' and includes typical completion time. It also includes when/not-to-use statements, though 'when the user's request matches this capability' is somewhat circular and it does not explicitly name ghost_audit_report as the download alternative.

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

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

With no annotations provided, the description carries the full burden and does it well: it discloses the generation pipeline, auto-selection of motion presets, direct looping GIF URL, inline markdown embeddability, and the 3 free/day quota. This gives the agent a realistic model of what will happen when invoked.

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

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

The core behavior is front-loaded, followed by output details, auto-motion, usage triggers, quota, and exclusions in a logical order. There is some redundancy near the end ('call gif_animate when the user's request matches this capability' restates the earlier 'Use when' section), but no significant waste.

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

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

Despite having no annotations, the description covers purpose, output format, quota, usage triggers, and exclusions. The output schema covers return values, and the three parameters are adequately described through combined schema and description coverage. An agent has everything it needs to decide and invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by advising vivid descriptions, giving a concrete example, and explaining that the motion preset is auto-detected from content. This goes slightly beyond the schema's default-field labels without duplicating them.

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

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

The description states a specific verb and resource: 'Generate a cinematic animated GIF from any description.' It further distinguishes itself from static image tools by describing the motion effect and looping GIF output, so an agent can tell it apart from siblings like image_generate.

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

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

It gives explicit natural-language triggers ('make a GIF of X', 'animate this', 'create a loop', 'make it move') and explicit when-not-to-use conditions, including missing inputs and preferring a safer read-only route. It does not name sibling alternatives directly, but the routing guidance is clear and actionable.

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

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

With no annotations provided, the description carries the full disclosure burden. It does reveal the core behavior: raw commits/diff are converted into a polished, grouped changelog with features, fixes, and breaking changes. The 'safer read-only route' warning is vague and side effects are not explicitly addressed, but for a text-transformation tool the description gives sufficient behavioral context.

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

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

The description is compact and front-loaded, with the core purpose and expected output in the first sentences. The 'When to use: call git_changelog when the user's request matches this capability' sentence is tautological and adds no new information, which prevents a perfect score.

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

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

For a 4-parameter tool with a full input schema and an output schema, the description covers the input source, acceptable user intents, output grouping, and negative triggers. It is adequate for a capable agent, though the lack of named alternative tools leaves minor routing ambiguity within the large sibling set.

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

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

Schema description coverage is 100%, so the baseline is 3. The prose adds genuine value beyond the schema by mentioning 'or a diff' as an accepted input variant and by mapping output formats (GitHub releases, CHANGELOG.md, product update) to the style parameter, which is not fully explicit in the schema.

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

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

The description opens with a specific transformation: 'Turn raw git commits or a diff into a polished, professional changelog' and names the target formats (GitHub releases, CHANGELOG.md, product update). It also states the expected output ('grouped changes (features, fixes, breaking changes)'), making the tool's purpose unambiguous and distinct from generic writing tools like 'write' or 'content_distribute'.

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

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

It gives concrete trigger phrases ('write a changelog', 'release notes for', 'what changed in this diff') and an explicit 'When not to use' section covering unrelated work, missing required inputs, and safer read-only alternatives. However, it does not name a specific sibling tool as the alternative, so the routing guidance stops short of being fully actionable.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it explains polling cadence, status semantics, that the approved content field may be edited and must be used instead of the original, and what to do on rejection or expiry. This goes well beyond the schema and gives the agent a complete behavioral model.

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

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

The description is long but well-structured with clear separations for status behavior, call format, and usage guidance. Some phrases are redundant, such as 'call hitl_check when the user's request matches this capability,' but overall every substantive behavior earns its place and the information is front-loaded.

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

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

Given a single documented parameter, an output schema, and a low-complexity polling operation, the description is complete. It explains the polling interval, all status outcomes, the source of the review_id, and the follow-up action for expiry. No significant information needed to call the tool correctly is missing.

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

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

Schema coverage is 100% and the schema already states that review_id is 'returned by hitl_submit. UUID format.' The description reinforces this in the CALL FORMAT, but adds little semantic information beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Check whether a human has approved or rejected a review submitted via hitl_submit.' It names a specific verb, resource, and distinguishes this from the sibling hitl_submit by framing it as the polling/completion check for a submission. The status-based behavior further clarifies what the tool does.

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

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

The description gives explicit guidance: poll every 5–10 seconds after hitl_submit, and defines what to do for each status ('approved', 'rejected', 'pending', 'expired'). It also includes when-to-use and when-not-to-use sections, though the alternative 'a safer read-only route' is generic rather than naming a specific sibling tool.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the asynchronous review gate, that the human may edit content, that the returned content may differ from the original, and the recommended polling cadence.

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

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

The description is longer than average but every section earns its place: purpose, workflow, call format, usage guidance, exclusions. It is front-loaded with the most important concept and uses clear section labels, though a few phrases are slightly redundant.

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

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

The description is complete for a human-in-the-loop tool: it explains when to use it, how to invoke it, what happens next, how to check status, how to handle edited content, and the lifecycle of the review link. The output schema covers return value specifics, so nothing essential is missing.

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

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

Input schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds extra value by providing a ready-to-use CALL FORMAT example and explaining the context field's purpose in helping the human understand stakes.

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

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

Description names a specific verb ('submit'), a concrete resource (content for human review), and the exact outcome (review URL, approve/reject flow). It is clearly distinguished from the sibling hitl_check, which polls the submitted review.

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

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

Explicitly provides WHEN TO USE, WHEN NOT TO USE, and a CALL FORMAT with a concrete example. It also tells the agent to poll hitl_check every 5–10 seconds until status changes, leaving no ambiguity about the expected workflow.

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

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

With no annotations provided, the description carries the full burden. It discloses practical behavioral traits: accepts a public URL, works on many image types, and rate limits (20/day free, 40/day signal agents, unlimited with Zambo Pass). It stops short of describing failure modes or file size limits, but essential operational context is present.

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

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

The description is longer than average but well-structured around what, use cases, and when. Each section earns its place, though the 'When to use: call image_analyze when the user's request matches this capability' phrasing is a near-tautology that could be trimmed.

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

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

For a 3-parameter tool with an output schema, this description covers input requirements, target use cases, rate limits, and exclusions. It doesn't name specific sibling alternatives, but it provides enough context for an agent to decide when to call it. Minor gaps around error handling and explicit output description are covered by the existing output schema.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters with examples. The description adds no parameter-specific detail beyond what the schema says—it repeats capability names but doesn't clarify format, constraints, or mode behavior further. Baseline 3 is appropriate.

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

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

The description opens with 'Analyze any image with AI vision' and enumerates specific capabilities (describe, extract text/OCR, review code/errors, identify subjects, read charts), making the tool's purpose unmistakable. It clearly distinguishes from image generation and other vision-adjacent tools via the explicit action and resource.

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

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

It provides explicit trigger examples ('what is this?', 'describe this', 'read the text in this', 'what's wrong with this code?') and a dedicated 'When to use' / 'When not to use' section. The exclusions are clear, but no alternative tools are named by sibling name (e.g., code_review), leaving the alternative guidance generic ('a safer read-only route').

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

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

With no annotations, the description carries the behavioral burden and does substantial work: it discloses the generation pipeline (Groq prompt enhancement + Pollinations rendering), the output form (direct image URL + markdown embed), inline rendering behavior, and a daily quota. It omits failure-mode details like quota exhaustion behavior, but nothing about its behavior is hidden or misleading.

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

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

The description is front-loaded with the core purpose and output, then packs relevant usage patterns and constraints. It is longer than minimal, and the final 'unrelated work / missing required inputs' line is mostly boilerplate, but nearly every sentence adds decision-useful information.

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

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

For an 8-parameter creative generation tool with no annotations, this description is complete: it covers what the tool does, how it works, what it returns, how to use key parameters, rate limits, and when not to call it. Since an output schema exists and is referenced, the agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds practical meaning beyond the schema: it maps aspect choices to specific formats ('portrait' for phone/social, 'story' for TikTok/Reels), gives concrete negative-prompt syntax, demonstrates count:4 for variation grids, and clarifies that Groq automatically enhances the prompt. This meaningfully supplements the raw parameter definitions.

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

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

The opening sentence names an exact verb and resource — 'Generate stunning AI images from any description' — and the use-case list (photos, art, logos, cinematic stills, anime, UI mockups, product shots) makes the generation-only scope unmistakable. This clearly separates it from image_analyze and other non-generation siblings, even though no sibling is named explicitly.

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

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

The description contains an explicit 'When to use' and 'When not to use' section, which is more than nothing. However, 'call image_generate when the user's request matches this capability' is essentially tautological, and 'a safer read-only route is more appropriate' gestures at alternatives without naming them, so the routing guidance is only weakly actionable.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses no auth, a rate limit of 3 free searches per day per IP, a performance expectation of under 60 seconds, and the output contents. These are exactly the behavioral traits an agent needs beyond the schema.

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

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

The capability is front-loaded and the description remains compact despite including operational context. The 'When to use' sentence is somewhat tautological, but the overall structure is scannable and free of excessive detail.

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

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

For a simple 2-parameter tool with an output schema, the description covers inputs, output contents, quota, auth, and latency. It omits rate-limit failure behavior and does not clarify the relationship with leadsignal_generate, but neither is required for basic correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by constraining trade to 24 supported trades and city to any US city, going beyond the schema's examples. It does not enumerate the full list of supported trades, but the schema already provides representative examples.

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

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

The description clearly identifies the capability: AI lead generation for contractors/local businesses, taking a trade and city and returning 5 qualified leads with contact info. It is specific and action-oriented, but it does not distinguish itself from the closely named sibling leadsignal_generate, so sibling differentiation is incomplete.

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

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

The description includes explicit when-to-use and when-not-to-use guidance, including avoiding missing required inputs, unrelated requests, and cases where a safer read-only route is more appropriate. It does not name concrete alternative tools, but the stated conditions are clear and usable.

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

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

With no annotations provided, the description carries the full burden and delivers: a rate limit ('3 free searches/day'), performance expectation ('under 60 seconds'), output specifics ('5 qualified leads with contact info'), and a caution that a 'safer read-only route' may be preferable. This is genuinely useful behavioral context beyond what any annotation would provide. It doesn't mention side effects like quota consumption or data handling, but for an alias tool this is a strong disclosure.

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

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

Five sentences packed with distinct information: purpose, I/O, capability limits, quota, and usage guidance. The purpose is front-loaded before constraints. Minor waste exists in the tautological 'when the user's request matches this capability' clause, but overall every sentence earns its place and there is no fluff.

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

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

Complexity is low (2 required params, no enums, no nested objects), the schema covers 100% of parameters, and an output schema exists so return values need no explanation. The description covers purpose, constraints, quota, and usage. The only remaining gap is the ambiguous relationship to the sibling 'leadsignal' tool, which the description labels itself an alias of.

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

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

Schema description coverage is 100% — both 'trade' and 'city' are documented with type, description, and examples directly in the schema. The description adds marginal value by constraining scope ('Supports 24 trades and any US city') and linking inputs to output ('Provide trade and city, get 5 qualified leads'), but it doesn't add format or syntax detail beyond the schema. Baseline 3 applies.

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

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

The description states a specific function — 'AI lead generation for contractors' — with explicit inputs ('trade and city') and output ('5 qualified leads with contact info'). The 'under 60 seconds' and '24 trades / any US city' lines add concrete scope. However, it opens with 'Alias for leadsignal' and the sibling list contains an actual 'leadsignal' tool, so the description does not clarify how an agent should choose between the two, slightly weakening differentiation.

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

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

The description has explicit 'When to use' and 'When not to use' sections, giving exclusions: unrelated work, missing required inputs, and 'when a safer read-only route is more appropriate.' This goes beyond implied usage. However, the when-to-use clause ('when the user's request matches this capability') is tautological and no specific alternative tools (e.g., leadsignal, signal_lookup) are named, so it falls short of a 5.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It discloses the data source (CoinGecko) and return content (live USD price, 24h % change, market cap), which implies a read-only lookup, but it does not explicitly state read-only semantics, rate limits, or potential failure behavior. Acceptable but not comprehensive.

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

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

The core information is front-loaded in the first two sentences, but the later "When to use: call live_price when the user's request matches this capability" is purely tautological, and the "When not to use" clause is generic filler. The useful content could be delivered in half the length.

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

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

For a simple single-parameter read tool with an output schema, the description covers the data source, return fields, and representative input patterns. Minor gaps remain—no explicit note on timeliness/latency or rate limits—but overall an agent can select and invoke this tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds semantic breadth with "100+ others," signaling that symbol accepts any coin beyond the enumerated list, and reinforces that both ticker or name forms work. This enriches meaning beyond the schema's example list.

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

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

Description states a clear verb+resource: "Real-time cryptocurrency price lookup for any coin" and enumerates specific symbols. It explicitly distinguishes itself from sibling market_pulse: "Do NOT use market_pulse for specific coin prices — use this tool." No ambiguity about what the tool does.

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

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

Gives concrete trigger patterns: "Use for ANY 'what is X price', 'X price now', 'how much is X', or 'X USD' query" and explicitly routes away from market_pulse. The generic "when not to use" line is somewhat tautological but the specific exclusions and named alternative provide solid guidance.

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

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

With no annotations, the description carries the behavioral burden, and it adds valuable context by disclosing the 30-minute cache, the 20-free-per-day quota, the aggregated data sources, and the exact output structure. It implies a read-only snapshot and could explicitly state that no state is mutated, but the disclosed operational details go well beyond what the schema provides.

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

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

The opening is front-loaded with purpose, return contents, cache, and quota, which is effective. The final 'When to use' section is circular and the exclusions are vague, so a few sentences do not earn their place; the text could be tightened without losing value.

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

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

For a read-only market-intelligence tool with three optional, fully documented parameters and an output schema, the description provides enough operational context: purpose, sources, return fields, caching, quota, and basic usage boundaries. The main missing piece is concrete selection guidance against the many sibling pulse/data tools, but the core invocation is well covered.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description does not materially deepen parameter understanding. The mention of 'AI, agents, and research' loosely maps to the domains parameter and the 30-minute cache relates to depth, but focus and domains meanings remain exactly as documented in the schema.

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

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

The description clearly identifies the tool as a real-time market intelligence snapshot spanning AI, agents, and research, and it lists both the data sources and the concrete return components. However, it does not explicitly contrast itself with overlapping siblings such as zambo_pulse, substrate_breakthroughs, or live_price, so the differentiation is strong but not complete.

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

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

The 'When to use' sentence is effectively tautological ('when the user's request matches this capability') and the exclusions are generic ('unrelated work', 'missing required inputs'). No specific trigger conditions or named alternatives are given, and since the schema has zero required parameters, the 'missing required inputs' caveat is confusing rather than helpful.

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

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

No annotations are present, so the description carries full behavioral burden. It clearly discloses that this is a one-time grant per email, requires an email, returns success status plus upgrade links, and explains what happens after the extension is exhausted, including pricing. This is unusually transparent for a mutating tool.

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

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

The main purpose is front-loaded, and the one-time-extension constraint is valuable. However, the 'When to use: call mcp_extend when the user's request matches this capability' sentence is a tautology that wastes words, and the when-not-to-use section is somewhat generic despite the useful exclusion about read-only routes.

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

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

For a single-parameter tool with an output schema, this description is complete: it covers purpose, prerequisites, permanence constraints, return value, and post-extension options. Nothing essential is missing for an agent to decide whether and how to call this tool.

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

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

Schema coverage is 100%, so the schema already fully documents the email parameter. The description adds contextual color ('one extension per email, ever' and the upgrade pitch) but does not need to compensate for missing parameter documentation.

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

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

States a specific action ('Grant 10 additional free daily calls') with a clear condition ('when a user has reached the free tier limit'). This is concrete and readily distinguishable from sibling tools like day_pass_activate or zambo_limit by its unique grant-plus-one-time-scope behavior.

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

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

Gives the activation condition (free tier limit reached), a hard prerequisite (email), and a permanent constraint (one extension per email ever). It also provides when-not-to-use guidance, though the 'safer read-only route' reference is generic and does not name a specific alternative tool.

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

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

No annotations are present, so the description carries the full burden. It conveys that the tool fetches a guide and is 'Free, always', implying no cost and no destructive effect, but it does not explicitly state read-only status, authentication needs, or whether calling it has side effects. The vague 'safer read-only route' warning adds confusion about whether this tool itself is read-only.

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

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

The first sentence is front-loaded and informative, but the 'When to use' sentence duplicates the earlier 'Call when' trigger, and the when-not-to-use clause is boilerplate that could apply to almost any tool. Roughly half the text does not earn its place.

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

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

For a tool with only two optional parameters and an output schema, the description covers the resource, target formats, use triggers, and cost. It could be more complete by explicitly stating read-only/no-side-effect behavior and naming concrete alternatives, but the output schema covers the return shape.

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

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

The input schema already documents both parameters at 100% coverage, so the baseline is 3. The description reinforces the supported target formats but does not add meaningful syntax or behavior details beyond what the schema already provides.

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

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

The description names a specific resource (the zambo.dev install guide), a concrete verb ('Get'), and a clear deliverable: ready-to-paste config blocks for Claude, Cursor, Windsurf, and agent.json. This clearly distinguishes it from the large sibling set.

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

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

It explicitly states when to call ('a user asks what MCP tools to use, or needs an install config') and includes a when-not-to-use clause. However, the exclusions are generic and somewhat vague — 'unrelated work', 'missing required inputs', and 'safer read-only route' — and no concrete alternative tool is named.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add some context — generation speed ('in seconds') and the return shape ('structured daily meals with prep times') — but stays silent on side effects, persistence, rate limits, or any prerequisites. Additionally, the 'missing required inputs' exclusion conflicts with the schema, which declares zero required parameters.

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

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

The core purpose, return format, and trigger phrases are usefully front-loaded in the first three sentences. But the 'When to use: call meal_plan when the user's request matches this capability' sentence is pure tautology, and the closing when-not block is generic filler that adds no decision value, so not every sentence earns its place.

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

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

With an output schema present and all six optional parameters fully documented, the description need not cover return values or parameter syntax. However, with zero annotations and no sibling differentiation, the thin behavioral disclosure and the vacuous usage guidance leave the definition adequate but incomplete for an agent choosing among meal_plan and adjacent-looking tools such as fridge_forge or tokendiet_analyze.

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

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

Schema description coverage is 100%, so the baseline of 3 applies and the description is not obligated to explain parameters. It lightly recaps a few parameters ('dietary restrictions, budget, cuisine preferences, and number of days'), which adds nothing beyond the schema's own field descriptions, so it remains at baseline.

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

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

The opening sentence states a specific verb and resource — 'Generate a personalized meal plan' — and lists concrete deliverables: recipes, macros, a shopping list, and 'structured daily meals with prep times.' This level of specificity makes the tool's scope unmistakable and implicitly distinguishes it from the many sibling generation/analysis tools, even though no sibling is named.

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

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

It provides concrete trigger phrases ('meal plan', 'what should I eat', 'plan my meals', 'make me a diet plan'), which is genuinely useful routing guidance. However, the 'When to use: call meal_plan when the user's request matches this capability' sentence is a pure tautology, and the when-not list ('unrelated work, missing required inputs, or when a safer read-only route is more appropriate') is generic boilerplate with no alternative tool named.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses that the tool returns a direct image URL that renders inline and implies creation of an image resource. However, it does not mention persistence, hosting, cost, rate limits, moderation, or other side effects of generating an image.

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

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

The description is front-loaded and readable, but it contains redundancy: 'Use when user says...' is followed by 'When to use: call meme_forge when the user's request matches this capability,' which repeats the same idea without adding value.

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

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

For a relatively simple tool with complete parameter schema and an output schema, the description covers the input format, output behavior, and when to invoke it. The main gaps are behavioral caveats rather than essential invocation details.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a helpful high-level framing that concept maps to the visual scene and top/bottom text, but it mostly restates what the schema already documents.

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

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

States a specific verb and resource: 'Generate a meme image — scene + overlaid caption text — as a shareable image URL.' This clearly identifies what the tool does and differentiates it from generic image tools by focusing on meme generation. However, it does not explicitly contrast siblings like image_generate or gif_animate, so it stops short of a 5.

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

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

Provides concrete trigger phrases ('make a meme', 'generate a meme about X') and a when-not-to-use note mentioning unrelated work, missing inputs, and safer read-only routes. This is clear context, but it does not name specific alternative tools or give exclusion conditions relative to siblings.

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

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

With no annotations provided, the description carries the burden and does reveal rate limits ('30 free/day'), current pricing (June 2026), external/personalized Groq service, and ranking behavior. It does not explicitly state read-only or side-effect status, but as a recommendation tool this is minor, and the output schema covers return shape.

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

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

Purpose is front-loaded and the 'Best for' / 'When to use' / 'When not to use' sections are scannable. The 'when the user's request matches this capability' phrase is tautological and some when-not language is generic, but on the whole it remains efficient.

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

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

For a 5-param tool with an output schema and no annotations, this covers the core decision context: ranked output, budget/token constraints, quota, and when to refrain. The only notable omission is behavior after the free daily limit, but that is edge context.

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

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

Schema already describes all 5 parameters (100% coverage), so baseline is 3. The description adds semantic context by linking parameters to 'task, token budget, and cost constraints' and explaining that use_case triggers a personalized Groq-powered insight, enriching the bare schema.

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

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

The opening sentence names a concrete action ('Get a ranked recommendation') and resource ('AI models'), then scopes it by providers, model count, and task/constraints. The 'Best for' examples make the intended query types unmistakable, distinguishing it from generic zambo_* sibling tools.

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

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

The description explicitly labels 'When to use' and 'When not to use' and gives concrete query examples. The exclusion list is somewhat generic ('unrelated work', 'missing required inputs', 'safer read-only route') and doesn't name a specific alternative sibling, so it is clear but not perfectly precise.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses 60-second caching, free/no auth, data source, the NadHawk score thresholds, tier progression, and output composition. It even covers API key provisioning details, making the tool's behavior highly predictable.

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

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

The core is front-loaded and information-dense, but the trailing 'When to use' section is tautological ('call monad_city when the user's request matches this capability') and the API key retrieval paragraph adds length. These elements prevent it from being as tight as it could be.

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

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

Given zero parameters and the presence of an output schema, the description covers all necessary context: what is returned, how to interpret scores, caching, auth requirements, use cases, and when to avoid calling. No critical information for invoking the tool correctly is missing.

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

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

The input schema has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics, but none are needed; it instead explains the output structure, which is appropriate.

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

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

The description clearly states the tool returns top contracts and whale wallets on Monad mainnet via NadCity, listing specific components (top 10 contracts, top 8 wallets, district breakdown). However, it does not explicitly differentiate from similar sibling tools like monad_pulse, so it is clear but lacks direct sibling contrast.

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

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

It provides explicit use cases: contract due diligence, whale tracking, and mapping active Monad activity. It also includes when-not-to-use guidance ('do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate'), though it does not name alternative tools.

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

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

With no annotations provided, the description takes on the full burden. It discloses key behavioral traits: data is 'Cached 30 seconds', it's 'Free, no auth', and it provides explicit health thresholds (avgBlockTimeMs > 500 or wsConnected false indicates stress). It also surfaces the NadCity API key retrieval mechanic for users extending to direct API calls. It does not cover failure behavior, but the disclosed traits are substantive.

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

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

The description front-loads the core purpose and return fields, which is good. However, it becomes bloated with a lengthy Zambo MCP API key passage and a generic 'When to use' section that is largely tautological ('call monad_pulse when the user's request matches this capability'). Several sentences could be trimmed without losing value.

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

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

Given the tool has an output schema, return values are likely already specified. The description adds useful operational context: caching, authentication, network-stress thresholds, and when to call it. It is missing explicit failure-mode information, but for a read-only health-check tool with a rich output schema, the coverage is strong.

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

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

The tool has zero input parameters, so the schema is already complete. Per the baseline for 0-param tools, the description need not explain input semantics. The extra information about API keys is tangential to this tool's parameters but does not affect scoring. The description adds no parameter meaning, but none is required.

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

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

The description opens with a clear statement of what the tool provides: 'Live Monad mainnet network stats via NadCity' and then enumerates the specific metrics returned (TPS, active wallets, block time, etc.). This unambiguously identifies the resource (Monad mainnet) and distinguishes it from sibling tools like market_pulse or zambo_pulse by its network-specific focus.

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

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

It gives an explicit usage context: 'Use before any on-chain Monad action to check network health.' It also includes a 'When not to use' clause, though the wording is generic ('unrelated work, missing required inputs, or when a safer read-only route is more appropriate') and does not name specific sibling alternatives. This is clear context but lacks concrete alternative routing.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It adds useful context by stating that no Zambo Pass is required and that the wallet address is for payouts. However, it does not disclose registration side effects, idempotency, or what happens on duplicate registration, which are important for a registration/write action.

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

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

The opening sentence is concise and front-loaded, but the 'When to use' section is redundant and tautological, adding little information. The description could be tightened by removing the generic condition and focusing on concrete registration behavior and eligibility.

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

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

For a simple registration tool, the description covers the core inputs and the key eligibility point (no Zambo Pass required). The output schema covers return values. Still, it omits behavioral expectations such as whether registration is immediate, persistent, or limited to once per agent, leaving some gaps for an agent deciding whether to invoke it.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description introduces a confusing mismatch: it says to provide a 'partner_id' while the schema defines 'agent_id.' This could mislead an agent into looking for a non-existent parameter. No additional semantic value is added beyond what the schema already documents.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Register as a Zambo partner.' The additional context about wallet addresses and payouts makes the intent unambiguous. However, it doesn't explicitly distinguish itself from siblings like partner_stats, though overlap is minimal.

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

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

The description includes explicit 'When to use' and 'When not to use' sections, which is helpful. However, the guidance is largely generic and tautological ('when the user's request matches this capability'), and it does not name specific alternative tools or concrete scenarios beyond 'missing required inputs' and 'safer read-only route.'

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Check' implies read-only, but the description never states there are no side effects, what credentials are needed, or what happens on failure; it also points to a nonexistent 'partner_id' parameter. This is a meaningful gap for a financial/payout tool.

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

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

The core sentence is concise and front-loaded, but the when-to-use/not-to-use block is filler that restates the capability without adding decision value. It is short enough not to be bloated, yet not every sentence earns its place.

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

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

For a simple read tool the description conveys purpose and returned metrics, but it omits the identity-parameter mismatch and provides only tautological usage guidance. An agent cannot reliably know whether to send agent_id or ref_code, and the requiredness is unclear.

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

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

Schema coverage is 100% and documents agent_id/ref_code well, but the description instructs 'Provide partner_id,' which appears nowhere in the schema. This actively misleads an agent and overrides the schema's value, so the baseline 3 is not deserved.

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

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

The first sentence clearly identifies the operation ('check'), the resource ('partner stats'), and the specific output fields ('total conversions and pending payout balance'). It is distinguishable from sibling tools like partner_register, though it does not explicitly name an alternative.

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

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

The description has explicit 'When to use' and 'When not to use' headings, but the content is circular and generic: 'call partner_stats when the user's request matches this capability' and 'do not call it for unrelated work.' It names no sibling alternative and gives no concrete routing criteria.

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