Normalize supplied person identity signals into a PDL-shaped enrichment record without inventing unavailable employment or location data. $0.28/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Full name | |
| No | Person email address | ||
| domain | No | Company domain | |
| company | No | Company or organization | |
| last_name | No | Last name | |
| first_name | No | First name | |
| linkedin_url | No | LinkedIn profile URL |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose meaningful behavior: it normalizes inputs, does not hallucinate missing employment or location data, and it exposes the $0.28/call cost. This goes beyond the schema and gives the agent useful expectations about output and side effects.
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 a single, front-loaded sentence that clearly names the purpose, includes a key limitation, and mentions cost. Every component adds information; there is no filler or schema repetition.
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 description gives a clear high-level contract and signal that results are PDL-shaped, but given 7 optional parameters and no output schema, it does not clarify how many signals are needed or what happens if input coverage is insufficient. An agent might reasonably ask whether calling with a single field or an empty payload is valid.
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, with each of the 7 parameters already having a simple description. The description's "person identity signals" phrase adds framing but does not explain parameter combinations, precedence, or minimum requirements beyond what the schema already provides.
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 names a specific verb, "Normalize supplied person identity signals into a PDL-shaped enrichment record," which clearly states the resource, action, and expected output. It also explicitly contrasts with data invention by saying it does not fabricate unavailable employment or location data, making the tool's scope distinguishable and actionable.
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?
A usage context is implied from the phrase "supplied person identity signals" — the tool should be used when the caller has person identity data and needs a normalized enrichment record. However, it gives no explicit guidance about when not to use this tool or how it compares to alternatives among a very large sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.