Boolsai Directory

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 the data source (Schema.org markup) but does not disclose potential behavioral traits such as rate limits, pagination, or limits on results. It is minimal but not misleading.

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

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

The description is two sentences with no wasted words. The first sentence states the core function and data source; the second provides a practical use case. It is 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 tool's simplicity (one required parameter, no output schema) and high schema coverage, the description is mostly complete. It could briefly mention the output format or what 'list brands' entails, but the lack of that information is not severely detrimental.

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% (single parameter 'founder' with description). The description adds no additional meaning beyond the schema, which already indicates case-insensitive behavior. With full coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('List brands attributed to a founder') and the data source ('from Schema.org Organization markup'). It distinguishes this tool from siblings like brands_in_city or brands_in_market by the unique filtering criterion (founder).

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 hints at a use case ('tracking serial DTC founders') but does not explicitly state when to use this tool versus alternatives or provide exclusions. With many sibling tools, more explicit guidance would be beneficial.

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 disclose behavioral traits. It mentions the data source (Schema.org Organization JSON-LD) but does not discuss limits, pagination, update frequency, or any other behavioral aspects. The description is insufficient for a tool with 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 extremely concise at two sentences, with no wasted words. It front-loads the core purpose and data source.

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 simplicity (single parameter, no output schema, one required field), the description adequately explains the source and action. However, it could mention result format or limits, but overall it is mostly complete for a straightforward list operation.

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 the 'city' parameter having a clear description and examples. The tool description adds no further parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: listing indexed brands with a physical address in a given city. It uses a specific verb ('List') and resource ('brands that publish a physical address in a given city'), and the data source is mentioned, differentiating it from siblings like 'brands_by_founder' or 'brands_in_market'.

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

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

There is no explicit guidance on when to use this tool versus alternatives. While the description implies a use case (city-based brand lookup), it does not specify exclusions, prerequisites, or compare with 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 are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or rate limits. The tool appears to be a read operation, but this is not explicitly stated.

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

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

A single sentence that is direct and to the point, 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?

Given the simplicity of the tool (one parameter, no output schema), the description provides enough context to use it, but lacks details about the output format or any behavioral aspects.

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 and schema both mention the country is a 2-letter ISO code, lowercase, so the description adds no new meaning beyond the schema.

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

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

The description clearly states it lists brands serving a country market via hreflang, differentiating it from siblings like brands_in_city and brands_by_founder. The verb 'List' and resource 'brands in market' are specific.

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 implies usage for country-level brand lists via hreflang. While it doesn't explicitly say when not to use or list alternatives, the context from sibling tool names and the description itself make the purpose clear.

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

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

With no annotations provided, the description carries the full burden. It discloses pagination (up to 1000 rows per page), cursor for continued pages, full row count returned, and output formats (CSV, JSONL). It does not mention authentication, rate limits, or whether the operation is read-only, but for an export tool, the behavioral details are 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?

The description is three sentences, each serving a purpose: the first states the core function and features, the second provides a real-world use case and example, and the third adds the full row count detail. No fluff or redundancy. Highly concise 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 lack of an output schema, the description adequately covers return values (rows per page, cursor, full row count). It addresses pagination, formats, use case, and example. It does not discuss error handling or timeouts, but for a data export tool of this complexity, the description is complete enough 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%, baseline is 3. The description adds value beyond the schema by explaining the cursor (continued pages), recommending CSV for CRM import, referencing list_signal_types for signal_type discovery, and clarifying the role of signal_value and market_country. This additional context helps the agent understand parameter usage.

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

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

The description clearly states the tool performs a paginated bulk export of indexed sites matching a filter. It specifies the verb 'export', the resource 'indexed sites', and key details like pagination (1000 rows per page), formats (CSV, JSONL), and cursor for continuation. This distinguishes it from siblings like 'bulk_export_url' and 'sites_using_vendor'.

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: 'when an agency needs an outbound prospect list... for CRM import', and provides an example. It does not explicitly list when not to use it or mention alternatives, but the context from siblings implies other tools for specific queries. Overall, the guidance is clear and contextual.

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 URL is public, no auth, returns NDJSON/CSV with chunked-transfer streaming. No annotations provided, so description carries full burden; could mention URL expiration or rate limits but overall 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?

Three concise sentences with no fluff. Front-loaded with main purpose and immediately useful guidance.

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 return type (URL, format, streaming). Sufficient for an agent to understand what it receives. Could mention temporary nature of URL.

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 75% with descriptions. Description adds context for format and purpose but does not significantly extend 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?

