Search RD Station CRM Contacts

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

The description discloses the output format ('one line per contact: name, id, primary email, primary phone, job title') and explains how the returned id flows into rdcrm_get_contact for full details. While readOnlyHint is already declared in annotations, the description adds value by explaining the line-per-contact output structure and the linking behavior with deals. It doesn't cover pagination behavior details, but the annotations already cover the safety profile.

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 compact and front-loaded: a single clear sentence stating the purpose, followed by an output-format sentence and two concise usage guidance sentences. Every line earns its place with zero waste or redundancy.

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 read-only search tool with 100% schema coverage, five well-documented optional parameters, and clear output-format disclosure, the description is largely complete. It also gives the usage context and alternative-tool pointers. Minor gap: pagination semantics (page/limit interplay) aren't explained in the description, though schema covers the parameters themselves. No output schema exists to offload return-value explanation, but the in-description line format compensates.

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%, so all 5 parameters are documented in the schema. The description adds marginal value by mapping query to partial-name and email/phone to exact-match, which reinforces the schema descriptions but doesn't add meaningfully beyond them. The baseline 3 is appropriate given full schema coverage does the heavy lifting.

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 states a specific verb+resource ('Search contacts in RD Station CRM') and explicitly defines the search semantics ('by partial name, exact email or exact phone'). It clearly distinguishes itself from siblings by noting the use of the returned id with rdcrm_get_contact, differentiating the search-and-list function from the full-detail and upsert operations.

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 explicit 'Use when:' guidance with concrete examples ('find Maria's contact', 'do we have someone with email x@y.com?') and explicit 'Don't use when:' exclusions pointing to an alternative tool (rdcrm_upsert_contact for create/edit). This meets the highest bar for usage differentiation.

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