Zambo AI Tools

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

With no annotations provided, the description carries full burden. It discloses that the tool returns 'active:true' for both passes and lists the benefits and API endpoint. It does not contradict any 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 informative but somewhat lengthy, detailing pass benefits and Day Pass details. While it front-loads the main purpose, it could be more concise. It earns its place but is not optimally compact.

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 1 parameter and no output schema, the description explains the return value ('active:true') and provides the endpoint. It is fairly complete for a simple check 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 schema has 1 parameter with description. The description adds value by specifying that the email is checked for both Zambo Pass and Day Pass, which is not fully covered in the schema. Schema coverage is 100%, so baseline is 3; the added context justifies a 4.

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

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

The description clearly states the tool checks if an email has an active Zambo Pass or Day Pass, using a specific verb ('Check') and resource ('email address for pass status'). It distinguishes itself from sibling tools like credithunt and leadsignal by focusing solely on pass 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 recommends using this tool before bulk API calls to know rate limits, and mentions the alternative Day Pass. However, it does not explicitly state when not to use it or provide exhaustive 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?

Although no annotations are provided, the description implies a read-only search operation by describing the output (relevant products with scores). However, it does not explicitly state that it has no side effects or require no special permissions, but the nature of search 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 three sentences: purpose, return details, and usage guidance. Each sentence adds value with no redundancy, well-structured and front-loaded.

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

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

Given the simplicity (1 parameter, no output schema), the description sufficiently explains the tool's scope (all 19 products), output (up to 8 results with specific fields), and usage context (before zambo_universal). It is complete for an AI agent to decide when and how to use 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 a detailed description and examples for the 'q' parameter. The description adds no extra information about the parameter beyond what is in the schema, so 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 verb (search), resource (all 19 Zambo Stack products), and purpose (find what fits your use case). It also differentiates from sibling tools like zambo_universal by specifying its role as a preliminary search.

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

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

The description explicitly says to use this tool before zambo_universal when you know exactly which product you want. This provides clear when-to-use and alternative guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses that the index is 'verified daily' and 'dead links auto-removed', indicating a maintained, read-only service. This adds useful behavioral context beyond the input schema.

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

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

The description is front-loaded with the core purpose and unique selling points. It lists 11+ program names, which adds credibility but slightly increases length. Overall, it is efficient and mostly free of 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 (filtering a list) and absence of output schema, the description adequately conveys what the tool returns ('matched recommendations') and its maintenance status. It could briefly mention the output format (e.g., list of program names and credits), but the current description is sufficient for basic 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 input schema already describes all three parameters with 100% coverage. The description adds minimal value, merely restating that the stack parameter is for 'matched recommendations'. The stage and min_value parameters are not elaborated 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 explicitly states the tool is a 'Live, verified index of every AI and cloud startup credit program' and specifies the ability to get matched recommendations by passing a tech stack. It clearly distinguishes itself from siblings by focusing on credit programs, a niche not evident 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 clear context: it's free, requires no auth, and suggests using the stack parameter for matching. However, it does not explicitly state when not to use it or compare it to sibling tools, leaving the agent to infer usage boundaries.

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 rate limits (3 free searches per day per IP), no authentication required, and expected output ('5 qualified leads with contact info in under 60 seconds'). However, it does not specify failure modes (e.g., unsupported trades, missing city) or caching behavior. These are minor omissions.

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 concise sentences, front-loaded with the core purpose. Every sentence adds value: purpose, input/output, constraints. 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 no output schema and simple parameters (2 strings), the description adequately covers what the tool does and returns. It lacks detailed return field names (e.g., what 'contact info' includes) and edge cases, but for the complexity level this is sufficient.

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

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

Schema coverage is 100% with examples, but the description adds value beyond schema by noting the tool supports 24 trades and any US city, and that it returns 5 leads. This enriches the agent's understanding of valid inputs and output scale.

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: generate leads for contractors and local service businesses. It specifies the verb 'get', the resource '5 qualified leads with contact info', the inputs 'trade type and city', and the scope 'supports 24 trades and any US city'. This is specific and distinct from siblings.

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

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

The description implies usage context (lead generation for trades) but does not explicitly state when to use this tool over alternatives. Siblings are mostly unrelated, so no explicit exclusions or alternative guidance is provided. The rate limit and auth info are usage constraints but not comparative.

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?

Describes return data (credentials, skills, roles, verification status, reputation) and states it's free and requires no auth. With no annotations, this provides adequate behavioral context for a read-only lookup 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, each adding value: action, returns, use case, access. No wasted words, front-loaded with the primary purpose.

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 1-parameter tool with no output schema or annotations, the description covers return fields, usage advice, and access details. Could mention error handling but not essential.

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 clearly describes the 'slug' parameter with examples. The tool description does not add any additional parameter 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?

Clear verb ('look up') and resource ('verified professional trust passport on Signal'). Specifically distinguishes from siblings by focusing on Signal profiles and returning credentials, skills, roles, etc. No other sibling tool explicitly targets Signal identity lookups.

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 states when to use: 'verify identity and trust before collaboration.' Also notes 'Free, no auth.' However, no explicit exclusions or alternative sibling tools mentioned.

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 transparently describes behavioral traits: returns a 'precise structured answer optimized for AI agents', mentions free tier and no auth/signup, and implies a deep scan mode. There is no contradiction.

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

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

