contacts_get_duplicate_contact

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

Annotations (readOnlyHint, idempotentHint, openWorldHint, destructiveHint) already convey that this is a safe, non-mutating read operation. The description adds no behavioral context beyond that—it doesn't explain what a 'duplicate' means, what the tool returns, or any edge cases. Since annotations carry the disclosure burden and the description adds nothing, it gets a low but not minimum score (no contradiction).

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?

While the description is extremely short, it is under-specified rather than concise. It lacks any structural elements like a purpose statement or usage hints. A single uninformative phrase does not earn credit for efficiency; it fails to convey necessary content.

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?

The tool has 3 optional parameters, no output schema, and a vague name. The description provides no information about what the tool returns, how it interprets 'duplicate', or when to call it. For a 3-parameter tool without an output schema, this description is completely inadequate for an agent to use correctly.

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 input schema has 100% coverage: the 'email' and 'number' parameters explain URL-encoding, and 'locationId' mentions its default. The description adds nothing that enhances parameter understanding, so the baseline of 3 (schema does the heavy lifting) is appropriate.

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 'Get Duplicate Contact' is a tautology that merely restates the tool name. It fails to explain what a 'duplicate contact' is or what the tool actually does beyond the name. There is no verb-resource detail or distinction from other contact tools like contacts_get_contact or contacts_search_contacts_advanced.

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 no guidance on when to use this tool versus alternatives. It does not mention scenarios where a duplicate contact lookup is appropriate, nor does it reference any sibling tools for comparison. An agent given this description cannot infer the intended use case.

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