Zambo

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the output details (up to 8 products, relevance scores, endpoints) but does not disclose additional behavioral traits beyond what annotations provide. No contradiction with annotations.

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

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

The description is mostly concise, with the core purpose front-loaded in the first sentence. However, the 'When to use' line 'call capability_search when the user's request matches this capability' is redundant and could be trimmed without loss, slightly reducing efficiency.

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 provides enough for a read-only search tool: purpose, output summary, and explicit usage boundaries against zambo_universal. The output schema covers return values, and annotations cover safety. The 'safer read-only route' mention is vague but not critical. Overall, the tool is adequately specified.

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 itself richly documents 'q' and its aliases with examples. The tool description adds no parameter-level meaning beyond what the schema already provides, 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 ('Search') and resource ('all 100+ Zambo Stack tools'), clearly distinguishing its discovery role. It also explicitly differentiates from the sibling 'zambo_universal' by advising to use it 'when you know exactly which product you want.'

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

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

Provides clear when-to-use and when-not-to-use guidance, including a specific comparison to 'zambo_universal' and an exclusion for 'safer read-only route.' However, the phrase 'when the user's request matches this capability' is somewhat tautological, and the alternative tools beyond zambo_universal are not named, leaving some ambiguity.

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

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

The description adds useful behavioral context beyond annotations: 'Verified daily — dead links auto-removed' indicates data freshness and maintenance, and 'Free, no auth' clarifies access requirements. The readOnlyHint, idempotentHint, and openWorldHint are already covered by annotations, so the description supplements rather than repeats them.

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

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

The description is well organized: a clear value proposition with examples, freshness/access notes, then usage guidance. The 'When to use / When not to use' bullet is a nice structural touch, though somewhat generic in content.

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

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

For an optional-parameter, read-only lookup tool with an output schema and rich param docs, the description covers the main invocation facts: no auth, data freshness, recommendation behavior, and empty-stack behavior. The usage guidance is slightly generic, but nothing needed to call the tool 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%, with each parameter already well-documented (examples, enum values, default, empty behavior). The description's mention of 'pass your tech stack' reinforces the stack parameter but adds no meaning 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 clearly identifies a specific resource ('AI and cloud startup credit programs') and the tool's purpose ('live, verified index' with matched recommendations). It distinguishes itself as a credit-program lookup domain, though it doesn't explicitly contrast with 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 includes 'When to use' and 'When not to use' sections, but the guidance is generic ('when the user's request matches this capability') and doesn't specify concrete triggering scenarios or name alternative tools. It gives some exclusion guidance, but no real decision framework.

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

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

Annotations already declare this is a write operation (readOnlyHint=false) that isn't idempotent and isn't destructive. The description adds meaningful behavior beyond that: the two-call protocol and the hard guarantee that activation never occurs without a verified transfer. Failure/payment-error handling is not covered, but the key behavioral constraints are.

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 capability and the two-step flow are front-loaded and efficient. The trailing 'When to use / When not to use' paragraphs are generic filler that restate the obvious, preventing 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?

With an output schema present, return values need not be described. The description covers the payment-to-activation lifecycle and the verification gate, leaving only minor gaps such as what happens on payment failure.

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 would be 3. The description goes further by explaining the role each parameter plays in the flow: payment_intent is the server-issued token from the first call, and tx_hash is the confirmed Base USDC transfer used to activate access.

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 with concrete detail: create a $1.49 USDC payment intent on Base, then verify a tx_hash to activate 24-hour access. The two-phase nature of the tool is unambiguous, and no sibling tool (capability_search, live_price, ghost_audit_*, etc.) overlaps with this capability.

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

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

