Buba public catalogue and guides

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description does not contradict it. The description adds only that the profile is 'public' and the subject 'fictional', and says nothing about what happens with an unknown or malformed slug (error vs empty result).

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

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

A single front-loaded sentence with the action, scope and lookup key in order and zero filler. Nothing in the sentence could be cut without losing 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 one-parameter read tool with rich annotations and no output schema, the definition covers the essentials. The remaining gaps are minor: no statement of lookup-failure behavior and no indication of return shape, though the absence of an output schema lowers that expectation.

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 one required parameter with 0% description coverage, so the description carries the burden; it does add meaning by specifying the slug is a 'catalogue slug' rather than a name or numeric ID, which is genuinely useful. However it gives no format, casing, or lookup-failure guidance beyond that.

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: 'Read one ... public profile', scoped to a single item via 'using its catalogue slug'. The word 'one' implicitly contrasts with the enumerate-style list_companions sibling, though it never names that sibling explicitly.

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

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

Usage is only implied: the mention of 'catalogue slug' hints that the caller must already have a slug, presumably obtained from list_companions, but there is no explicit when-to-use, when-not, or named alternative. An agent must infer the routing between this and list_companions or search_docs.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered structurally. The description adds only that the result reflects 'current' state, i.e. pricing can change over time; it says nothing about auth requirements, caching, or what the returned flags look like.

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

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

A single front-loaded sentence with no filler. The two things checked (pricing availability, checkout openness) are stated in the order of importance.

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-arg, read-only tool this is close to sufficient, but there is no output schema, so the description is the only signal about return content and it stays at the level of 'availability' and 'open/closed'. An agent cannot tell whether it will get plan names, currency amounts, or a single boolean.

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 there is nothing for the description to explain beyond the implicit 'call with no arguments' contract. Baseline 4 applies.

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

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

The description names a specific verb and resource: check pricing availability and whether paid checkout is open. That is concrete enough to distinguish it from all four siblings (get_companion, get_site_info, list_companions, search_docs), though it never explicitly says so, and 'pricing availability' is slightly ambiguous about whether actual price figures are returned.

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 or when-not-to-use statement, and no alternatives are named. The link to checkout implies the agent should call this before attempting a paid flow, but that inference is left entirely to the reader.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds real value by scoping the returned content to offerings, audience, capabilities, limitations and links. It omits any note on return format or size, which is a minor remaining gap for a no-parameter read.

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

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

A single front-loaded sentence with no filler, listing the content categories efficiently. The phrase 'its adult audience' is the one element whose meaning is not self-evident and slightly muddies an otherwise tight sentence.

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

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

For a zero-parameter, non-destructive read with no output schema, the description supplies enough to know what comes back and when it is relevant. Naming the closest overlapping sibling (get_pricing) would have closed the last gap.

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 there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly implies no inputs 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 gives a concrete verb ('Read') and enumerates the content returned: offerings, audience, capabilities, limitations, links. That is much clearer than the title 'About Buba' alone. It does not explicitly distinguish itself from get_pricing, which also covers 'what Buba offers', so sibling differentiation is incomplete.

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 statement and no named alternatives. The intended role (an orientation/about lookup) is only implied by the mention of capabilities and limitations. An agent can infer it, but must compare against get_pricing and search_docs on its own.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that results are public profile links, which is useful given there is no output schema, but it omits pagination behavior (limit/cursor) that matters for a listing 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?

A single well-formed sentence with the action front-loaded and no filler. It could be slightly sharper by separating discovery guidance from return-value description.

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

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

For a 5-parameter listing tool with no output schema and low schema coverage, the description covers purpose and rough return type but leaves pagination and filter-combination semantics unexplained. Adequate but with clear 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 only 20% (only cursor is documented), so the description has to compensate. It names the filterable dimensions (interests, style, category), which maps loosely onto query/style/category, but it says nothing about limit or how multiple filters combine, leaving real ambiguity.

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?

States a specific verb (find/browse) and resource (fictional adult AI companions) and lists the filter dimensions. It implicitly distinguishes itself from get_companion by being a filtered discovery/list operation rather than a single-record fetch, though it never names the sibling.

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

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

Usage is only implied: 'find ... by interests, style or category' suggests discovery browsing, but there is no explicit when-to-use versus get_companion (detail) or search_docs, and no statement of exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds two useful pieces of context beyond that: the corpus is limited to "published" documentation, and results come back as passages plus links. It says nothing about ranking, result count behavior, or empty-result handling.

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

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

A single front-loaded sentence with no filler, and the scope of the corpus is stated up front. It is efficient, though so terse that the space saved is not spent on the missing parameter and 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?

For a two-parameter, read-only search tool with no output schema, the description covers the essentials of what is searched and roughly what comes back. It is incomplete on the two things an agent actually needs to call it well: query formulation and the limit parameter's effect on results.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining the two parameters, and it explains neither. It never mentions what the query string should contain, nor that a limit exists, defaults to 5, or caps at 20. An agent learns only that the search is over Buba documentation.

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

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

The description uses a specific verb ("Find") and names the resource precisely: "source passages and links in Buba's published product guides, pricing and safety documentation." That is clear enough to separate it from the get_* siblings, which appear to fetch a single artifact rather than search across documents, though it never names those siblings explicitly.

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

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

Usage is only implied: "Find source passages and links" suggests a discovery/lookup task, and the sibling names (get_pricing, get_site_info) hint that this is the search path rather than the direct-fetch path. There is no explicit statement of when to prefer this over get_pricing for pricing questions, and no exclusions or prerequisites.

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