Clearly states 'Returns a streaming-export URL' and contrasts with bulk_export. Distinguishes purpose and scope.

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 when to use bulk_export (N<1000) vs this tool for bigger exports. Also mentions use case for curl/HTTP pipe.

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 that the tool returns added/removed/changed vendors, account IDs, and inline-script signals, and explains default behavior for omitted timestamps. Lacks mention of auth or rate limits but is otherwise 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?

Two sentences, no wasted words. The purpose is front-loaded, and every sentence adds meaningful information. 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, no output schema, and no annotations, the description is complete. It explains inputs, outputs, default behavior, and typical use case. No gaps.

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

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

Schema coverage is 100%, baseline 3. The description adds value by explaining the default behavior when t1/t2 are omitted ('compares oldest vs newest'), 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 the tool's purpose: comparing two historical scans of the same URL to surface stack changes. It specifies the resources returned (vendors, account IDs, inline-script signals) and distinguishes from siblings like 'compare_sites' which compare different sites.

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 context: 'Use this for competitor watch — what did patagonia.com just deploy?' and explains default behavior when t1/t2 are omitted. This guides the agent on when to use this tool vs alternatives.

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

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

With no annotations, the description carries full burden. It discloses that the tool compares 2-5 domains, returns vendors, account IDs, brand info, markets, and identifies shared/unique signals. This goes beyond the schema to explain behavioral output.

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 clear, front-loaded sentences. No wasted words. First sentence states action and output, second gives usage examples. Perfectly 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 simple input (one array param) and no output schema or annotations, the description fully covers purpose, input constraints, and output contents. No missing elements for this complexity level.

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 param 'urls' with description). The description confirms the range (2-5 domains) but does not add new detail about parameter formatting or validation beyond the schema. Adequate but not enhanced.

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 'Side-by-side stack comparison of 2-5 domains' and details what it returns (vendors, account IDs, brand info, markets, shared/unique signals). This specific verb+resource distinguishes it from siblings like site_dossier (one site) or similar_sites (finding similar).

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

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

The phrase 'Good for "compare X.com vs Y.com" or competitive teardowns' gives clear usage context. While it doesn't explicitly state when not to use, the examples effectively guide the agent to appropriate scenarios.

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 it accepts a combination of filters and returns sites with signals, but lacks details on pagination, rate limits, or ordering. With no annotations, the description carries full burden but is 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, no redundant words. Front-loaded with the key purpose, then lists parameters and return type. 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?

No output schema, but description covers return values ('matching sites + their key signals'). Missing details on pagination but acceptable for a query tool. Adequate given the tool's 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 value by indicating any combination of parameters can be used, which is not explicit in the schema, raising 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?

Clearly states it's a unified query tool against the Boolsai Directory, distinguishing from sibling granular tools. Uses 'Unified query' and 'One tool to rule the other lookups' to establish its role.

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 when to prefer this tool: 'when you have multiple filter conditions to AND together.' Implies single conditions should use granular tools. Provides 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 exist, so the description provides full behavioral context. It discloses caching (24h), freemium model, and data sources (Cloudflare DoH + public RDAP). It also explains the signal value, which helps the agent understand output interpretability.

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 compact paragraph where each sentence adds value (purpose, returned fields, caching, use case). It is front-loaded with the core action. Slightly verbose in listing fields but overall 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 tool's simplicity (one parameter, no output schema), the description is remarkably complete. It covers input, output, caching, data sources, and even provides a practical usage example. No gaps remain for an agent to misuse the tool.

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

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

Schema coverage is 100% (single parameter 'domain' with description). The tool description does not add new parameter semantics beyond what the schema already provides. Baseline 3 is appropriate since the schema is sufficient.

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 'Free DNS/WHOIS enrichment for a single domain' and enumerates the returned data (email host, DNS provider, CDN, registrar, domain age). It clearly distinguishes from sibling tools like site_dossier or subdomain_map by focusing on a single domain's enrichment.

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 clearly implies when to use (quick enrichment of one domain) but does not explicitly state when not to use or mention alternative tools. The use case is well-contextualized with the example insight, but no direct exclusions or sibling differentiation.

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 explains the algorithm (full vendor set, not just archetypes), parameters (limit, min_shared), and that it returns top N matches with scores. It adequately discloses behavioral traits 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 concise with no wasted words: two sentences plus a usage example. The first sentence states the core purpose, the second provides usage guidance.

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 no annotations, the description sufficiently covers the algorithm, usage, parameters, and return type. It is complete for effective tool 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 the description's parameter details (e.g., min_shared meaning) add little beyond the schema. The context of Jaccard similarity helps but doesn't 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?

