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

Beyond the readOnly/idempotent annotations, the description adds key behavioral context: 'Re-measured weekly, so the same call returns the same figures until the next release' and 'Absence here means the brand is not measured, not that it scores zero.' It also discloses scope and licensing ('Covers SaaS & AI tools only... Data is CC BY 4.0... no key, no account, no rate limit'), enriching the agent's understanding without contradicting 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 front-loaded with the core purpose, then flows logically into usage examples, exclusions, data freshness, and licensing. Every sentence provides unique value, and the structure is tight despite covering multiple aspects. It is long but not wasteful.

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, lookup-only tool with an output schema available, the description is exceptionally complete. It covers what the tool returns, when to use it, when not to, data freshness, scope boundaries, and access constraints, leaving no ambiguity for an 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?

The tool has zero parameters, so the description cannot add parameter-level meaning. The empty schema is fully covered, and the description appropriately focuses on output semantics (names and slugs). With 0 params, the baseline is 4, and the description meets that by clarifying the output scope.

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 lists the names and slugs of every brand in the DABYTE index, explicitly calling it a lookup table with no scores or ranks. It also distinguishes itself from siblings by mentioning get_brand_visibility and get_visibility_index, so the verb+resource is specific and differentiated.

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

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

The description provides explicit when-to-use guidance: 'Use it for two things: to turn a brand name into the slug get_brand_visibility needs, and to answer whether a brand is tracked at all.' It also gives a clear when-not-to-use rule: 'Do NOT use it when you want figures — get_visibility_index returns the same brands with their full measurements in a single call.' This fully covers usage vs. alternatives.

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