Zambo

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety and repeatability profile. The description adds complementary value by disclosing the exact return contents (relevance scores, descriptions, taglines, callable API endpoints), which is useful behavioral context beyond what the annotations state. 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?

Two sentences with zero filler: the first front-loads the purpose ('Search across the supported Zambo tool catalog'), and the second adds only the valuable return-format detail. No word is wasted, and nothing important is deferred or buried.

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?

What an agent needs to call this correctly is present: purpose, return contents, and fully documented parameters in the schema. Because an output schema exists, the return values needn't be repeated. The only minor gap is that ranking/sorting or a limit on results is not hinted at, but that's a small omission for a simple search tool with a rich 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% - every parameter (q, query, keyword, search) is documented, including the fact that all are aliases and the guidance 'Use q when possible.' The description itself adds no parameter detail, but per rubric the baseline is 3 when the schema carries the full weight. It neither compensates nor under-delivers.

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

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

The description states a specific verb + resource ('Search across the supported Zambo tool catalog for a use case') and goes beyond by naming what it returns (relevance scores, descriptions, taglines, callable API endpoints). Against siblings that are all concrete execution tools (credithunt, prompt_shield, live_price), this is clearly the discovery/search tool, so it distinguishes itself without extra words.

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?

'for a use case' establishes the clear discovery pattern: use this when you have a goal but don't know which sibling tool to invoke. The sibling list (ghost_audit_report, leadsignal, etc.) makes the alternative set implicit. However, the description never explicitly says 'when you already know the tool, call it directly' or names an alternative, so it lacks an explicit when-not condition that would 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effect profile. The description adds that the index is 'live' and 'verified' and enumerates the output fields (eligibility details, current links, credit info), which goes beyond the annotations. No contradictions.

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

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

Two sentences with no redundant words. The core purpose and inputs are front-loaded, and the output components are listed efficiently. Every clause adds 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 states inputs (optional stack/stage) and outputs (programs, eligibility, links, credit info). The presence of an output schema covers return details, and all parameters are documented. The tool is simple and well-scoped; nothing critical is missing for correct invocation.

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

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

The input schema provides full descriptions for all three parameters (stack, stage, min_value), so schema coverage is 100%. The description only repeats that it accepts an optional stack and stage without adding new semantics, formats, or relationships. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the tool provides a 'live verified index of AI and cloud startup credit programs' and accepts optional stack and stage inputs. It is specific about the resource (credit programs) and the action (retrieval/filtering), and it stands apart from unrelated 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 implies usage when an agent needs matching startup credit programs and indicates optional filters. It does not explicitly list exclusions or alternatives, but none are needed given the unrelated sibling set. The context is clear enough for an agent to decide when to call it.

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

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

The description goes beyond the annotations by explaining the conditional flow (payment challenge vs. activation) and the precondition that a verified transfer must occur. It also indicates that a spend receipt is returned, reinforcing the destructiveHint annotation without contradicting it. It could add more detail about what state is consumed, but the core behavioral traits are disclosed.

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 fairly compact and front-loaded with purpose, then covers inputs, outputs, and preconditions. The opening phrase 'Agent-native access activation endpoint' is somewhat redundant with the title, and the list of result contents duplicates what an output schema would provide, 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?

The description is largely complete for an activation tool: it names the accepted inputs, the two possible outcomes, the key result fields, and the activation precondition. The main gap is that the 'existing access key' path is mentioned but not shown as a concrete parameter or header, so an agent might not know exactly how to invoke that path.

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 covers the single x_payment parameter with a precise description, so the baseline is 3. The description adds the 'existing access key' alternative, which is not mapped to any schema property, making its usage slightly ambiguous. It provides useful context but does not fully resolve how that alternative is supplied.

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

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

The description states a specific action and resource: this is an activation endpoint for day passes. It clearly distinguishes the tool from siblings by describing its unique behavior—accepting a payment envelope or access key and returning a payment challenge or activation result—so an agent can infer what it is for without needing to inspect the schema.

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

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

The description provides clear usage context: it accepts an optional payment envelope or an existing access key, and activation only happens after a verified transfer. It does not explicitly name alternatives or state when not to use it, but no sibling appears to perform a similar activation flow, so the context is sufficient for basic selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the output format (markdown) and the report structure, while not contradicting any annotation.

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

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

