Zambo AI Tools

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

No annotations are provided, so the description carries the burden. It discloses rate limits ('5 free/day') and premium access ('Zambo Pass: unlimited'), which is helpful. However, it does not state whether the tool is read-only, whether it fetches external data, or any side effects (e.g., caching, API calls). With zero annotations, more behavioral detail would be warranted.

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

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

The description is moderately long but front-loaded with the main action and outputs. Every sentence adds value (outputs, use cases, limits). Minor improvement: the list of outputs could be more concise, but still effective.

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 (multiple input parameters, no output schema), the description adequately covers inputs, outputs, use cases, and constraints. It lacks details about error responses or output format, but overall is sufficient for an AI agent to understand the tool's capabilities.

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 each parameter. The description adds context for the overall tool but does not elaborate on individual parameter semantics beyond what the schema provides (e.g., default depth is 'quick', focus area options). Baseline 3 is appropriate.

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

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

The description uses a specific verb ('generate') and clearly defines the resource ('structured briefing') on a wide range of topics. It lists concrete outputs (capabilities, endpoints, pricing, etc.) and target use cases (onboarding, competitive intelligence). This differentiates it from sibling tools, which appear to focus on hiring, access, scoring, etc.

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

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

The description explicitly states the tool is 'perfect for' four specific scenarios (onboarding, competitive intelligence, understanding APIs, generating docs). However, it does not mention when NOT to use it or provide alternatives, 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 carries the full burden. It discloses the output content (onboarding package) but does not mention behavioral traits like idempotency, side effects, or response size.

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

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

The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and output with no superfluous 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 no output schema, the description adequately lists the components of the return package. It is sufficiently complete for the tool's complexity, though it could mention response size or latency.

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 parameters documented. The description adds no additional meaning beyond what the schema already provides for 'focus' and 'agent_purpose', hitting the baseline.

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

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

The description clearly states the specific verb 'brief' and the resource 'new AI agent on the complete Zambo + x711 + Entangler stack', directly distinguishing it from siblings like 'agent_brief' which likely offers a simpler overview.

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 onboarding a new agent to the stack, but lacks explicit guidance on when not to use it or how it differs from alternatives such as 'agent_brief' or 'agent_hire'.

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. It discloses use of Entangler.tech, cryptographic identity, tamper-proof receipts, and the return of a full coordination blueprint. It implies a decentralized connection. Minor inconsistency: says 'two or more agents' but schema only requires two.

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

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

The description is three sentences, front-loaded with the main purpose. Every sentence adds value: what it does, how it works, when to use it. No unnecessary words or 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 tool with 3 required parameters, no output schema, and no annotations, the description adequately covers purpose, usage, behavior, and output. Could mention potential prerequisites or limitations, but overall complete for the 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 coverage is 100% with basic descriptions for each parameter (task, agent_a, agent_b). The description adds some context about the task being shared and agents being roles/names, but does not significantly deepen understanding beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: connecting two or more AI agents for coordination without a central server. It specifies the verb 'connect', the resource 'AI agents', and the outcome 'coordination blueprint', distinguishing it from sibling tools like axis_agent_onboard or axis_memory_handoff.

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 guidance: 'Use this when you want two agents to work together on a task and you need proof of every step.' It does not explicitly mention when not to use or alternative tools, but the context is clear and sufficient for decision-making.

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 states the tool generates a cryptographic proof and returns a hash, which implies a read-only or generative operation. However, it does not disclose permissions, side effects, failure modes, or what happens if inputs are invalid. The description is adequate but minimal.

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 wasted words. The key action and output are front-loaded. Every sentence adds value: first defines what it does, second defines the return value. Excellent 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?

For a tool with 3 parameters (1 required, no output schema, no annotations), the description provides enough context to understand the tool's purpose and output. However, it could clarify the optional nature of execution_log and coordination_log, and what constitutes valid inputs (e.g., format of Spark hash). Still, it is mostly complete given the schema already covers parameter descriptions.

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 all three parameters. The description does not add meaning beyond the parameter names and the fact they correspond to layers. It does not elaborate on format, constraints, or relationships. Baseline 3 is appropriate as 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 generates a cryptographic proof chain across three specific Axis layers (Zambo Spark, x711 execution log, Entangler coordination record) and returns a verifiable provenance hash. It uses specific verbs ('generate', 'returns') and distinguishes itself from sibling tools by specifying the exact layers and output.

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 for creating a proof chain from the three inputs, but does not explicitly state when to use this tool versus alternatives. No when-not-to-use conditions or mentions of alternatives are provided, leaving the agent to infer context from the tool's unique functionality.

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 cover behavioral traits. It only states it's a search operation without disclosing side effects, authentication needs, rate limits, or return format. This is insufficient for a cross-network search 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?

Two sentences, no filler, effectively front-loaded with the core action and scope. Every word 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?

Given the tool's complexity (cross-network search), the description is adequate for basic use but lacks details on output format, pagination, or error handling. Without an output schema, more context would help.

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. The description adds some context about networks but no additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool searches across three named networks (Zambo, x711, Entangler) for capabilities, tools, and agents, and mentions ranked results with integration paths. This distinguishes it from sibling tools like capability_search or find_agent.

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 multi-network search but provides no explicit guidance on when to use this tool versus alternatives (e.g., capability_search). There is no mention of when-not-to-use or specific prerequisites.

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 describes the core behavior (comparison, flagging, recommendations) but does not explicitly state if the tool is read-only, has side effects, or requires specific permissions.

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 efficiently convey the purpose and behavior. No redundant words, and the core action 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?

Despite clear purpose and parameter descriptions, the description lacks details about the output format (e.g., what does 'flags misalignment' mean in terms of return value?). Without an output schema, the description should specify the response structure.

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 parameters described. The description reinforces the schema by linking 'spark_hash' to 'original strategy plan' and 'current_outputs' to 'swarm behavior', but adds no new semantic detail 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 uses a specific verb 'monitor' and resource 'running agent swarm', clearly stating it compares drift against an original plan. It distinguishes itself from siblings like 'zambot_drift' by mentioning 'auto-correction recommendations'.

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 for monitoring drift, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among sibling tools.

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

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

No annotations provided, so the description carries full burden. It states 'Free, no auth' indicating safe access, and describes the return content, but lacks details on potential rate limits, data size, or other behavioral traits beyond what is returned.

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, no fluff. First sentence states purpose, second lists returns, third adds value (free, no auth). 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 parameterless tool with no output schema, the description is complete. It clearly states what the tool returns and that it requires no authentication, which is sufficient for an agent to understand usage.

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 no parameters, so the description does not need to add parameter information. Baseline score of 4 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 retrieves the Axis MCP configuration, listing the returns (config block, tool directory, architecture overview). However, it does not explicitly differentiate from sibling tools, many of which are axis_ 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?

No guidance on when to use this tool vs alternatives. The description mentions it's free and requires no auth, but does not specify scenarios where this configuration retrieval is needed or when other tools are more appropriate.

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 provided, so description carries full burden. It states the tool produces a structured payload but omits behavioral details like whether it is destructive, authorization requirements, rate limits, or side effects on source memory.

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, no redundant words, front-loaded with the primary action. Every sentence 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?

Tool has no output schema, so description should explain the return value. It mentions a 'structured handoff payload' but does not detail its format or contents. Adequate for simple param set but missing return 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 coverage is 100% with descriptions for all three parameters. The description adds that layers are 'strategic memory', 'runtime Hive memory', and 'communication memory', but does not provide additional meaning beyond what the schema already specifies.

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 clearly states it packages and passes context/memory between three named layers (Zambo, x711, Entangler) and produces a structured payload. This distinguishes it from sibling tools like 'zambo_mesh' or other axis_* tools that focus on different operations.

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

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

