BotFriendly

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

No annotations are provided, so the description carries the full burden and it discloses key operational traits: it fetches without JavaScript or cookies, is rate-limited to 6 checks per minute, each check takes a few seconds, and can return either a scored report or a readiness prompt. It also promises evidence and fix advice per check, making outputs and side effects predictable.

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 dense but every clause earns its place: it covers purpose, how the site is fetched, what is evalued, what the output includes, the alternative format, and operational limits. It front-loads the core action and avoids 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?

With no output schema and no annotations, the description covers the essentials: input restrictions, the full set of checks, scoring scale, evidence/fix output, the prompt alternative, and rate limits. An agent can correctly decide whether to call the tool and can plan for latency and throughput.

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%; both parameters already have meaningful descriptions in the input schema, including 'scheme optional, https assumed' and the json/prompt enum behavior. The description reinforces the prompt formatting mode but does not add new parameter-level detail beyond what the schema provides.

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

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

The description opens with a specific verb and measurable outcome ('Score how bot-friendly a website is (0-100)') and then enumerates the exact checks performed, making it unmistakable from sibling catalog/service tools. It names concrete resources such as robots.txt, llms.txt, sitemap, and OpenAPI, so an agent knows precisely what is evaluated.

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 frames the tool as a bot-access audit and explains the format='prompt' conditional, which gives the agent context for choosing a mode. It does not explicitly name when-not-to-use or an alternative tool, but the sibling tools are unrelated, so the omission is minor and the intended 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?

With no annotations, the description carries the behavioral burden. It discloses the max-3 cap and that results are paid placements marked as ads, which is material for an agent deciding whether to surface them. It does not cover return format or error behavior, but for a simple zero-parameter read tool this 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?

Two tight sentences with no filler: the core action and limit come first, followed by a clarifying disclosure about the ad nature. Every clause earns its place and the information 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?

For a zero-parameter, no-annotation, simple list tool, the description is complete: it tells the agent what is returned (featured services), the scope (site-wide), the count cap (max 3), and the key semantic detail (paid placements marked as ads). No essential information is missing for correct invocation.

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

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

There are zero parameters, so the schema already fully covers everything and the baseline is 4. The description adds useful context about scope and result nature (site-wide, max 3, paid ads), which reinforces what an agent should expect without needing parameter-level detail.

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

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

The description states a specific verb and resource: retrieve site-wide featured/promoted services. The qualifiers 'site-wide' and 'max 3' clearly differentiate it from siblings like get_service (single service) and search_services (search all), so an agent can select it without ambiguity.

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 context of paid placements and the max-3 limit implies when to call it (when the agent needs featured/promoted services), but it does not explicitly say when to prefer an alternative or mention exclusion criteria. It gives enough context to infer usage, though without direct alternative routing.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It is an implied read-only stats call and describes the per-entry content: sponsor, layer, spec URL, and support count. It does not mention authentication or rate limits, but for a zero-parameter read operation this 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 with no wasted words. The core purpose is front-loaded, the protocol list is precise, and the output details are presented compactly.

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 no-parameter, no-output-schema tool, the description is complete. It tells the agent what the tool returns and includes enough field-level detail to know what to expect without needing an example or additional schema.

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

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

The tool takes zero parameters, so the description cannot add parameter-level meaning. The baseline for zero-parameter tools is 4, and the description appropriately focuses on output semantics instead.

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

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

The description states a specific action ('Get adoption stats') and a specific resource ('every protocol BotFriendly tracks'). It enumerates the exact protocols covered and the fields returned, making it impossible to confuse with the sibling tools focused on services, categories, and site checks.

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 makes the intended context clear: use this tool when you need protocol-level adoption statistics. It does not explicitly name alternatives or exclusions, but the sibling tools are clearly distinct in scope, so the usage context is unambiguous.

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 burden of explaining behavior. It does disclose that the tool returns details such as protocol support, URLs, auth method, billing, and metadata, which conveys a read-only lookup. However, it does not address error behavior, not-found cases, rate limits, or any authentication requirements for calling the 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 one efficient sentence that front-loads the core purpose and then lists the useful output categories. Every clause earns its place, and there is no redundant or vague 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?

For a simple single-parameter lookup with no output schema, the description provides a solid summary of what will be returned and when to use the tool. It could be slightly more complete by noting the exact response shape or what happens when a slug does not exist, but the essential information for selecting and invoking the tool is present.

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

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

