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

With no annotations provided, the description carries the full burden. It discloses that it returns both the authoritative company count and the nameable companies, and mentions that the basis difference is explained. This goes beyond a simple 'get companies' and alerts the agent to the dual output nature. However, it does not mention any operational constraints like rate limits, data freshness, or the effect of the limit parameter beyond what is in the schema.

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

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

The description is concise, with three sentences that front-load the unique value proposition. The use of all-caps 'PRO — THE INVERSION' is attention-grabbing but arguably excessive; still, it makes the core differentiator immediately apparent. The description wastes no words and clearly explains the purpose and distinctiveness, though the tone is somewhat promotional.

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

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

Given the tool's complexity (prospecting query with dual return types), the description provides a clear idea of what to expect: both the authoritative count and nameable companies, with the basis difference explained. It does not document pagination or the effect of the limit parameter, but the limit parameter is present in the schema. Since there is no output schema, the description adequately covers the return semantics, though it could mention how 'industry' filtering affects the count versus the named companies.

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 already describes 'slug' and 'industry' (50% coverage), and the limit parameter is self-explanatory. The description references the kind parameter via 'service, tool, standard' and clarifies the 'industry' usage via 'broken down by industry'. It does not add meaningful semantics for the 'limit' parameter, and the description does not provide syntax examples or deeper parameter relationships. Given the schema coverage is exactly 50% (not high, not low), the description adds some but not substantial value beyond the schema.

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

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

The description clearly states the tool's function: it runs stack-to-companies as opposed to the sibling tools' company-to-stack direction. It explicitly names the resources (service, tool, standard) and the output (companies showing demand, broken down by industry). This differentiates it from all sibling insights 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 provides a strong usage context: 'the prospecting query — who should I be selling this to'. It contrasts with siblings by stating every other tool runs company -> stack, implying this is for stack-first queries. It does not explicitly list when-not-to-use cases, but the clear directional inversion and prospecting label serve as a distinct guideline.

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