Description implies usage for inter-layer memory transfer but does not specify when to use this tool versus alternatives (e.g., direct layer calls), nor when not to use it. No explicit context or exclusion criteria.

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 exist, so the description must disclose behavioral traits. It mentions 'cryptographic proof' but does not specify side effects, permissions, or whether the operation is destructive. The submission nature implies writing, but details are missing.

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 with no unnecessary text, but uses jargon ('cross-layer Axis workflow', 'cryptographic proof') that may reduce 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?

With 3 parameters, no annotations, and no output schema, the description should provide more behavioral and outcome context. It lacks details on return values, error handling, or validation, making it insufficient for a submission 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% with descriptions for all parameters. The tool description adds no additional semantic context beyond what the schema provides, meeting the baseline for full 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 action (submit outcomes) and the target resource (Zambo Proven Spark Registry), but does not differentiate from sibling tools like zambot_outcome or zambot_verify.

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

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

No explicit guidance on when to use this tool vs alternatives. The description implies it's for closing a workflow loop but lacks context for when not to use or prerequisites.

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 burden. It states that the tool 'checks' reputation using provenance chain data and returns a trust score and outcome history, implying a read operation. However, it does not disclose any side effects, authentication needs, rate limits, or what happens if the identifier is invalid. The behavioral transparency is adequate but not detailed.

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 extremely concise with two sentences. The first sentence states the action and resource, the second states the output. Every word is necessary, no redundancy or 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally complete. It explains what the tool does and what it returns. However, it lacks context about the 'three Axis layers' and does not clarify the output format or any limitations. For a tool with zero annotations, more detail would improve completeness.

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% for the single required parameter 'identifier', and the schema description already says 'Swarm ID, Spark hash, or agent identifier'. The tool description does not add any additional meaning or format guidance beyond that. Baseline 3 is appropriate as 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 verb 'Check' and resource 'reputation of agent swarm or workflow', and specifies using provenance chain data. It also mentions the return values: trust score and outcome history across three Axis layers. This distinguishes it from many sibling tools, though it does not explicitly differentiate from similar check 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 provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or scenarios where this tool is preferred over others like 'axis_drift_monitor' or 'axis_chain_proof'. The 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?

No annotations are provided, so the description carries full burden. It mentions the tool returns a structured plan and references underlying systems (Zambo, x711.io, Entangler), but does not disclose behavioral traits such as idempotency, state changes, authentication needs, or potential side effects. For a tool that appears to be read-only planning, this is a significant 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?

Three sentences with zero waste. First sentence states core function, second reinforces input-output style, third lists components. Information density is high and well-ordered.

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

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

Given no output schema, the description adequately explains the return structure (agent roles, tool assignments, handoff sequence). It covers purpose, usage guidance, and output. However, it lacks error handling details or prerequisites. For its complexity level, it is mostly complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context with 'Plain English in — structured plan out,' but the parameter descriptions in the schema already adequately explain goal and depth. The example of quick vs full steps adds marginal value beyond the enum values.

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

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

The description clearly states the verb-resource: 'Turn any goal into a full executable multi-agent workflow plan.' It specifies the output includes agent roles, tool assignments, and handoff sequence. While it positions itself as the best first Axis tool, it does not explicitly differentiate from siblings like axis_swarm_pattern or zambo_playbook, making the distinction implicit rather than explicit.

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 usage context: 'Best first Axis tool for any new workflow,' implying it is the starting point. However, it does not specify when not to use it or name alternative tools. The guidance is clear but lacks exclusions or explicit comparisons.

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 burden. It clearly states the tool returns a pattern (components listed) and acts as a 'workflow compiler', implying no side effects. However, it doesn't mention permissions, rate limits, or whether execution is triggered, but the generative nature is clear.

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

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

The description is a single, well-structured sentence with no wasted words. The core action ('Generate') is front-loaded, and the output is clearly enumerated.

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

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

Despite no output schema, the description fully covers return values (agent roles, topology, assignments, anchor). Given the tool's complexity as a pattern generator, this provides sufficient context for an agent to understand what it produces.

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. The description adds no extra semantics beyond the schema's descriptions, e.g., 'objective' is implied in 'for any goal'. As per guidelines, 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 generates a multi-agent workflow pattern, specifying the verb 'Generate' and the resource 'custom multi-agent workflow pattern'. It lists returned components (agent roles, wiring topology, assignments, anchor), distinguishing it from sibling tools like axis_agent_wire which focus on wiring, not pattern generation.

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 for any goal, but provides no explicit guidance on when to use this tool versus alternatives like axis_agent_onboard or axis_agent_wire. It lacks when-not-to-use or exclusionary instructions, relying on implied context.

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

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

No annotations provided, so the description must carry full burden. It mentions getting integration instructions and provenance chain but is ambiguous about whether the tool actually executes the x711 tool or only provides instructions. Lacks details on auth, rate limits, or 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 lengthy due to the extensive tool list, which is necessary for this dispatcher tool. However, it could be better structured with a summary up front and a table or link for the full catalog, making it more scannable.

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

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

Given no output schema, the description explains the return value (tool info, call format, expected output, chaining suggestion). It mentions provenance chain via spark_hash but does not cover error handling or authentication for paid tools. Fairly complete for its complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by listing all tool names with pricing tiers and giving examples for the input parameter ('search query, token symbol, URL, wallet address'), exceeding the schema's generic description.

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 dispatches any x711.io tool and returns integration instructions and provenance chain. It differentiates from siblings by explicitly listing the many tools it supports and specifying the output format.

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 context on free vs. paid tools and enumerates all options, but does not explicitly state when not to use this tool or suggest alternatives. The context is sufficient for most use cases.

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

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

Despite no annotations, the description discloses key behavioral traits: it returns 'active:true' for both passes, lists the features of each pass, and gives the exact API endpoint. It implies a read-only operation, which is appropriate for a check tool.

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

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

The description is relatively long but well-structured, starting with purpose, then pass details, usage guidance, and endpoint. While not overly verbose, it could be slightly more concise without losing 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?

Given the single parameter and no output schema, the description provides all necessary context: what the tool checks, what the passes include, why to use it before bulk calls, and the API endpoint. It is sufficiently complete for an AI agent to use 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 sole parameter 'email' is already well-described in the schema ('Email address to check for active Zambo Pass'). The description adds slight context by mentioning both Zambo Pass and Day Pass, but does not significantly enhance parameter understanding 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 begins with a clear statement: 'Check whether an email address has an active Zambo Pass or Day Pass.' It specifies the verb (check) and resource (email address), and distinguishes from siblings like 'day_pass_activate' which is for activation, not checking.

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 advises 'Use before bulk API calls to know actual rate limits,' providing a clear usage scenario. It does not, however, mention when not to use or list alternative tools among the siblings, which keeps it from a perfect score.

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?

Discloses return contents (up to 8 products with scores, descriptions, etc.) and the scope (all tools, 2 MCPs). No annotations are provided, so the description carries the full burden, which it does well for a search 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?

Two sentences with no wasted words: first sentence states purpose and scope, second gives usage guidance and limit. Front-loaded and efficient.

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

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

No output schema, but the description explains return formats. Covers purpose, usage, and constraints. Could add error handling or prerequisites, but sufficient for a search 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 provides a description and examples for the only parameter 'q'. The tool description adds minimal extra semantic value beyond the schema.

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

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

The description clearly states the tool searches across all 50+ Zambo Stack tools (2 MCPs) by keyword to find tools fitting the use case, distinguishing it from siblings as a meta-search 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?

