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

The readOnlyHint and openWorldHint annotations already signal a non-mutating, externally informed tool, and the description adds substantial behavioral context: it uses live public web evidence, cites every claim, scores roles rather than individuals, and returns no contact details. The 'live public web evidence' claim also usefully explains the idempotentHint: false annotation without contradicting any annotation.

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 tightly structured: the first sentence front-loads the core scoring mechanics and threshold, the second explains the evidence base, and the final sentences cover customization and privacy constraints. Every sentence earns its place, with no filler or repetition of the tool name.

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 an output schema, detailed parameter descriptions, and strong annotations, the description is nearly complete for a scoring tool. It covers the scoring axes, threshold, evidence source, citation behavior, customization options, and privacy boundary. The only notable gap is that it does not explicitly state what happens when neither client_id nor icp_description supplies an ICP, which could matter for an agent deciding whether a valid call requires one of them.

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 provides 100% parameter coverage, so the baseline is 3. The description adds genuine meaning beyond the schema by explaining how client_id can supply the ICP and make icp_description optional, and how our_company_name, our_domain, and our_differentiators curate the score toward 'how YOU win.' It does not add much for vertical or ideal_tech_stack, but the schema descriptions are already 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 opens with a specific verb and object — 'Score a company against your ICP' — and immediately names the five weighted axes, the 1-10 scale, and the 7+/10 pursue threshold. It also sets clear boundaries versus sibling tools by noting it 'Judges roles, never individuals' and 'returns no contact details,' making its purpose and distinct scope unmistakable.

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 for when the tool applies: scoring a prospect company against your ICP using live public web evidence, and curating the score with your own company details or a Klarix client_id. It does not explicitly name alternative sibling tools or state when not to use this tool, so it stops short of full routing guidance, but no exclusions are needed for the core use case.

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