It gives real sequencing guidance: call with no arguments first to create the payment intent, then call again with payment_intent and tx_hash. The generic 'when to use / when not to use' boilerplate adds little, but the explicit two-step invocation flow is genuine guidance an agent needs.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, lowering the burden. The description goes well beyond by revealing the markdown report format, the Achilles 10-stage structure, the score range, finding severities, actionable fixes, the prerequisite that the audit must be complete, and the free vs. Pass quota difference. No annotation contradiction exists.

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 contents, then adds prerequisite and quota context. It is reasonably concise, but the 'When to use' sentence is filler that merely restates the tool's purpose, and 'safer read-only route' is imprecise.

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, read-only tool with an output schema, the description is complete: it specifies what the report contains, the prerequisite status check, quota implications, and where the audit_id comes from (via the schema). No missing information would prevent 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% for the single required audit_id parameter, including provenance ('returned by ghost_audit_site'). The description does not add further parameter-level detail, 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 opens with a specific verb and resource: 'Retrieve the full markdown report for a completed Ghost Audit.' It then details the exact contents (0-100 score, severity findings, stage-by-stage analysis, fixes), clearly distinguishing it from the sibling status-checker ghost_audit_status and the site-initiating ghost_audit_site.

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 says to call ghost_audit_status first to confirm completionainer and includes 'When to use' and 'When not to use' sections. However, the 'When to use' clause is somewhat circular ('when the user's request matches this capability'), and the 'safer read-only route' alternative is named vaguely rather than specifying a 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), it discloses the 10-stage pipeline, SSE streaming, approximate 90-second completion time, returned URLs (audit_id, stream_url, download_url), the daily free quota, and optional pass-based authentication. This is rich behavioral context that annotations alone do not convey.

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

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

Long but efficiently packed with main purpose, returns, stage list, timing, quota, and usage gates. There is slight redundancy between 'one completed audit/day' and 'No payment or signup required for the daily audit,' but every sentence otherwise 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 complex, multi-stage audit producing asynchronous output, it specifies all call-relevant details: returned identifiers and URLs, streaming behavior, completion time, rate limits, and when to avoid calling. The output schema exists, so return-value details need not be repeated in the description.

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, including URL format and the email/pass relationship. The description reinforces pricing context and the no-signup free tier, but the marginal additional meaning is modest, 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?

Explicitly states it runs a 10-stage ghost audit on any website and lists the exact categories of findings (SEO gaps, AI discoverability, conversion leaks, etc.). This clearly distinguishes it from siblings like ghost_audit_report and ghost_audit_status by framing it as the full audit runner.

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

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

Provides explicit 'When to use' and 'When not to use' sections, plus rate-limit and auth context (free daily audit vs. Zambo Pass). However, it does not name specific sibling alternatives such as ghost_audit_report or ghost_audit_status as the safer read-only route, leaving some inference to the agent.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable operational detail—return values of 'complete' vs 'running' with elapsed time, plus readiness for report download—while staying consistent with the annotations.

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

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

The description efficiently packs purpose, required input, status values, polling cadence, and expected completion time into a compact block. The generic when-to-use/when-not-to-use sentences add some filler, but they do not meaningfully hurt readability.

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 polling tool with readOnly/idempotent annotations and an output schema, the description fully covers how to call it, what statuses to expect, and how long to wait. Nothing an agent needs to invoke and interpret the result 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 describes audit_id as 'returned by ghost_audit_site.' The description repeats that provenance without adding format, validation, or additional semantic detail, so it meets the baseline but adds no new parameter meaning.

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

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

The description opens with a specific verb-object pair—'Check the status of a running Ghost Audit'—and makes the tool's purpose unmistakable. The running-to-complete status transition also clearly separates it from related tools like 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?

It provides concrete guidance: require audit_id from ghost_audit_site, poll every 15-30 seconds, and expect 60-120 second completion. The 'when not to use' clauses are present but generic and do not name a specific alternative, so it stops short of fully explicit 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?

Beyond the annotations, the description adds valuable behavioral context: rate limiting (3 free searches per day per IP), auth requirements (none), expected speed (under 60 seconds), and scope (24 trades, any US city). It also clarifies output content (contact info) without contradicting readOnlyHint=true.

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 key constraints, and it is reasonably compact. The 'When to use' line is somewhat tautological and the final exclusion is vague, so a small amount of trimming could improve clarity.

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 tool with two required parameters, an output schema, and read-only annotations, the description covers inputs, output, scope, quota, and auth. Nothing essential for calling 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 already provides good descriptions and examples for both trade and city. The description adds the US-city constraint and the 24-trade limit, which are not in the schema, though it does not enumerate the supported trades.

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

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

The description clearly states that the tool takes a trade type and city and returns 5 qualified leads with contact info, so the purpose is evident. However, it does not explicitly distinguish itself from sibling tools like leadsignal_generate or other lead-generation 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 includes explicit 'When to use' and 'When not to use' guidance, covering unrelated work and missing required inputs. It does not name concrete alternative tools, and the 'safer read-only route' exclusion is vague since the tool itself is annotated as read-only.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat those. It does add context that the data comes from CoinGecko and includes live USD price, 24h change, and market cap. However, it does not mention that the symbol lookup may be case-insensitive (lightly covered by schema) or that prices may be delayed, nor does it disclose any rate limits or potential for unknown coins to return errors. With annotations covering safety, a 3 is fair.

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 strictly necessary, especially the 'When to use' section which restates the same guidance already given. It is front-loaded with the key capability and returns, but the latter part could be trimmed. No wasted words about the tool itself, but the usage section is a bit repetitive.

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 provides sufficient information: what it does, supported coins, return values, and when to use it. The output schema exists, so return format is covered. The main missing detail is error handling for unsupported coins, but that is not critical for an agent to call the tool correctly.

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

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

The schema already describes the 'symbol' parameter well, listing example tickers and noting case-insensitivity, and coverage is 100%. The description adds the list of supported coins ('BTC, ETH, SOL, DOGE, BNB, XRP, MATIC, AVAX, ADA, LINK, and 100+ others') and specifies the return fields, which is helpful but not necessary for invoking the tool. The description does not introduce new syntax or format details beyond the schema.

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

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

The description clearly states the tool performs real-time cryptocurrency price lookup, lists specific supported coins (BTC, ETH, SOL, etc.), and specifies the returned data (live USD price, 24h change, market cap). It explicitly differentiates itself from market_pulse by saying 'Do NOT use market_pulse for specific coin prices — use this tool.' This leaves no ambiguity about the tool's purpose.

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

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

Provides explicit 'When to use' and 'When not to use' sections, and explicitly names market_pulse as the alternative to avoid for specific coin prices. This is particularly strong guidance, as it directly tells the agent when to prefer this tool over a sibling.

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

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

Beyond annotations, the description adds substantive behavioral detail: 'Two-phase analysis: instant pattern library scan (12 attack vectors) + Groq semantic analysis,' return values ('injection_risk 0–100, recommendation safe/review/block, safe rewritten version when possible'), and a rate limit ('50 free/day'). These details meaningfully enrich the annotation-provided read-only/idempotent 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 the core purpose Alert, but it becomes repetitive with overlapping 'Best for' and 'When to use' sections. The line 'call prompt_shield when the user's request matches this capability' is tautological, and the brand prefix 'Zambo Stack —' adds little. It would be stronger with tighter phrasing.

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 an output schema and fully documented parameters, the description is nearly complete: it covers purpose, analysis modes, output format, free-tier quota, and usage boundaries. Minor gaps like behavior when the daily free limit is exhausted are not addressed, but the overall context is sufficient.

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

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

Schema description coverage is 100%, and the schema already explains parameters like mode, prompt, system, and context. The description adds little parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Detect prompt injection, jailbreaks, and policy bypass attempts' and clarifies it operates 'before they reach your AI model.' It is clear and specific, but it does not explicitly differentiate from sibling tools, 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 provides explicit 'When to use' and 'When not to use' sections, plus 'Best for' examples like 'validate user input before LLM call' and 'detect jailbreak attempts.' However, the when-to-use condition is somewhat circular ('when the user's request matches this capability') and no specific sibling alternatives are 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?