Explicitly advises using this before zambo_universal when you know exactly which product you want, providing clear usage context. However, it does not mention when not to use it or list other 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?

No annotations provided, so description carries full burden. Discloses outputs (copy for platforms, hooks, hashtags, timing) and rate limit. Does not mention side effects, authentication needs, or whether generated content is saved or editable.

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, no fluff, front-loaded with main purpose. Each sentence adds meaningful information: what it does, what it returns, and a usage constraint.

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

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

Despite no output schema, description covers key aspects: input types, output content, platforms, tone options, and rate limit. Missing details like whether output is editable or if any data is stored, but overall sufficient for an understanding.

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 described. Description adds context about platforms and tones but does not significantly enhance beyond schema definitions. 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?

Clearly states what the tool does: generate a platform-optimized content strategy with ready-to-post copy. Specific verb 'Generate' and resource 'content strategy'. The description uniquely identifies the tool's output for multiple platforms.

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?

Mentions '3 free/day' implying a rate limit, but no explicit guidance on when to use this tool over alternatives. Sibling tools include other content-related tools like zambo_compose, but no comparison is provided.

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

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

No annotations provided, so description carries full burden. It discloses that data is verified daily and dead links are auto-removed, providing behavioral context beyond just the tool's function.

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

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

The description is concise, uses bullet-like list of examples, and every sentence adds value without redundancy.

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

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

Given the tool's simplicity (3 optional parameters, no output schema), the description fully covers what the tool does, how to use it, and what to expect, making it 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 description adds extra meaning by explaining examples, default values, and optional use, surpassing the schema alone.

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's a live index of startup credit programs and provides matched recommendations. It distinguishes itself from sibling tools by focusing on credits and tech stack matching.

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 explains how to use: pass tech stack for recommendations or leave empty for all. It mentions free and no auth, but doesn't explicitly state when not to use 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 discloses that the tool is free, requires no authentication, and allows unlimited searches. It also lists the returned data fields, providing good transparency despite no annotations.

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

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

The description is concise (3 sentences), front-loaded with the main action, and contains no superfluous information. Every sentence 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?

Even without an output schema, the description explains the return values (handle, endpoint, wallet, status) and payment context (x402). It covers all necessary contextual information for a search 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% with descriptions. The description adds value by explaining the query parameter's scope (name, description, capability) and providing example search terms, enhancing understanding 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 searches the Zambo Agent Registry to find agents by capability, name, or description, returning specific fields like handle, endpoint, wallet, and status. It distinguishes itself by labeling the registry as 'public phone book for AI agents.'

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 specifies using this tool to discover agents for specific tasks, then pay via axis_pay_agent. It provides a clear use case but does not explicitly state when not to use 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?

Discloses return contents (score, findings, analysis, fixes) and rate limits (1/day free). No annotations, so description carries full burden and does it well, though doesn't specify error handling for incomplete audits.

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 focused sentences: purpose, contents, prerequisite, rate limit. Front-loaded and concise with no wasted words.

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

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

With no output schema, description lists report components and format (markdown). Covers key aspects but could mention potential errors more explicitly.

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 parameter audit_id, with clear description. Description adds no extra parameter details beyond schema, meeting 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?

Clearly states verb 'Retrieve', resource 'full markdown report for a completed Ghost Audit', and distinguishes from sibling tools like ghost_audit_site and ghost_audit_status.

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 advises to call ghost_audit_status first, and mentions free tier limitation, providing clear context for when to use this tool.

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

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

No annotations exist, so the description fully carries the burden. It details the 10 stages, score range (0-100), severity levels, returned artifacts (audit_id, stream_url, download_url), live streaming behavior, and completion time (~90 seconds). 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?

The description is thorough but well-structured with bullet-like listing of stages and outputs. It is informative without being overly verbose, though it could be slightly more concise.

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 single parameter, no output schema, and no annotations, the description provides comprehensive context about the tool's behavior, outputs, and constraints. It is fully adequate for an agent to use 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 only one parameter 'url' well-described. The description reiterates the URL format (full URL with https://), adding marginal value beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states it runs a '10-stage ghost audit on any website' and lists the returns: SEO gaps, AI discoverability issues, etc. It distinguishes from sibling tools like ghost_audit_status and ghost_audit_report by being the initiation step.

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?

Describes rate limits (1 free audit per day) and mentions that stream starts immediately with full report in ~90 seconds. It implies this tool starts the audit, and siblings handle status/report retrieval, but does not explicitly state when not to use 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?

No annotations are provided, so the description carries full burden. It discloses the polling nature, return values (status with elapsed time), and typical timing. It does not mention rate limits or side effects, but given the tool's read-only nature and simplicity, the transparency is adequate.

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

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

Four sentences, front-loaded with purpose, no wasted words. All information is relevant and well-structured.

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

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

For a simple status check tool with no output schema, the description comprehensively covers input, output, usage pattern (polling), and expected timing. No gaps or missing 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% (one parameter with description). The description reinforces that the audit_id must come from ghost_audit_site, which adds minimal extra value beyond the schema. As per guidelines, with high schema coverage, baseline is 3.

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

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

