deduplicate_entity_namesCluster up to 250 names into groups that are the same entity — the work behind a CRM merge or supplier-list cleanup. Grouped by distinctive words, not compared exhaustively; the response reports how many comparisons ran. If one word dominates the list, "truncated" is true (clustering incomplete) — split and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| names | Yes | ||
| threshold | No | Defaults to 0.85. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals the algorithmic approach ('grouped by distinctive words'), the output signal (comparison count), and the truncation failure mode with a retry instruction. This is substantive behavioral disclosure that helps the agent anticipate edge cases.
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 dense sentences with no filler. The opening sentence establishes purpose, the second gives algorithmic context, and the third provides a critical edge-case instruction. 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?
The description covers purpose, scale limit, algorithm, output signals, and retry guidance, which is strong for a tool with no output schema. It leaves some ambiguity about the exact shape of returned groups and how `type` changes matching, but the essential operational information is present.
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 only 33%, and the description does not compensate by explaining the `type` or `threshold` parameters. It mentions the 250-name limit, which is already in the schema, but gives no guidance on how person/company selection or threshold values affect clustering behavior.
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 action ('Cluster up to 250 names into groups that are the same entity') with a clear resource and outcome. It also sets it apart from sibling tools by emphasizing batch clustering rather than pairwise comparison or normalization.
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?
It provides concrete contexts such as CRM merge or supplier-list cleanup, and implies when the tool is appropriate via 'not compared exhaustively.' It stops short of explicitly naming sibling alternatives like compare_entity_names or match_entity_name, so it earns 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools map cleanly to a distinct action and resource: single-URL lookup, batch triage, watch/pull lifecycle, and the entity-name operations are each clearly separated. The only likely confusion is between check_ai_crawler_access and verify_ai_crawler, but the descriptions draw that boundary well.
Tool names overwhelmingly follow a verb_noun convention such as calculate_gst, verify_email_address, and normalise_entity_name. The non-verb award_pay_rate and the slightly awkward total_invoice and pull_ai_crawler_watch are minor deviations from an otherwise consistent pattern.
Fourteen tools sits comfortably in the well-scoped range, and each cluster earns its place: entity matching, Australian compliance, email verification, and AI crawler access all have distinct tool groupings. Nothing feels redundant, and the count reflects the server's broad verification purpose without bloat.
The surface covers the core verification workflows well, including batch and watch variants for crawler access and a full set of entity-name operations. The main gap is that the server name promises routing but the tools mostly verify and triage rather than actively route; minor lifecycle niceties like unwatching are also absent.