normalise_entity_nameReduce a name to its comparable core with the legal form split out — a stable, deterministic grouping key. Reports every token removed and flags any obfuscation it strips (homoglyphs, invisible characters, digit-for-letter substitution). The normalisation the matching tools apply, exposed on its own.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name to normalise. | |
| type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral detail beyond these: it reports every token removed, flags obfuscation (homoglyphs, invisible characters, digit-for-letter substitution), and emphasizes determinism. This gives the agent insight into what to expect from the tool's output without contradicting any annotations.
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 sentences, zero filler. The first sentence front-loads the core purpose and output, the second details the reporting and obfuscation-flags behavior. Every clause earns its place, and the description is compact yet dense with useful information.
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 tool is simple (2 params, no output schema), and the description covers its behavior thoroughly: normalization, legal form split, reporting, obfuscation flagging, determinism, and its role in matching. Annotations handle safety. The only minor gap is not explaining the effect of the 'type' parameter on normalization, which could be ambiguous for person names vs company names. Still, overall the agent has enough to call it correctly.
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 50%, with only 'name' having a description ('The name to normalise.'). The description adds semantic context about splitting out the 'legal form', which implies the 'type' parameter (company vs person) matters for behavior, but it does not explicitly explain how 'type' affects normalisation. The enum is self-documenting in that it gives allowed values, but the description falls short of fully compensating for the uncovered schema parameter.
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 clear action ('Reduce a name to its comparable core'), the resource (name), and the outcome ('stable, deterministic grouping key'). It also distinguishes itself from the sibling matching tools by explicitly stating it is 'The normalisation the matching tools apply, exposed on its own.' This gives the agent a precise understanding of what the tool does and how it relates to compare/deduplicate/match.
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 implies usage as a building block for matching tools ('The normalisation the matching tools apply, exposed on its own') and mentions its role as a 'grouping key', which suggests when it would be useful (e.g., pre-grouping, understanding normalization behavior). It does not explicitly name alternatives or give when-not-to-use conditions, but the context is clear enough for an agent to infer when to call it versus the matching tools.
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.