A single dense sentence front-loads the key output ('Full markdown report') and then lists the report contents without filler. Every phrase earns its place and the structure supports quick agent scanning.

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 reporting tool with an output schema, the description and schema together cover when to call it, how to get the required audit_id, and what the return value contains. Nothing essential is left ambiguous.

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

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

Schema description coverage is 100%, and the schema already explains that audit_id is 'The audit_id returned by ghost_audit_site.' The description reinforces that the audit must be completed but does not add new parameter-level semantics, 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 description states a specific verb and resource: it returns a full markdown report for a completed Ghost Audit. It enumerates the exact contents (Achilles 10-stage score, severity-ranked findings, stage analysis, recommended fixes), which clearly distinguishes it from sibling tools like ghost_audit_site or ghost_audit_status by lifecycle and output type.

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

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

The phrase 'for a completed Ghost Audit' plus the schema's note that audit_id comes from ghost_audit_site makes the intended usage clear: this is the post-audit report step. It does not explicitly name alternatives or exclusion conditions, but the context is strong enough for an agent to route correctly.

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 destructiveHint=true, openWorldHint=true, and readOnlyHint=false, but the description adds no further behavioral context. It does not disclose side effects like consuming an audit credit, the asynchronous nature of the audit, or that it actively scans the target site. Given the annotations are present, the description's failure to elaborate on these traits leaves a notable gap.

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

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

The description is a single sentence that efficiently front-loads the core purpose ('Achilles 10-stage audit for a website') before listing outputs. It is not overly verbose, though the list is long. It could be broken into two sentences for readability, but it is acceptable.

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 output schema likely covers return structure, so the description's list of return values is somewhat redundant. However, it lacks important process context: that the audit is asynchronous, that it may consume credits (implied by email param), and that progress can be tracked via ghost_audit_status. These omissions leave an agent uncertain about the full call flow.

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 both parameters have descriptive text (url with example, email with note about passes). The tool description does not add any parameter-level meaning beyond the schema, so it neither helps nor hinders. A baseline of 3 is appropriate.

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

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

The description states a specific verb ('audit') and resource ('a website'), and lists concrete outputs (SEO gaps, AI discoverability, conversion leaks, etc.) that clearly distinguish it from sibling tools like ghost_audit_report (which likely retrieves a completed report) and ghost_audit_status (which tracks progress). The 'Achilles 10-stage' phrase adds specificity.

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

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

The description implies this tool initiates a new audit by listing the returned audit ID and live stream URL, but it does not explicitly compare against alternatives. It does not state 'Use this to start an audit; use ghost_audit_status to check progress' or mention when to use provibe_audit instead. Guidance is only implicit.

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

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

The annotations already cover the safety profile with readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context by specifying what the status report contains: running/complete state, elapsed time, and report availability.

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

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

Two sentences with no filler. The core purpose is front-loaded in the first sentence, and the second sentence efficiently lists the return details.

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

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

For a single-parameter, read-only status tool with strong annotations and an output schema, the description covers the essential behavior. Nothing critical is missing 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%, and the single parameter is already described as the audit_id returned by ghost_audit_site. The description only restates that the audit is identified by audit_id, adding no new meaning beyond the schema.

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

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

The description clearly identifies the resource ('Ghost Audit') and the action ('status report'), and it states the key outputs: running/complete state, elapsed time, and report availability. It does not explicitly contrast with ghost_audit_report or ghost_audit_site, but 'status' is distinct enough to avoid serious confusion.

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

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

There is no guidance on when to use this tool versus ghost_audit_site or ghost_audit_report. The schema notes that audit_id comes from ghost_audit_site, but the description itself does not explain the workflow or any exclusions.

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

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

The description says the tool logs and records into a timeline, which is a write operation, but annotations declare readOnlyHint=true. This is a direct contradiction: 'append-only' and 'Zambo records the report' cannot be read-only in any meaningful sense. The appended nature also strains the idempotentHint=true annotation.

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

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

Two compact sentences with no filler. The core purpose is front-loaded, the scope is stated immediately, and the behavioral caveat about Zambo's claims is kept to one clear sentence.

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 ten parameters, nested objects, and no explicit parameter elaboration in the description, the summary is too thin to be fully complete. More importantly, the contradiction with readOnlyHint undermines trust in the documented behavior, and the description omits relevant redaction/hashing behavior that would clarify how inputs are handled.

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

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