Schema coverage is 100%, and the single slug parameter is already well-documented with examples in the schema. The description only adds that lookup is by slug, which adds marginal value beyond the structured input 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 gets full details for a specific service by slug, listing the included information types. This distinguishes it from siblings like search_services (searching) and list_categories (listing), making the tool's purpose 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 gives clear context: use this tool when you already have a specific service slug and need complete details. It does not explicitly name alternatives or exclusion criteria, but the 'by its slug' phrasing implies it is not for discovery or searching.

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 of behavioral disclosure. The verb 'List' clearly signals a read-only, non-destructive operation, and 'with descriptions and service counts' reveals what the response contains. It does not mention auth, rate limits, or pagination, but these are unlikely to be critical for a simple category list.

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

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

The description is a single sentence with no filler. It front-loads the action, names the resource, and states the included data. Every word earns its place.

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

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

With zero parameters and no output schema, the description is the sole specification of behavior. It fully defines the return content (categories with descriptions and service counts) and the scope (all categories). Nothing critical is missing for an agent to invoke and interpret the result.

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 the input schema provides no documentation burden. The baseline for zero-parameter tools is 4, and the description appropriately focuses on output content rather than parameter details. No additional parameter semantics are needed.

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 names a specific action ('List'), a specific resource ('all BotFriendly categories'), and the data included ('descriptions and service counts'). This clearly distinguishes it from siblings like get_service or search_services, which target individual services. An agent can tell exactly what this tool does.

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

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

The description does not explicitly state when to use this tool over siblings like get_service or search_services. Usage must be inferred from the listing purpose, and no exclusions or alternative routing are provided. For a simple read-only enumeration this is adequate but still implied rather than explicit.

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

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

With no annotations, the description carries the behavioral disclosure burden. It openly explains the promoted-listing behavior, including the promoted:true/ad:true markers and site-wide vs category ad placement. This is valuable hidden behavior an agent needs to interpret results correctly. It does not cover output shape, but the main behavioral surprise is well disclosed.

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

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

The description is three sentences, front-loaded with the action and resource, then filters, then ad behavior. It is compact and readable, though the protocol list in the second sentence partly duplicates the schema's enum descriptions.

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 search tool with 11 optional parameters and no output schema, the description covers the key ad-filtering behavior and general search purpose. However, it omits return-value details such as result fields, pagination size, max results, and when to use sibling tools like get_service or get_featured, leaving some ambiguity for agents.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only a high-level filter summary and repeats that promoted=false excludes ads, which the schema already documents. It does not meaningfully add semantics beyond the parameter 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 gives a specific verb and resource: 'Search the BotFriendly directory' for services, APIs, and tools. It enumerates filter dimensions such as category, protocol, and auth method, making the tool's role clear. It does not explicitly contrast with siblings like get_service or get_featured, but the search-oriented intent is reasonably distinguishable.

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

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

The description provides clear usage context: search the directory and filter by category, protocol, auth method, and more. It also gives a concrete practical tip: use promoted=false to exclude ads. It does not state when to prefer sibling tools or provide explicit exclusions, so it is not a full routing guide.

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 behavioral burden, and it does so well: it discloses that each interface URL must be on the service's own domain, that the URL is fetched during the call, that there is no review queue, and that the listing publishes immediately. It also explains icon fallback behavior. Some side effects such as duplicate handling and authentication are not covered, but the core behavioral contract is 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?

The description is three sentences with no wasted words. It front-loads the primary purpose and then adds only high-value behavioral details about review, fetching, publication, and icon handling. Nothing is redundant with the schema.

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

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

The description covers the core submission contract well: domain validation, live fetch, immediate publication, and icon fallback. But for a 16-parameter mutation tool with no output schema and no annotations, it leaves gaps: valid category slugs are not referenced, the optional boolean fields are left unexplained, and there is no indication of success or failure semantics. It is adequate for the happy path but not fully complete for confident use of all parameters.

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 real meaning to `url` by stating the own-domain and live-fetch constraints, and it clarifies the `icon_url`/`icon_base64` fallback. However, schema description coverage is only 63%, and the description does not compensate for the six parameters left as bare names, including `tags`, `accepts_mpp`, `accepts_x402`, `billing_model`, `has_mcp_server`, and `has_openapi_spec`.

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 opening sentence states a concrete action ('Submit a service') and a specific destination ('BotFriendly directory'), making the tool's purpose immediately clear. The no-review-queue and immediate-publication details further separate it from the query-oriented sibling tools like get_service and search_services.

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 establishes that this tool is for submitting a service and tells the agent what to expect: no review, live URL fetching, immediate publication. It does not explicitly name alternatives or exclusions, but the contrast with the read-only sibling tools makes the intended use unambiguous.

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