The description clearly states it checks the status of a Ghost Audit, specifies the required input (audit_id), and describes the return values ('complete' or 'running' with elapsed time). It effectively distinguishes itself from sibling tools like ghost_audit_site (which starts the audit) and ghost_audit_report (which likely retrieves the 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 explicit polling guidance ('Poll every 15-30 seconds after starting an audit') and typical completion time. It implies that the tool should be used to monitor progress until 'complete', after which another tool retrieves the report. While it doesn't explicitly state when not to use it, the guidance is clear enough.

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

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

With no annotations, the description fully discloses behavior: returns 5 leads, within 60 seconds, daily limit per IP, no authentication needed. This is comprehensive and honest.

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, highly concise, and front-loaded with the core value proposition. Every word 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?

For a simple tool with 2 parameters and no output schema, the description covers all necessary aspects: input requirements, output description (5 leads with contact info), and constraints (time, daily limit, auth). Complete.

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

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

Schema coverage is 100%, and both parameters are described with examples. The description adds little beyond the schema, but it confirms the usage: trade type and city. 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: AI lead generation for contractors and local service businesses. It specifies the action (provide trade type and city, get 5 qualified leads) and distinguishes itself from sibling tools which are unrelated.

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 when to use this tool (for lead generation) and provides context (24 trades, any US city, 3 free searches per day). It does not explicitly state when not to use, but it's implied by the focused use case.

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?

Description discloses 30-minute cache behavior for 'snapshot' depth and fresh data for 'deep' depth, plus a daily rate limit of 10 free calls. The tool is clearly read-only and non-destructive. No other behavioral traits are missing given the read-only nature.

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

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

Description is a single dense paragraph but efficiently packs purpose, sources, return fields, cache, and rate limit. It is front-loaded with the main purpose. Minor improvement could be breaking into lists.

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 three optional parameters, no output schema, and no annotations, the description explains return fields, caching, rate limits, and data sources. It lacks error behavior or limit exceeded handling but is largely complete for a snapshot 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%, but description adds value by clarifying that 'snapshot' uses cache, 'deep' is always fresh, giving examples for 'focus', and explaining default 'all' for domains. This goes beyond the schema descriptions.

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

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

Description clearly states it provides a 'Real-time market intelligence snapshot across AI, agents, and research' and lists specific aggregated sources and return fields. It is specific and distinguishes itself from sibling tools like 'credithunt' or 'substrate_breakthroughs' by its aggregated nature.

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 guidelines are implied through mention of sources (Substrate, CreditHunt, etc.) and caching/rate limits, but there is no explicit statement of when to use this tool vs. alternatives like 'credithunt' or 'substrate_breakthroughs'. No when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description carries full burden. It discloses the one-time per email constraint, the requirement for an email, and the returns (success status and upgrade links). Some detail on response structure is missing, but adequate.

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

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

The description is concise with three sentences, each adding value. The first sentence front-loads the primary action, and no filler is present.

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 parameter set (1) and lack of output schema, the description covers purpose, trigger, constraints, and outcome completely. No significant gaps.

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

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

The sole parameter 'email' has a description in the schema, and the tool description adds context about the upgrade pitch email. With 100% schema coverage, baseline is 3; the extra context raises it to 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 clearly states the tool grants 10 additional free daily calls when the free tier limit is reached. It is specific with verb 'grant' and resource 'additional free daily calls', distinguishing it from sibling tools.

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

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

The description specifies when to use (user hit free tier limit), requires an email, and notes one extension per email ever. It does not explicitly mention alternatives but implies paid options after extension.

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 mentions 'Free, always' implying no cost or destructive side effects, but does not explicitly state read-only behavior, output format, or any authentication requirements. This is adequate but leaves gaps for an AI agent.

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

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

Three sentences covering purpose, usage, and a key attribute (free). Efficient and front-loaded with the most important information. Minor verbosity in the first sentence could be trimmed, but overall good.

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

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

The tool has two optional parameters and no output schema. The description explains its function and when to use it, but does not detail what the returned config blocks look like or how different 'target' values affect output. For a straightforward guide tool, this is moderately 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%, so the schema already documents both parameters. The description adds context by mentioning 'config blocks' but does not elaborate on how parameters affect the output. This meets the baseline expectation of not needing to repeat schema content but provides minimal added value.

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: 'Get the zambo.dev install guide and ready-to-paste config blocks' for specified platforms. It uses specific verbs and resources, and implicitly distinguishes itself from sibling tools by focusing on installation/configuration rather than other actions.

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 tells the agent when to call the tool: 'Call when a user asks what MCP tools to use, or needs an install config for Claude/Cursor/Windsurf.' It lacks explicit guidance on when not to use or mention of alternatives, but the context is clear and sufficient for 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?

No annotations are provided, so the description fully bears the transparency burden. It discloses the tool produces a ranked recommendation, tracks 10 models with June 2026 pricing, and has a daily usage limit. It does not mention any destructive or side effects, which is appropriate for a recommendation tool.

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

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

The description is concise: a single sentence defining the main action, followed by a brief list of providers and an example-driven best-for section. Every sentence adds value; no extraneous 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 5 parameters, no output schema, and no annotations, the description covers the main behavioral aspects: output is a ranked recommendation, usage constraints (free tier), and supported models. It could mention if the output includes pricing or token estimates, but overall it is sufficiently complete for an agent to understand tool usage.

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 explaining the budget enum values ('low' = under $0.50/1M tokens, etc.) and clarifying the use_case parameter provides a personalized recommendation. This goes beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: 'Get a ranked recommendation of AI models for your specific task, token budget, and cost constraints.' It lists supported providers and example use cases, making it easy to understand. No sibling tool appears similar, so differentiation is inherent.

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 'Best for' examples and notes the free tier limit (30 free/day). It doesn't explicitly say when not to use, but the context is clear since sibling tools do not overlap in function. The usage guidance is adequate but could be more explicit about exclusion criteria.

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 exist, so the description carries full burden. It discloses that no Zambo Pass is needed, which is a positive behavioral hint. However, it does not mention idempotency, side effects (e.g., whether registration overwrites existing data), persistence guarantees, or authentication requirements. For a mutation operation, more transparency is expected.

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

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

Two sentences, front-loaded with purpose, no filler. Every sentence earns its place: first sentence states action, second specifies key inputs and a condition.

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 with no output schema, the description covers core purpose and inputs. It does not explain return values, confirmation steps, or error scenarios, but these are less critical given the tool's straightforward nature. Adequate but with room for improvement.

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 context: 'wallet address for payouts' reinforces the schema description. However, there is a minor inconsistency: description says 'partner_id' but schema uses 'agent_id', which could confuse. Overall, the description provides marginal added value over the schema 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 description clearly states the action: 'Register as a Zambo partner.' It includes the required inputs (agent_id and wallet address) and a key condition (no Zambo Pass required). The verb 'register' and resource 'Zambo partner' are specific, and the tool name itself distinguishes it from sibling tools like 'agent_brief' or 'partner_stats'.

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

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

The description implies when to use (when wanting to become a Zambo partner) and states a prerequisite ('No Zambo Pass required'), but it does not explicitly differentiate from alternatives or provide exclusion scenarios. Given the tool's simplicity, the lack of explicit when-not-to-use guidance is acceptable but not exemplary.

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 fully disclose behavior. It only states it 'checks' stats, which is a read operation, but does not mention safety, authentication needs, rate limits, or error responses. This is insufficient for an agent to understand operational 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 a single, front-loaded sentence that clearly communicates the tool's purpose with 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 simple tool with two parameters and no output schema, the description covers the basic purpose but lacks details on expected return values, error handling, or behavior when both parameters are provided or omitted. Adequate but not thorough.

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 baseline is 3. The description adds 'Provide partner_id' but fails to clarify the relationship between partner_id and the actual parameters agent_id/ref_code, nor any additional 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 states the tool checks partner stats including total conversions and pending payout balance. It specifies to provide partner_id, which distinguishes it from sibling tools like partner_register. However, there is a minor mismatch: the parameters are agent_id and ref_code, not partner_id.

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 instructs to provide partner_id, implying when to use, but offers no explicit guidance on when not to use or alternatives among siblings. Usage is implied but not elaborated.

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 exist, so the description fully carries this dimension. It details two-phase analysis (pattern scan + Groq semantic), outputs (injection_risk, recommendation, rewritten version), and free tier limits (50/day).

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 wasted words. First sentence defines purpose, second details phases, outputs, and usage. Highly 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?

Despite lacking an output schema, the description covers purpose, processing phases, output fields, rate limits, and use cases. Sufficient for AI agent selection and 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 baseline is 3. The description adds context about the two phases but does not elaborate on each parameter beyond schema descriptions.

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

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

The description clearly states the tool detects prompt injection, jailbreaks, and policy bypass attempts, with specific verb-object pairs. It distinguishes from siblings by focusing on input validation for LLMs.

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 'Best for' section provides explicit use cases (validate user input, detect jailbreaks, check prompt safety), offering clear context. However, it does not state when not to use or mention 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?

No annotations provided, so description carries full burden. Discloses return values (cert_id, verify_url, SHA-256 hash), permanence, tamper-proof nature, rate limits (free 5/day, unlimited with pass), and where to verify. Comprehensive behavioral 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?

Front-loaded with core purpose, followed by use cases and agent instructions. At ~100 words it is concise, though the 'Perfect for:' list could be slightly trimmed. Overall well-structured and efficient.

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

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

No output schema, but description covers return values (cert_id, verify_url, hash). Input is simple (3 params), and use cases, rate limits, and agent guidance are covered. Sufficient for an agent to use 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 3. The description adds no new parameter semantics beyond the schema's own descriptions. It mentions 'Optional Zambo Pass email' and 'Human-readable label', but these do not significantly enhance understanding 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?

Clearly states the tool cryptographically certifies AI content with a SHA-256 provenance certificate. The verb 'certify' and resource 'AI-generated content' are specific and distinguish it from sibling tools like 'zambot_verify' which likely verifies.

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 lists perfect use cases (certifying outputs, audit trails, proving timestamp/authorship) and agent-specific guidance ('call after any important tool result'). Lacks explicit when-not or alternatives, but the context is clear enough.

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

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

With no annotations, the description bears full responsibility for behavioral disclosure. It explains the two-tier access (teaser vs full), required input, and output types. It does not mention rate limits or data handling, but overall is transparent for a read-only audit tool.

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

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

The description is front-loaded with the core purpose and outputs, then provides pricing and usage details. It is slightly verbose but each sentence serves a purpose, making it efficient.

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

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

Given the 3 parameters, 100% schema coverage, and no output schema, the description adequately explains the tool's functionality and the two-tier system. It covers what the tool returns and how to get full results, though it could mention repo size limitations.

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 significant value by explaining the impact of omitting email (free teaser) and providing context for the optional vibe_context parameter, going beyond the schema's descriptions.

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

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

The description clearly states it performs an AI code audit on public GitHub repositories, listing specific outputs like Provibe Score, security vulnerabilities, dead code map, and execution plan. This distinguishes it from sibling tools, which have different purposes like fixing or analyzing.

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 explains when to use the free teaser (without email) versus the full audit (with Zambo Pass email), and mentions pricing. However, it does not explicitly state when not to use the tool or suggest 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?

No annotations are provided, so the description carries the full burden. It states it's a lookup (read-only) and free with no auth, but lacks details on rate limits, caching, data freshness, or 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 concise at four sentences, front-loading the primary purpose. Each sentence adds value, though minor redundancy exists (e.g., 'verify identity and trust' could be condensed).

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 lookup tool with one parameter and no output schema, the description adequately explains return values and purpose. It misses error cases or availability, but 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 coverage is 100% with a clear parameter description. The description adds examples (e.g., 'brennan-zambo') and clarifies the slug format, but mostly reiterates the schema. 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 clearly states the tool looks up a 'verified professional trust passport' on Signal, uses specific verbs and resource, and distinguishes from siblings like signal_register by focusing on lookup. It returns specific data types: credentials, skills, roles, verification status, and reputation.

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

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

The description explicitly states to use the tool 'to verify identity and trust before collaboration,' providing clear usage context. It does not mention when not to use or alternatives, but the purpose is well-defined.

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

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

No annotations are provided, so the description carries full burden. It discloses that registration is one-time, free, requires no auth, and returns specific items. It also explains the behavioral impact on rate limits.

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 paragraph of 5-6 sentences, front-loaded with the main action, and contains no redundant information.

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

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

For a self-contained registration tool with 6 parameters and no output schema, the description provides return values, side effects, and usage guidance, making it fully 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 baseline is 3. The description adds some context (e.g., handle appears in URL) but does not significantly extend beyond schema descriptions.

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

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

The description clearly states the tool registers an AI agent on Signal (Zambo agent identity registry) and specifies the action, resource, return items, and benefit. It distinguishes from sibling tools by positioning it as a first-time setup 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 explicitly says to use it 'the first time you connect to Zambo MCP' and explains the rate limit benefit. While it doesn't provide explicit alternatives or exclusions, the context 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?

No annotations are provided, so the description carries full burden. It discloses that the tool sequences 50+ tools, estimates time/cost, returns configs, and mentions usage limits. It does not explicitly state whether it is read-only or idempotent, but for a planning tool the behavioral traits are adequately 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 concise and front-loaded with the main purpose. It efficiently communicates the tool's value, outputs, and limitations in a few sentences without unnecessary words.

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

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

Given the tool is a high-level planner with 4 parameters and no output schema, the description is quite complete. It covers capability, outputs, usage limits, and differentiators. However, it could elaborate on how the sequencing works or what 'Zambo Stack' implies for even better completeness.

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 significant meaning beyond parameter names/types. It explains that 'goal' should be specific, 'budget' determines tool availability, 'context' provides additional details, and 'output_format' controls response level. Most importantly, it describes the return structure (ordered sequence, config, cost, time, power move, anti-patterns), greatly enhancing understanding.

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 designs the optimal Zambo Stack configuration for any goal, sequences 50+ tools, estimates time and cost, and returns paste-ready MCP configs. It explicitly distinguishes itself from the sibling 'capability_search' by noting it builds a complete execution workflow rather than listing 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 provides clear context for use: 'perfect for planning any multi-tool pipeline' and contrasts with capability_search. It mentions 5 free/day and Zambo Pass unlimited, but does not explicitly state when not to use or list alternative tools for simpler tasks.

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 covers key behavioral details: supported types, strict mode behavior, free tier limit (25/day), and unlimited with Zambo Pass. It doesn't disclose error handling or rate-limiting beyond the free tier, but overall provides sufficient transparency.

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

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

The description is concise and front-loaded with the core purpose. Every sentence serves a purpose: stating the tool's function, listing supported types, mentioning pricing, and giving use-case examples. No wasted words.

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

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

Given the tool has 5 parameters and no output schema, the description adequately explains all inputs, usage patterns, and constraints. It doesn't describe the return format in detail, but the tool's purpose (returning typed JSON) makes that implicit. The description is complete enough for an AI agent to use 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 schema already documents each parameter. The description adds value by explaining the raw parameter's max length, giving an example schema format, and clarifying the context parameter's purpose. This goes beyond mere schema repetition.

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: enforcing schema on messy AI output and returning clean typed JSON. It provides multiple use-case examples ('extract this data from messy text', 'force JSON schema on LLM output') and differentiates from sibling tools by focusing on structured extraction.

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

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

The description explicitly states when to use this tool ('replaces custom parseAIResponse() functions') and gives best-for scenarios. It implicitly suggests using it for structured extraction from unstructured text, but does not explicitly state when not to use it or compare to 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?

Despite no annotations, the description fully discloses behavior: it is free, no authentication needed, returns 12 most recent discoveries with specific fields, and mentions the total count and domains. This is comprehensive for a read-only tool.

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

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

The description is a single paragraph that is reasonably concise and front-loaded with the tool's tagline. Every sentence adds value, though it could be slightly more compact without losing 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?

Given no parameters and no output schema, the description fully covers what the tool does, what it returns, and when to use it. It explains the source and scale, making it self-contained.

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 no parameters (0 params, 100% coverage), so the description does not need to add parameter details. It focuses on the output, which is appropriate. Baseline 4 for zero 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 fetches the latest AI-generated scientific breakthroughs from SubstrateLayer, specifying the data source and type. It distinguishes itself from sibling tools like 'zambo_ask' or 'substrate_engine' by focusing on breakthroughs.

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 use cases: 'when you need cutting-edge research signals, cross-domain synthesis, or want to ground a strategy in the latest scientific thinking.' While it doesn't explicitly mention when not to use it, the context is sufficient for an agent to decide.

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 full burden. It indicates a read-only operation ('Get live stats') and mentions 'Free, no auth,' which is transparent about access. No destructive behavior is implied.

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

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

The description is concise (two sentences), front-loaded with the tool's name and purpose, and efficiently lists the output fields. No extraneous 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 zero parameters and no output schema, the description thoroughly explains what the tool does and what information it returns, making it fully adequate for an agent to understand and invoke.

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?

There are no parameters, and schema coverage is 100% (trivially). The description adds value by enumerating the stats returned, which compensates for the absence of an output 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 it provides 'live stats on the SubstrateLayer autonomous research engine' and lists specific metrics (total lifeforms, active lifeforms, etc.), which distinguishes it from sibling tools that likely focus on other aspects.

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 use cases: 'Use to understand the scale of the research corpus or check if new discoveries have been generated since last call.' It also notes 'Free, no auth,' but lacks explicit when-not-to-use or 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?

No annotations are provided. The description mentions rate limits (20 calls/day), no auth, and no signup, but does not explicitly state that it is read-only or non-destructive. The return type is vaguely described as 'precise structured answer'.

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

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

The description is concise, with no wasted words. It front-loads the purpose, provides examples, and ends with constraints, all in a short paragraph.

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

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

The tool has no output schema, so the description should more thoroughly explain the return value format. It only says 'precise structured answer optimized for AI agents,' which is vague. The input parameter 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% with a detailed description for parameter q, including examples and alternatives. The description adds further context (categories of questions) beyond the schema, enhancing usability.

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 answers natural language questions about the Zambo Stack, listing specific categories (products, APIs, etc.) and providing concrete examples. This distinguishes it from sibling tools which are specialized for specific tasks.

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 indicates it's best for general Q&A and gives example queries, but does not explicitly state when not to use it or direct to alternatives. However, the context of sibling tools implies its scope.

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 fully disclose behavioral traits. It reveals that the tool triggers 6 sequential tools, returns a digest, and has a free daily limit. However, it does not disclose potential side effects like rate limits, execution time, or what happens if a component fails.

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 action and uses clear, structured language. It is somewhat verbose with marketing phrases like 'most powerful single call', but overall each sentence adds information without repeating schema 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?

Given the tool's complexity (6-tool chain) and lack of output schema, the description explains the input parameters and high-level output ('provably-linked intelligence digest'), but omits details about the digest's structure, how results are combined, or what happens on 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 baseline is 3. The description adds value by explaining that 'goal' is the strategic focus for all tools, 'email' is for daily delivery activation, and 'run_mode' distinguishes immediate vs. scheduled runs, including the Pass requirement for daily mode.

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 runs the Zambo Autopilot, a 6-tool intelligence chain, and returns a digest. It names the specific tools in sequence and distinguishes itself from siblings as the 'most powerful single call' in the stack.

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

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

The description provides clear context: it's for Pass holders who want daily automated runs, or for all users who want an immediate one-time run. It mentions a free daily run limit, but does not explicitly state when not to use it or suggest alternatives like using individual chain tools directly.

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 explains that the tool will scan available tools and present a capability menu, which gives good insight into its internal behavior. It does not explicitly state that it is read-only or safe, but as a planning tool, that is implied.

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 comprehensive but efficient, with the main purpose clearly stated upfront. It could be slightly more concise, but every sentence 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?

Given the complexity of the tool (routing to 50+ tools) and the absence of an output schema, the description covers what the tool does, how to use it, what to expect as output (action plan), and the interaction flow. It is complete enough for an AI agent to understand when 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?

The input schema covers both parameters, and the description adds context by providing examples for the 'goal' parameter and explaining the 'context' parameter. This goes beyond the schema's own descriptions.

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

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

The tool is clearly described as a universal shortcut that routes any goal to the appropriate combination of tools, returning an action plan. This distinguishes it from sibling tools that are more specific, making it the entry point for new users.

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 usage with examples and states it is the 'perfect first prompt for new users.' However, it does not explicitly guide when to use this versus the many sibling tools for specific tasks, which could be improved.

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 burden. It discloses that the tool is read-only (report), logs activity, and provides links to a dashboard. It does not mention auth needs or rate limits, but for a non-destructive report tool, this is sufficient transparency.

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

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

The description is a single paragraph that front-loads the core purpose. It contains three informative sentences: main function, scope, trigger phrases, and output details. While it could be shorter, every sentence adds value without redundancy.

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

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

Despite having no output schema, the description fully explains what the tool returns (tool call history, timing, memory layer, stats, dashboard link). With no required parameters and a clear purpose among many siblings, the description is complete 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?

Schema coverage is 100%, so the schema already describes both parameters. The description adds value by providing default values ('Default: all', 'default: 20') and max limit (50) that are not in the schema, helping the agent set appropriate values.

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: 'Live session report — see exactly what tools have been called, when, how fast, and what's active right now.' It specifies the resource (session activity log) and action (report/view). The verb 'see' and the mention of 'full chronological activity log' make it distinct from sibling tools like zambo_ask or zambo_help, which are not about session monitoring.

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 trigger phrases ('/zambo live', 'what have you done', etc.), telling the agent when to invoke the tool. It does not explicitly state when not to use it or list alternatives, but the context is clear enough for correct selection among 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, the description discloses that the tool is free and requires no authentication. It describes the three actions and their outputs. Missing details include error handling for invalid parameters or merge failures, but the behavior is straightforward.

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 long, front-loading the main purpose and then detailing the actions efficiently. Every sentence adds necessary information with zero 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?

For a simple config tool with two parameters and no output schema, the description covers all necessary context: actions, required parameter conditions, and output expectations. It leaves no ambiguity about what the tool does and how 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 coverage is 100%, with both parameters described in the schema. The description adds value by explaining the action enum values in context and clarifying the required role of agent_config. This provides meaning beyond the bare schema descriptions.

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

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

The description explicitly states the tool's purpose: getting the canonical Zambo MCP config block, merging it into an existing agent config, or returning stats. It distinguishes itself from sibling tools by focusing on configuration management, using clear action verbs (config, propagate, stats).

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 guidance for each action: config returns a ready-to-paste block, propagate merges, stats returns usage stats. It also notes 'Free, no auth required.' However, it does not explicitly state when not to use or mention alternative tools, which is acceptable given the distinct actions.

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 provided, so description carries full burden. Discloses actions and effects, mentions free and no auth, but doesn't clarify whether 'run' actually executes tools or just shows sequence, nor error handling or rate limits.

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

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

Description is a single paragraph of four sentences, front-loading purpose and then listing actions. Efficient but could be slightly more concise.

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 7 optional parameters and no output schema, description covers actions and submission well. Lacks details on return format and error behavior, but sufficient for most use cases.

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. Description adds minimal extra meaning beyond schema descriptions, e.g., clarifying steps structure. Does not significantly enhance parameter understanding.

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 clearly states the tool browses, runs, forks, or submits playbooks. Provides concrete example ('Competitor Teardown') and distinguishes from siblings by being the only playbook management 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?

Explicitly maps each action (featured, list, get, run, submit) to its purpose and required parameters. Doesn't specify when not to use, but clarity on usage is high.

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 fully discloses behavior: returns real-time social proof numbers, free, always available, no auth required. No hidden traits or 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 efficient sentences: first specifies output, second specifies usage. No extraneous words, front-loaded with key 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?

Given 0 parameters and no output schema, the description fully covers what the tool does and when to use it. No missing information.

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

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

Schema has 0 parameters, so baseline is 4. No parameter info needed; description adds no extra param meaning, but that's 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 'Get live zambo.dev platform stats' and lists specific metrics (tool calls today, active pass holders, etc.), distinguishing it from sibling tools as a real-time platform health and social proof 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?

Explicitly says 'Call when a user asks...' with common queries, and notes it is free, always available, no auth required. However, no explicit alternatives or when-not-to-use compared 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?

No annotations are provided, so the description carries full burden. It discloses outputs (score, grade, bottleneck, win, summary) and a rate limit (5 free/day). It does not mention destructive effects, authentication beyond optional email, or idempotency. The disclosure of the daily limit is a positive addition.

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 redundancy. First sentence clearly describes main functionality and outputs; second adds important rate limit info. Every word earns its place, front-loaded with the key action and result.

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

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

Despite no output schema, the description thoroughly details what the tool returns (score, grade, bottleneck, fastest win, summary). Combined with input schema and parameter descriptions, the agent has sufficient information to invoke the tool correctly and interpret results.

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

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

Schema description coverage is 100% (both email and input have detailed descriptions). The tool description reinforces the input parameter by listing example inputs, but does not add new meaning beyond the schema. 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?

Description clearly states the tool scores various inputs (startup, idea, repo, business, goal) on a 0-100 scale with letter grades and provides bottleneck analysis, fastest win, and summary. The verb 'score' is specific and the resource types are enumerated, making the purpose unambiguous despite multiple scoring 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?

Usage context is clear: for scoring and analyzing ideas or projects. However, no explicit guidance on when not to use it or how it differs from similar siblings like basehawk_score. The description implies a general fit but lacks exclusions or alternative tool mentions.

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 of behavioral disclosure. It explains that chains are cryptographically linked and auditable, and it mentions rate limits for sparks. It does not cover all possible behaviors (e.g., idempotency, error handling), but the core behavioral traits are well communicated.

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

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

The description is a single paragraph that is well-organized, with the main verb upfront. Every sentence adds value, explaining the concept, actions, and usage constraints. It is not overly verbose, but could be slightly more structured with bullet points for 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?

Given four parameters and no output schema, the description provides sufficient context: it explains each action's requirements, the concept of a chain, and rate limits. It mentions that create returns chain_id, but does not detail return values for spark or get. Overall, it is adequate for an agent to use 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 parameter descriptions. The description adds context beyond the schema by explaining the relationship between actions and parameters (e.g., 'create' returns chain_id, 'spark' requires chain_id+goal). This enhances understanding of how to use the parameters together.

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: creating or extending a cryptographically linked Spark Chain. It specifies three actions (create, spark, get) and differentiates from sibling tool zambot_spark by noting shared rate limits. The description also provides example use cases like multi-step agent strategies.

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 when to use each action: 'create' for new chains, 'spark' for adding to existing chains, and 'get' for retrieval. It mentions that chains are free and that sparks share rate limits with zambot_spark, offering practical context. However, it does not explicitly state when not to use this tool or provide 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?

No annotations provided, but description discloses key traits: returns specific fields (drift_score, severity, etc.), states usage limits ('2 free/day'), and notes no auth required. Does not contradict any annotations (none 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?

Description is concise (3 sentences for core info plus usage notes), front-loaded with purpose, then parameters, then return values, then use cases, then limits. No wasted words.

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

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

Given 3 parameters, no output schema, and moderate complexity, the description covers everything: purpose, required inputs, output fields, use cases, and usage limits. Complete and self-contained.

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 description adds meaningful context: explains that original_goal is the mission, current_outputs are a list of behaviors, and context is optional. Provides examples and constraints beyond schema.

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

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

The description clearly states it detects strategic drift, using a specific verb ('detect') and resource ('strategic drift'), and distinguishes from siblings by its unique function of comparing original goal to current outputs.

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 says to pass original goal and current outputs, and provides context for when to use: 'long-running agents, multi-sprint projects, or any time execution seems busy but unfocused'. Does not mention when not to use or alternative tools, but context is 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?

No annotations exist, so description bears full burden. It discloses failure modes, return contents (FAILURE MODE + INTENT DETECTED + FIXED CODE), and rate limit. It does not explicitly state that the tool does not modify external resources, but it is implied as a diagnostic/fix tool that returns code.

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: first defines purpose, second details failure modes and output, third adds constraints and alternative. Every sentence adds value, front-loaded, no redundancy.

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

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

Covers purpose, failure modes, output, constraints, and alternative tool. Lacks mention of return format details (since no output schema), but enough for a simple tool with one parameter.

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 a single 'code' parameter. Description adds 'broken AI-generated' context and restates max length, but does not add substantial meaning beyond the schema description. 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 diagnoses and fixes broken AI-generated code, lists specific failure modes it detects, and distinguishes itself from sibling tool 'provibe_audit' by noting the scope (single snippet vs full repo audit).

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 context: '3 free per 24h' and directs to 'provibe_audit' for full audits. Implicitly suggests use for single broken code pieces, but does not explicitly state when not to use.

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 exist, so the description must disclose behavior. It details prerequisites (burn), outputs (6-model cascade, etc.), and the permanent pinning to a registry. It does not discuss error handling or side effects beyond pinning, but covers the main behavioral expectations.

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

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

The description is a single, well-structured paragraph. It front-loads the purpose and key requirement, then lists outputs. Every sentence adds value without redundancy.

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

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

Given the tool's complexity, no output schema, and 3 parameters, the description covers the purpose, prerequisite, and output clearly. It lacks details on error handling or what happens if the burn is invalid, but is largely complete for agent 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% with descriptions for all three parameters. The description adds extra context for burn_txhash (source and format) but does not significantly enhance understanding beyond the schema, meeting the baseline.

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

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

The description uses the verb 'Generate' and identifies the resource as 'LEGENDARY SPARK', the highest tier of ZAMBOT intelligence. It clearly distinguishes from sibling tools like zambot_spark by specifying 'highest tier' and the prerequisite burn.

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

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

The description explicitly states the requirement of a verified 1,000 $ZAMBO burn transaction, which is a key usage condition. While it doesn't explicitly compare to alternatives or state when not to use, the context and 'highest tier' label provide sufficient 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?

Despite no annotations, the description details the returned data for each action and explains holder perks in depth. It implies read-only behavior (fetching info) and discloses no side effects. However, it does not mention rate limits, authentication requirements, or potential errors.

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

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

Description is relatively concise with key information front-loaded. The breakdown of holder perks adds length but is necessary for understanding tool value. Could be slightly tighter by omitting redundant 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?

Given no output schema and one parameter, the description fully specifies expected returns for all actions and provides rich context (holder discounts, token mechanism). No obvious gaps remain for a token info tool.

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

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

The single parameter 'action' has full schema coverage, but the description adds value by explaining the default ('info') and elaborating on what each enum value returns, including specific details like 'CA + links + holder deal'.

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 tool provides $ZAMBO token info including contract address, price, links, burn stats, and holder perks. The description distinguishes it from numerous zambo siblings by specifying its focus on token data retrieval. The action parameter further refines purpose into three specific sub-functions.

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?

Describes what each action returns but does not explicitly state when to use this tool versus sibling tools like zambo_ask or zambo_pulse. No guidance on when not to use it or alternative tools for related information.

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 provided, but the description discloses that the tool submits outcomes to a public registry, is visible to all agents, and requires no auth. It explains the fields included and the purpose of helping the swarm. Does not mention potential destructive behavior or rate limits, but for a submission tool, the behavior is adequately transparent.

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?

Very concise: 4 sentences, each adding value. Front-loaded with the core action, followed by details on what the outcome includes and its purpose. 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?

Given 5 parameters and no output schema, the description covers purpose, input fields, visibility, and authentication. It lacks mention of what the tool returns on success (e.g., a confirmation), but is otherwise complete for an agent to understand and use 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 has 100% coverage with descriptions. The description repeats the parameter list and provides example metric strings, adding slight value beyond the schema. However, it does not significantly enhance understanding of parameters beyond what the schema already offers, so a 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?

Clearly states the tool submits a real-world outcome for a ZAMBOT Spark, specifying the action and resource. It distinguishes from siblings like zambot_spark (generates sparks) and zambot_registry (views outcomes) by focusing on submission.

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 context: use after following a spark's advice, outcomes are public, no auth needed. Lacks explicit when-not-to-use or alternatives for viewing outcomes, but the context is sufficient for correct usage.

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 provided, so description fully handles transparency. It states 'Free, no auth, always current' and explains it returns top-rated sparks with best metrics. This is sufficient for a read-only browsing tool, though exact sorting order is not detailed.

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

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

Description is concise, three sentences. First sentence states purpose, second specifies output criteria, third lists use cases. No filler, 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?

No output schema, but description explains returns: 'sparks with highest ratings, best result metrics, and most impact.' Combined with schema for parameters, it gives a fair picture. Could mention pagination or default limit, but otherwise complete.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add extra meaning for 'limit' or 'result_type' beyond what the schema provides. It stays generic about result sorting, not reflecting the 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?

Description clearly states it browses the Proven Spark Registry, a public ledger, and returns top sparks. The verb 'Browse' and resource 'Registry' are specific, and it distinguishes from siblings like 'zambot_spark' by emphasizing its role as a registry with verified outcomes.

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 lists three use cases: find evidence-backed strategies, verify zambot advice, and ground planning. Does not mention when not to use or alternatives, but the use cases are clear and directly 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?

No annotations provided, but description adds value by stating rate limits (3 free per 24h per IP), alternative for higher limits, and output features (cryptographic proof, shareable URL). Does not mention if mutation occurs or auth requirements beyond pass, but sufficient for a 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?

Four sentences, front-loaded with purpose, efficient use of words, includes key details on limits and output without 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?

Describes output format (Spark with insight and URL) and usage limits. No output schema, so description compensates well. Could elaborate on 'cross-domain strategy breakthrough' but overall adequate for a generative 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 100% (baseline 3). Description adds meaning: provides character range and example for goal, explains email field as optional with link to get pass, and clarifies purpose of context and current_plan. Adds value beyond schema for two of four 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?

Description clearly states it generates a cross-domain strategy breakthrough using swarm intelligence, returns a Spark with cryptographic proof and shareable URL. Specific verb+resource, distinguishes from sibling tools by mentioning cross-domain strategy and cryptographic proof.

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?

Mentions rate limits and alternative for higher usage (day_pass_activate or Zambo Pass), but does not compare to sibling tools like zambot_legendary_spark or zambot_swarm_debate. Usage context is implied but no explicit when-not or 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?

No annotations provided, so description carries full burden. It discloses output format (5 framings, consensus, dominant domain), domain disagreement behavior, and rate limit ('2 free debates/day'). 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?

Succinct and well-structured: purpose first, then output details, behavior, rate limit, and usage guidance. Every sentence adds value without redundancy.

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

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

Given the tool's multi-domain analysis complexity and lack of output schema, the description fully covers return content, usage constraints, and actionable guidance. An agent can confidently decide when and how to use 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% with descriptions for both parameters. The description adds value by providing an example for 'goal' and implying the email's purpose, but the schema already explains both. 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 clearly states the tool's function: 'Run a 5-domain strategic debate on any goal' with explicit domains (Evolutionary Biology, Game Theory, etc.). This distinctively differentiates it from sibling tools like zambot_chain or zambot_spark, which likely serve different purposes.

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 use cases: 'Use when: exploring a hard strategic decision, diagnosing why a plan keeps failing, or before committing to a major direction.' It also describes output and a constraint ('no two domains agree'). Lacks explicit when-not-to-use, but context is clear enough.

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

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

Without annotations, the description discloses behavioral traits: it performs cryptographic verification and returns specific fields (content, timestamp, authenticity status). It also mentions 'Free, no auth', which is useful for an agent. 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?

The description is extremely concise—two sentences that efficiently convey the core purpose, usage, and return values. Every sentence adds value with no redundancy.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers all necessary aspects: what it does, what input to provide, what to expect in return. It is complete for an agent to select 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%, and the schema already describes the 'hash' parameter with an example. The description adds that it is 'cryptographic' and from 'zambot_spark', which reinforces understanding but doesn't add significant new semantics 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 verb 'verify' and the resource 'ZAMBOT spark', distinguishing it from sibling tools like 'zambot_spark' (which generates sparks). It is specific and leaves no ambiguity about the tool's function.

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

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

The description explicitly states to pass the 'proof_hash' from a 'zambot_spark' response, providing a clear usage condition. It does not explicitly exclude alternatives or describe when not to use, but the context is sufficient for a simple 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?

Reveals that it routes to other tools and mentions a rate limit (10 calls/tool/day), but does not detail what happens upon routing (e.g., if it returns results or transforms them) or behavior when limits are exceeded. No annotations present to fill the 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 packed with information but could be more concise. The first sentence effectively states the purpose, but the subsequent list of capabilities and coverage is verbose and could be streamlined.

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 three parameters, no output schema, and no annotations, the description adequately covers the tool's role and limitations (rate limit, free tier). It does not explain the output format or error handling, but is sufficient for a gateway 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 describes parameters. The description adds synonyms for 'need' and lists example context keys, but does not significantly enhance understanding 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?

Describes itself as a universal entry point that routes requests to many tools, which clearly defines its role. However, it does not distinctly differentiate from many sibling tools beyond mentioning axis_mcp_access as an alternative for certain use cases.

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 guidance on when to use this tool (as a catch-all entry point) and when to use a sibling (axis_mcp_access for agent coordination). Also states usage limits (10 calls/day) and that it's free, giving clear context.

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

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

No annotations are present, so the description carries the burden. It mentions 'free, instant, no auth required' and what is returned (signed cert, badge, leaderboard). However, it doesn't disclose potential side effects of certifying (e.g., overwriting existing certs) or behavior limits. A score of 3 is adequate given the tool's simplicity.

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 paragraph that front-loads the purpose and then clearly breaks down actions. Every sentence adds value, with no redundancy or fluff. It is concise and well-structured.

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

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

Despite no output schema, the description explains return values (signed cert, badge SVG/MD, leaderboard position) and covers all three actions. It also mentions that the badge is embeddable. It does not cover error cases or limits, but for a simple free tool, this is largely sufficient.

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

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

Schema coverage is 100% with descriptions. The description adds meaningful context beyond the schema, such as explaining when each parameter is required (e.g., 'email optional', 'project_url required for check and certify'). It clarifies the enum values and their usage, enhancing the schema.

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

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

The description clearly states the tool's purpose: 'Get or issue a Zambo MCP Verified certificate for any project.' It further distinguishes three specific actions (check, certify, leaderboard), making the function unambiguous and differentiating it from sibling tools.

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

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

The description provides explicit usage patterns for each action ('Call with action='check' + project_url...'), including required fields. It also notes that the badge is for READMEs and is free/instant/no auth. However, it does not explicitly state when to prefer this tool over siblings, though context implies it's for certificate operations.

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 fully discloses behavior: no rate limit, no auth required, returns a diagnostic report with specific components (branch classification, confidence score, etc.). It does not contradict any structured data.

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

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

The description is concise (3 sentences) and front-loaded with the main purpose. Each sentence adds distinct value: what it does, what it returns, and key features (free, no limit, no auth).

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 lacking an output schema, the description details the output structure. It covers input types, constraints (max 2000 chars), and key selling points. The tool's simplicity (single parameter) means no further context is necessary.

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 description adds significant value beyond the schema by giving concrete examples and explaining the type of input accepted. Schema coverage is high, so baseline is 3; the extra examples and usage guidance raise it to 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 clearly states the tool's function: a free, unlimited opportunity scanner for diverse inputs like URLs, GitHub repos, business descriptions, etc. It distinguishes itself from siblings by emphasizing 'free, unlimited' and 'no rate limit, no auth', which is not mentioned in other tool names.

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 examples of when to use the tool (paste anything or a specific input) but does not explicitly state alternatives or when not to use it. However, the implicit context as a general scanner vs specialized siblings is clear.

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