The description clearly states the tool finds sites with the most-similar vendor stack using Jaccard similarity, specifies the resource (sites) and method, and distinguishes from the sibling similar_sites by noting it's more accurate for niche stacks.

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 when to use this tool ('when stack_archetype labels are too coarse') and contrasts it with similar_sites, providing a concrete usage example.

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 discloses it is a cross-reference lookup (non-destructive), but does not mention side effects, rate limits, or return behavior (e.g., empty results). Minimal but acceptable.

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 clear sentence followed by a bullet-list of signal types. No redundant words; efficiently front-loads purpose and key 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 lookup tool with no output schema, the description omits details about return format or behavior on no match. Considering the simplicity and good parameter info, it is minimally complete but could be improved.

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 the description adds value by enumerating valid signal types and providing examples for signal_value, which goes beyond the schema's brief 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: 'Cross-reference any tenant-unique account ID across the index.' It provides specific use cases and lists numerous signal types, 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 gives explicit usage examples ('useful for who else shares this...'), which helps the agent decide when to use it. However, it does not explicitly mention when not to use or compare with alternatives like similar_sites or domain_intel.

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 convey behavior. It states the core functionality but omits behavioral details such as rate limits, authentication requirements, data freshness, or whether it is read-only. The enthusiastic tone lacks cautionary notes.

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 well-structured: it starts with the core purpose, gives examples, explains the value proposition, and ends with usage guidance. Every sentence contributes meaning.

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 does not detail return format (e.g., list of domains, cluster info). However, it adequately describes inputs and core behavior. The limit parameter is not elaborated in description, but schema covers 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%, baseline 3. The description adds value by providing concrete examples and explaining auto-detection of signal_type, and the domain alternative. 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: 'Find every domain sharing a tenant-unique ID' with specific examples (Stripe pk_live, Sentry DSN, etc.). It distinguishes from sibling tools by focusing on tenant IDs, not other signals like founders or cities.

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

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

Explicit usage guidance is given: 'Use this when you want to discover the actual operator behind a brand, or expand a single brand into its full portfolio.' It contrasts with competitors but does not explicitly state when not to use it (e.g., for non-tenant lookups).

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 that the tool runs four live sub-queries against indexed data, returns structured pitch angles, and saves time. This is good behavioral context, though it could mention if it's read-only or any 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 paragraph that front-loads the key purpose ('ONE-CALL PROSPECT BRIEF') and lists the sub-queries. Every sentence adds value, though it could be slightly more concise by removing redundant phrasing like 'for agency outbound' (already implied).

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 explains the return content (four specific outputs). For a complex tool with multiple sub-queries, this provides sufficient completeness for an agent to understand what to expect.

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 the description adds value by explaining that 'url' is the prospect's domain, 'angle' is optional with specific values (cro, analytics, etc.), and what happens if omitted. This clarifies usage beyond the schema.

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

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

The description clearly states the tool's purpose: it's a 'ONE-CALL PROSPECT BRIEF' that aggregates four sub-queries (dossier, sister brands, competitors, pitch angles) with a specific audience (agency outbound). It distinguishes from sibling tools like site_dossier or operator_cluster by combining multiple queries into one 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 explicitly says 'Use this whenever the user asks 'tell me about prospect.com'' and frames it for agency outbound, providing clear context. It does not explicitly state when not to use it, but the usage scenario 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 only gives vague return description ('sites running similar tech') without details on read-only nature, rate limits, pagination, or data freshness. Very little 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?

Two sentences with no wasted words. First sentence states purpose, second adds context. Both sentences earn their place.

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

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

For a simple 1-parameter tool with no output schema, the description minimally explains the return value ('sites running similar tech') but lacks details on result format, error handling, or 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% for the single parameter 'url', with a clear description in the schema. The tool description adds no new information about the parameter. 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?

Description clearly states the verb 'find' and resource 'brands with similar stack archetypes given a domain'. However, it does not differentiate from sibling tool 'find_similar_by_stack', which likely has an overlapping purpose.

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

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

Provides clear context by mentioning use cases like benchmarking, prospecting, and competitor lookups. But lacks explicit when-not-to-use or alternative tools.

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

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

No annotations provided, so description carries full burden. It lists what the output includes (vendors, account IDs, brand identity, etc.), implying a read-only operation with no side effects. Transparent about scope.

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 compact (2 sentences) but dense with information. Front-loaded with purpose and lists categories efficiently. Slightly lacking structure (bullet points would help), but 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?