Schema description coverage is 100%, so the schema already documents the ten parameters, including redacted_inputs_hash and timestamps. The description adds high-level context about logging external actions but does not add meaning beyond the schema. This matches the baseline of 3 for high schema coverage.

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

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

The description states a specific verb and resource: logging an action into an append-only job timeline. It also clearly distinguishes the tool by saying Zambo records the report but does not claim it ran or observed the action, which sets it apart from audit tools that report first-hand observations.

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

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

The phrase 'action performed outside Zambo' gives a clear when-to-use condition, and 'does not claim it ran or observed the action' helps avoid misuse. It does not name sibling tools or explicit alternatives, so it misses some exclusionary guidance, but the intended context is well implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the tool's safety profile is covered. The description adds context that the tool is AI-driven, returns 'qualified' leads, and provides only 'available' contact information, which hints at possible gaps in results. It does not go deeper into data freshness, result limits, or how qualification is determined, but the annotations lower the burden.

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

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

The description is two sentences and front-loads the core purpose before describing inputs and outputs. It is appropriately sized for a simple two-parameter tool, though phrases like 'qualified local leads' are somewhat generic and could be more specific without hurting conciseness.

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

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

Given the low parameter count, full schema description coverage, existing output schema, and annotations indicating a safe read operation, the description covers the essentials. It explains what the tool does and what it returns. The main gap is the lack of rationale for when to use it over siblings, but the overall context is sufficient for a tool of this complexity.

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

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

Schema description coverage is 100%, so the schema fully documents the 'trade' and 'city' parameters. The description restates these concepts at a high level without adding syntax details, formats, or edge-case guidance beyond what the schema already 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 states the tool generates leads, identifies the target audience (contractors and local service businesses), and clearly specifies the two inputs (trade type and city) and the output (qualified local leads with contact info). It is clear and distinct from the listed sibling tools, though the output is described in somewhat generic terms rather than with a concrete verb like 'returns a list of.'

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 intended audience and input pattern are implied through 'for contractors and local service businesses' and 'accepts a trade type and city.' However, there is no explicit guidance on when to prefer this tool over alternatives, nor any exclusions or conditions. With siblings like capability_search and live_price, an agent would have to infer which tool fits a lead-gen request.

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

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

The annotations only state readOnly, idempotent, and non-destructive hints. The description goes well beyond this by detailing the provider fallback chain (CoinGecko → Coinbase → cached verified value), the disclosure of cached value age, and the 'when verified' caveat on market capitalization. This is genuinely valuable behavioral context that an agent needs before trusting the result.

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

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

Three sentences with no waste. The purpose is front-loaded, the fallback chain is compactly stated, and the return fields are listed in one sentence. Every sentence contributes essential 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 tool's moderate complexityholistically, the description covers the core purpose, provider fallback behavior, cached-data staleness, and return fields. The presence of an output schema and safety annotations fills remaining structural gaps. The description is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, with both 'coin' and 'symbol' fully described including the supported coin list and case-sensitivity. The description adds little beyond the schema — only the phrase 'supported coins' is a slight reinforcement. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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

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

The description opens with a specific verb and resource: 'Real-time cryptocurrency price lookup.' This immediately states what the tool does and distinguishes it from the unrelated sibling tools (ghost_audit, leadsignal, etc.). It also lists the returned fields, reinforcing 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?

Usage context is implied through 'Real-time cryptocurrency price lookup' — an agent can infer when to use it. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. Since no sibling tool appears to offer price lookups, the absence is not damaging, but the guidance is not explicit.

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

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

The description says 'Starts fresh session context and returns a new session_id,' implying a state-creating action. However, annotations declare readOnlyHint: true, which indicates the tool does not modify state. This is a direct contradiction: starting a session is a mutating action, not read-only. The description does not reconcile this conflict, so an agent could be misled about the tool's side effects.

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 only two sentences, with the primary action front-loaded and the usage guidance following immediately. Every sentence adds value: the first states what the tool does, and the second explains how to use subsequent calls. No unnecessary words or repetition.

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

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