The description is highly concise: two sentences plus a list of example queries. It is front-loaded with the core action and provides essential details without extraneous text.

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 param, no output schema, no nested objects), the description covers purpose, usage, and behavioral limits. It could be more complete by clarifying how 'deep scan mode' works or handling out-of-scope questions, but it 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?

Only one parameter 'q' with 100% schema coverage. The description adds value by specifying the domain (zambo.dev, 19 products), character limits (5–500), and examples. However, it does not describe the return format or error handling, which could be helpful.

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: answering natural language questions about the Zambo Stack, listing specific topics like products, APIs, and pricing. It distinguishes from siblings by being a general Q&A tool, unlike the more specific sibling tools (e.g., builder_pass_check, leadsignal).

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 (e.g., 'Best for: 'What does ZAMBRO do?') and mentions rate limits ('20 calls/day free'). However, it does not explicitly state when to avoid this tool or recommend alternatives among siblings, which would improve clarity.

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 outputs (failure mode, intent, fixed code) and a rate limit. It does not mention destructive side effects, but the tool appears read-only.

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

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

Extremely concise: three sentences front-loading purpose, then details. 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?

For a simple one-parameter tool without output schema, the description fully covers purpose, behavior, and constraints (rate limit). Nothing essential is missing.

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

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

Schema description coverage is 100% for the single parameter 'code', with identical information in the tool description. The description adds no additional 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 diagnoses and fixes broken AI-generated code, listing specific failure modes and outputs. It distinguishes from sibling tools by focusing on fixing rather than analysis or other 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 implies usage for broken AI code but lacks explicit when-not-to-use or alternatives guidance. It does provide a usage limit (3 free per 24h), which aids in 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 description carries full burden. Discloses cryptographic proof_hash, daily rate (3/24h/IP), and paid tier (Zambo Pass). Does not mention side effects or auth requirements beyond email, but for a generation tool this is sufficient.

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) and front-loaded with primary function. Includes essential details without fluff. Minor redundancy: 'spark' is defined twice.

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 main purpose, constraints (rate limits, pricing), and output (insight + proof_hash). No output schema, but description explains return value. Lacks details on how proof_hash is verified, but acceptable for a generation tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining email is optional with pricing context, and provides example for goal. Goes beyond schema with usage limits and verification details.

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 specific verb ('Generate' + 'synthesizes') and resource ('cross-domain strategy breakthrough' / 'spark'). Distinguishes from siblings by mentioning 'swarm-wisdom from 19 live products' and unique output (insight + proof_hash).

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 instead of siblings (e.g., zambot_fix, zambo_ask). Mentions rate limits and pricing but does not differentiate use cases 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?

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?

No annotations are provided, so the description carries full burden. It clearly discloses key behaviors: free, no API key, 10 calls/day per IP, route through 19 live AI products, and expert structured response. Could add data handling details, but overall strong.

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 verbose with marketing language ('THE primary') and a long list of use cases. While front-loaded about purpose, it could be more concise. Every sentence contributes, but some are promotional.

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 (one required, nested objects) and no output schema, the description provides general coverage but lacks details on response structure or format specifics for the routed responses. Adequate but not 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 examples for the 'need' parameter but doesn't significantly enrich meaning beyond the schema. The 'format' and 'context' parameters are adequately described in the schema.

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

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

The description states it's the primary endpoint for natural language needs and lists many use cases, but it doesn't differentiate from sibling tools like zambo_ask or zambot_verify, making the purpose vague for an AI agent selecting among them.

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 universal applicability ('anything') without explicit guidance on when not to use it or alternative tools, despite many siblings existing. It mentions rate limits and free access but lacks 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?

With no annotations provided, the description carries full burden. It discloses key behavioral traits: no rate limit, no auth, deterministic, free, unlimited. It also describes the return format. However, it doesn't mention data handling or statelessness, which would add completeness.

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 4 sentences, front-loaded with core value proposition. Every sentence adds unique information: purpose, input types, output components, and constraints. No redundancy or filler.

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

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

The tool is simple (1 param, no output schema), and the description thoroughly covers input, output, and constraints. Could mention response time or whether it's real-time, but overall sufficient for reliable invocation.

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

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

Schema coverage is 100% for the single 'input' parameter, but the description adds significant value by listing example input types (URL, wallet, GitHub repo, etc.) and clarifying max length (2000 chars). This goes beyond the schema's brief 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?

Description clearly states it's a 'free, unlimited deterministic opportunity scanner' that analyzes various input types (URL, wallet, repo, etc.) and returns a diagnostic report with specific outputs. It distinguishes itself from sibling tools by mentioning '21 specialized branches' and the range of analyzable inputs.

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?

Implied usage via examples ('Paste anything — a URL, wallet address...') but no explicit guidance on when not to use or comparison to sibling tools. Alternatives like builder_pass_check or capability_search are not mentioned, leaving the agent to infer context.

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