Despite no output schema, the description thoroughly enumerates all major return categories (vendors, account IDs, brand identity, markets, siblings). For a single-parameter read tool, it is fully 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% for the single parameter 'url'. The description adds only example inputs ('gymshark.com' or full URL). Baseline of 3 is appropriate as schema already defines the parameter adequately.

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 specifies a comprehensive dossier for a single domain, listing vendors, account IDs, brand identity, markets, etc. It uses a specific verb ('Full intel dossier') and resource, clearly distinguishing from sibling tools like domain_intel or subdomain_map.

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 'Use for any 'what's running on X.com?' query,' providing clear context. Does not explicitly exclude alternatives, but the guidance is specific enough for an agent.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns a domain list with brand names where known, and clarifies the vendor slug format (lowercase, underscore-separated). No mention of pagination or output limits, but for a simple list tool, this is fairly 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?

Two sentences, no wasted words. The first sentence states purpose with examples, the second clarifies format and return structure.

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 single-parameter input, the description is mostly complete. However, lack of output schema means the description should fully describe return values; it mentions domain and brand names but not whether results are paginated or limited, which could be important for an AI agent.

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%, but the description adds value by specifying the slug format and providing examples, which go beyond the schema's generic 'e.g.' examples.

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

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

The description clearly states 'List indexed sites detected using a specific vendor', specifies the verb 'List', resource 'sites detected using a vendor', and distinguishes from siblings by focusing on vendor detection rather than other criteria like founder or city.

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 finding sites by vendor but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.

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

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

No annotations exist; the description does not mention read-only behavior, auth needs, or rate limits. While 'List' implies safety, the absence of explicit transparency is a 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?

Two sentences: the first states the purpose concisely, the second lists valid inputs. No wasted words, front-loaded with key 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 simple list tool with one parameter and no output schema, the description is sufficient. It covers what the tool does and valid inputs. Could mention output format but not 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?

Schema coverage is 100% with a single parameter described as 'Archetype slug'. The description adds value by enumerating all valid slug values, going 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 'List brands matching a stack archetype', with a specific verb and resource. It distinguishes from siblings like 'brands_by_founder' by focusing on stack archetypes.

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 when-to-use guidance or alternatives are provided. The list of valid slugs aids usage, but there is no mention of when to choose this over siblings like 'find_similar_by_stack'.

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 mentions 'we've ever scanned' implying historical data but does not discuss data freshness, authentication needs, rate limits, or what happens on invalid input. The description lacks critical transparency about the tool's limitations and operational characteristics.

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 largely efficient: it front-loads the core purpose in the first sentence, then lists benefits and use cases. Each sentence adds meaningful information without repetition. It is slightly longer than necessary but still well-structured and clear.

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 returns grouped subdomains with no output schema, the description partially compensates by explaining the output grouping (by vendor) and providing use cases. However, it lacks details on pagination, error handling, or what happens if the root domain has no subdomains. The description is moderately complete but could be more 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 coverage is 100% with descriptions for both parameters. The description adds extra context for 'root' (e.g., 'pass just the apex; we'll find subdomains automatically'), which enhances understanding beyond the schema. However, for 'limit', the description repeats the schema's range. Overall, it adds some value but not significantly beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: it retrieves subdomains for a given root domain. It explains the value (storefront topology, checkout location, etc.) and distinguishes from sibling tools like brands_by_founder or directory_query by focusing on subdomain mapping. The verb 'map' and resource 'subdomains' are specific and unambiguous.

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

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

The description provides explicit use cases: finding the right path to scan, spotting enterprise topology, and discovering sister surfaces. This gives clear context for when to use the tool. However, it does not explicitly mention when not to use it or suggest alternative tools, though the context of siblings implies some differentiation.

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 that the tool returns global statistics and lists the data categories. While it implies a read-only operation, it does not explicitly state side effects or permissions, but given the 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?

The description is two sentences: first states what the tool does with examples, second gives usage advice. Front-loaded, no filler words, every sentence earns its place.

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

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

Given no output schema but zero parameters and simple purpose, the description fully explains what the agent will receive. It lists key data points, making it complete for an agent to understand return value and 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?

The tool has zero parameters, so baseline is 4 per rules. The description adds significant value by detailing what the output contains (sites indexed, signal types, top vendors, most-changed companies), fully compensating for the absence of 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 explicitly states the tool returns 'Global stats for the Boolsai directory' and lists specific data points (sites indexed, signal types, top vendors, most-changed companies). This clearly distinguishes it from sibling tools like directory_query or site_dossier.

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 use 'at the start of a session', providing clear context for when to use. It does not mention when not to use or alternatives, but the guidance is sufficient for this simple tool.

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