Look up a contact by email, phone number, or name to retrieve full contact details, including all emails and phone numbers.
Look up a specific contact by email, phone number, or name. Returns full contact details including all emails and phone numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Email address, phone number, or name to look up |
Changes observed during successful MCP inspections.
v3.0.8Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the return contents ('full contact details including all emails and phone numbers'), which is useful, but says nothing about behavior when the identifier is not found, when a name matches multiple contacts, or any permission requirements.
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?
Two short sentences with zero filler; the action and accepted inputs are front-loaded and the return behavior follows immediately. Every clause earns 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?
For a one-parameter lookup with no output schema, the description does helpfully state the return shape, compensating for the missing output schema. However it omits not-found behavior and ambiguity handling for name matches, which are the main risks for an agent calling this tool.
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% for the single identifier parameter, and the description merely restates the same three accepted forms (email, phone number, name). Baseline 3 is correct when the schema already fully documents the parameter and the description adds no format or precedence detail.
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 specific verb (look up) and resource (a contact) plus the three accepted key types. It is clear what the tool does, but it never distinguishes itself from the overlapping siblings contacts_search and person_search, so an agent must guess which lookup path to take.
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 phrase 'a specific contact' faintly implies singular, exact retrieval versus a search, but there is no explicit when-to-use guidance, no exclusions, and no routing to contacts_search or person_search despite strong sibling overlap. Nothing tells the agent when this should be preferred over the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.