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

Annotations already declare the tool read-only and non-destructive, and the description adds meaningful behavioral context beyond that: candidates carry `type` and canonical `slug`, slugs feed into specific downstream parameters, and bulk queries resolve independently with `limit` applying per query. No contradictions with 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 well-structured and front-loaded, with useful bullets and examples. It is slightly long due to enumerating many downstream tool/parameter names, but every sentence serves a purpose: one for definition, one for routing, one for bulk behavior.

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 tool with no output schema, the description covers input semantics, output candidate structure, downstream usage, when to use it, and alternative tools. Nothing an agent needs to call or consume this tool is missing.

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%, setting a baseline of 3. The description adds value beyond the schema by clarifying that a comma-separated `query` resolves each name independently in a single call and that `limit` applies per query, which is not explicit in 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 opens with a precise verb and resource: 'Resolve any named thing — person, company, place, or other entity — by free-text name in one union search.' It clearly distinguishes this from sibling resolve tools by stating it is a union search across entity types, and it explains the type/slug candidate structure.

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?

Excellent routing guidance: 'Use this first whenever you only have a name and don't know what kind of thing it names.' It explicitly names alternatives (`particle_person_resolve`, `particle_company_resolve`) and the conditions under which to choose them, plus bulk-resolution usage instructions.

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