Annotations already mark it read-only, idempotent, and non-destructive; the description adds the paid vs free mode, the Zambo Pass email requirement for full results, and the 'no auth required for teaser' detail. It also previews the output contents, which is useful context beyond the annotations, and nothing contradicts them.

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

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

The core behavior is front-loaded and the two-mode pricing is scannable. The when-to-use sentence is a tautology and some pricing detail is marketing-flavored, so not every sentence earns its place, though overall length is reasonable.

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 full output schema, safe annotations, and complete input schema, the description covers the required public-repo input, the optional email mode, and what the tool returns. It is only slightly incomplete because it never names a specific sibling alternative or gives a concrete rule for choosing audit over review.

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?

All three parameters are already fully described in the input schema, including repo_url's example and email's optional effect, so the high schema-coverage baseline applies. The description reinforces the email/full-audit relationship but doesn't add new meaning for repo_url or vibe_context.

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

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

The first sentence states a specific verb and resource: AI code audit of any public GitHub repository. The next sentence enumerates concrete outputs (Provibe Score, vulnerability list, dead code map, execution plan), making the function clear. It doesn't explicitly differentiate from code_review, but its unique score and audit framing make it identifiable.

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 a when-to-use and when-not-to-use block and explains the teaser vs full-audit switch based on whether an email is supplied. However, the guidance is mostly generic or tautological ('when the user's request matches this capability', 'unrelated work') and never names an alternative tool, so it does little to disambiguate from similar siblings.

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

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

Annotations already mark readOnlyHint=false and openWorldHint=true, and the description adds nuance: it may execute a live read-only branch, otherwise returns planned vs executed tools, and requires user confirmation for consequential actions. It goes beyond annotations without contradicting them.

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

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

The description is lengthy but justified for a complex universal router. It front-loads the core purpose, then covers behavior, usage rules, and exclusions in a logical order. Every section earns its place, though it could be slightly tightened.

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 breadth, an output schema, and comprehensive annotations, the description covers all critical aspects: execution flow, planned vs executed distinction, confirmation requirements, and multi-step continuation via session_id. No obvious gaps for an agent to call it correctly.

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

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

Schema coverage is 100% with good parameter descriptions, but the description adds value by listing synonyms for 'need' (message, query, prompt, etc.) and enumerating supported context keys. This supplements the schema without redundancy.

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

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

The description clearly states the tool's role as a universal entry point that routes requests across 100+ tools, listing concrete categories like strategy AI, code audits, and live market data. It distinguishes itself from siblings by being the aggregator/router, so an agent knows exactly 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?

Explicit 'When to use' and 'When not to use' sections give clear direction, including a safer read-only alternative. It also names a specific alternative for agent coordination (native Zambo coordination tools), leaving no ambiguity about routing decisions.

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