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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds real behavioral detail beyond them: matching is exact (no fuzzy/partial behavior), the full record is returned rather than a summary, and the call maps to GET /lookup.

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?

Three short sentences, front-loaded with the core verb and scope, ending with the return behavior. Slight redundancy with the schema on field values, but nothing that fails to earn its place.

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 only three parameters, a full annotation set, and a description that covers exact-match semantics and the shape of the return ('full records'), an agent has what it needs to call this correctly. The lack of an output schema is partly offset by the return statement.

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 description coverage is 100%, so field, value and entity are all documented in the schema, making the 3 baseline appropriate. The description reinforces the allowed field values and the cf_ custom-field convention but adds no new semantics, and it never mentions the entity parameter that the schema defines.

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?

States a concrete verb and resource — 'Exact-match lookup of contacts, companies or deals by one field' — and the qualifier 'exact-match' implicitly separates it from the fuzzy freshsales_search sibling. It stops short of naming that sibling or the freshsales_get_* tools explicitly, so the differentiation is inferable rather than stated.

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?

'e.g. a contact by email address' gives one concrete usage scenario, and 'Returns the full records' hints that this is the way to fetch a complete record by a known key. But there is no explicit guidance on when to prefer this over freshsales_search or freshsales_get_contact, and no stated exclusions.

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