Given the tool has no parameters, an output schema (not shown), and annotations covering idempotency and destructiveness, the description adequately explains its operation and the returned session_id. It could theoretically mention persistence or lifespan, but the core information needed to call it is present. The contradiction with readOnlyHint is addressed separately and doesn't affect completeness here.

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, and the schema correctly reflects that (coverage 100%). Per the rubric, a tool with no parameters receives a baseline of 4. The description adds no parameter details because none exist, but it appropriately explains the session_id output, which is not a 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's action ('Starts fresh session context') and its output ('returns a new session_id'). It is specific and distinct from sibling tools, which all have other purposes. No ambiguity exists about what this 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 provides clear guidance on how to use the tool: reuse the returned session_id for continuity, and changing or omitting it starts clean context. While it does not explicitly name alternatives, this tool's purpose is unique among siblings, and the usage context is self-evident. It does not state exclusions, so it fits the 'clear context, no exclusions' level.

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 establish readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable output behavior: it returns a risk score, safe/review/block recommendation, attack indicators, and a safe rewritten version 'when available.' This goes beyond the annotations without contradicting them.

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

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

A single, front-loaded sentence states the action, scope, and return values with no wasted words. The 'when available' qualifier is a useful precision that does not bloat the description.

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 a fully documented input schema, an output schema, and annotations covering safety, the description does not need to repeat those details. It supplies the high-level purpose and return behavior, though it stops short of explicit use-case guidance. This is nearly complete for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; it only summarizes outputs. The schema's own descriptions for prompt, mode, system, context, certificate, and email are already explicit.

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 and resource: 'Detection and analysis of prompt injection, jailbreak, and policy-bypass attempts.' It names concrete attack classes and lists expected outputs (risk score, recommendation, indicators, safe rewrite), making the tool's purpose unmistakable and distinct from the sibling audit/search tools.

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

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

The description implies the tool is for validating prompts for injection and policy-bypass, but it never explicitly states when to prefer it over alternatives or what scenarios are out of scope. No exclusions or sibling routing are provided, so an agent must infer usage from the purpose alone.

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/non-destructive, so the safety profile is covered. The description lists what the tool returns, which adds some output context, but it does not disclose behavioral nuances like the free-teaser vs full-audit distinction, whether network access to the repo is made, or any rate/time considerations. It adds only marginal behavioral value beyond annotations.

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

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

The description is a single, tightly packed sentence with no filler. It front-loads the action and resource, then lists the deliverables in a readable list. Every clause earns its place.

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

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

With an output schema present, the description doesn't need to detail return formats. It covers the core purpose, the required resource type, and the key outputs. It misses the free-teaser vs full-audit distinction, but that is documented in the schema. Overall it is sufficient for a read-only, idempotent 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 coverage is 100%, and the schema already documents each parameter with examples and the email tradeoff. The description adds no extra parameter semantics—it just restates 'public GitHub repository' which the schema already provides. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description states a specific action ('AI code audit') on a specific resource ('public GitHub repository') and lists concrete outputs (Provibe score, vulnerabilities, dead-code map, execution plan). It does not explicitly differentiate from sibling ghost_audit tools, but the tool name and unique output set make the purpose clear.

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

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

The description implies usage context: auditing a public GitHub repository. It does not mention alternatives or exclusions, such as when to use ghost_audit_* or when the repo is private. The optional email/full audit behavior is only in the schema, not the description, so guidance on when to provide it is missing.

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

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

Annotations already provide destructiveHint=true, and the description adds that it returns execution state and downstream tool results, implying it can execute downstream tools. It doesn't elaborate on potential side effects or permissions, but the annotation covers the destructive nature; still, some added context on downstream execution would be valuable.

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

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

The description is three sentences with no fluff. It front-loads the core purpose in the first sentence, lists domains in the second, and summarizes outputs in the third. 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 with 9 parameters, an output schema, and rich annotations, the description covers purpose, scope, and returns. The main gap is the lack of guidance on when to use this router versus specific siblings, but the output schema and annotations fill most of the remaining 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 is 100%, and the description adds no parameter-specific information. The description mentions 'natural-language requests' which maps to the 'need' parameter, but this is already clear from the schema; the baseline of 3 applies.

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

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

The description clearly states it is a universal entry point for routing natural-language requests across supported Zambo tools, using specific verbs and resources. It enumerates the domains it covers, which distinguishes it from the specific sibling tools like ghost_audit_report or live_price.

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

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

The description implies usage: it's the universal entry point, so you'd use it when you have a natural-language request and aren't sure which specific tool to call. However, it doesn't explicitly state when to avoid it or when to prefer a sibling tool like leadsignal directly, leaving this to inference.

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