Verify addresses, email addresses, and phone numbers with confidence scores.
Scored across 11 tools
Each tool has a clearly distinct purpose: address retrieval, verification (single and batch), and policy management. The descriptions explicitly cross-reference each other (e.g., retrieve_address vs verify_address) to avoid confusion.
Most tool names follow a verb_noun pattern (list_policies, retrieve_address, verify_address, verify_email, verify_phone), but show_policy and verify_contact deviate slightly: show_policy uses a different verb, and verify_contact covers multiple fields rather than a single noun. Still, the pattern is largely consistent and readable.
With 11 tools, the set is well-scoped: it covers core verification operations (address, email, phone, contact) for both single and batch modes, plus policy management. No redundant tools, and each earns its place.
The surface covers verification and retrieval with both single and batch operations, and includes policy listing and detail. However, there is no tool to create, update, or delete policies (only list and show), which is a minor gap for policy management.
List available decisioning policies (strict, shipping, standard, permissive) with their thresholds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful detail that results include thresholds, but does not describe ordering, return format, or any other behavioral expectations; with zero parameters, this is acceptable but not exceptional.
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 states exactly what the tool does and what information it returns. Every word earns its place, with no filler or 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?
For a zero-parameter, read-only list tool without an output schema, this description is complete: it names the result domain, the specific policy categories, and the included threshold data. No critical information an agent needs to invoke it correctly is missing.
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 tool has no parameters, so the description does not need to explain parameter behavior. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the output rather than inputs.
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 uses a clear verb-resource pairing ('List available decisioning policies') and further specifies the scope by naming the exact policy types and what is included (thresholds). This distinguishes it from siblings like show_policy, which presumably displays a single policy rather than the available set.
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 this is the tool to use when you need an overview of all available policies and their thresholds, but it does not explicitly discuss when to use show_policy instead. The distinction is inferable from the sibling name but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a suggestion id from address.suggestions into its full cleansed address components (organisation, sub-building, number, street, city, province, postcode, country). Use this when you need the address itself — to fill a form or show a confirmation — rather than a decision; to verify a chosen suggestion instead, pass 'suggestion_id' to verify_address. CONSUMES A LOQATE CREDIT per call, so resolve only the one suggestion the user chose. The result is reference data, NOT a verification. Requires a Loqate API key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header | |
| suggestion_id | Yes | Id of a suggestion previously returned in address.suggestions. CONSUMES A LOQATE CREDIT. Ids are not stable over time; a stale one returns SUGGESTION_NOT_FOUND and you must search again rather than retry |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds crucial non-obvious behavior beyond the annotations: each call consumes a Loqate credit, the result is reference data not verification, and IDs can become stale. These details are not captured by readOnlyHint or openWorldHint, so the description carries meaningful extra weight. No contradiction with 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?
Four sentences carry routing, cost, and semantics without filler, and the first sentence front-loads the core action. The closing 'Requires a Loqate API key' is slightly redundant with the schema's key parameter, so it is not a perfect 5.
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 two-parameter tool with a fully documented schema, the description covers what it returns, when to use it, cost side effects, and verification semantics. The absent output schema is partially compensated by the explicit component list; the only minor gap is not clarifying the key-configuration exception mentioned in the schema.
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 already describes both parameters with 100% coverage, including key optionality and suggestion_id staleness. The main description mostly restates that suggestion_id comes from address.suggestions and mentions the API key, so it adds little beyond the schema; a baseline of 3 is appropriate.
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 'Resolve' plus the exact resource ('suggestion id from address.suggestions') and enumerates the returned components. It also explicitly contrasts itself with verify_address, making it easy to distinguish from siblings.
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?
Explicitly says 'Use this when you need the address itself — to fill a form or show a confirmation — rather than a decision' and tells the agent to pass 'suggestion_id' to verify_address instead. It also instructs to resolve only the one chosen suggestion because of the credit cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show full details for a specific decisioning policy.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Policy name: strict shipping standard or permissive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds 'full details' but provides little behavioral context beyond that, such as whether the policy must already exist or how missing names are handled. No contradiction with annotations exists.
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, purpose-focused sentence with no filler. Every word contributes to clarifying the tool's function.
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 simple, read-only, single-parameter tool with rich schema coverage and an informative annotation, the description is largely sufficient. It could be slightly more explicit about how to discover a valid policy name, but the sibling list_policies and parameter description cover that gap well enough.
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%, and the parameter description already explains that 'name' is a policy name with examples ('strict shipping standard or permissive'). The main description does not add additional parameter meaning, so the baseline of 3 applies.
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 uses a specific verb ('Show') and a clear resource ('full details for a specific decisioning policy'). It clearly differentiates from the sibling list_policies by emphasizing 'specific' rather than a listing operation.
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?
Usage context is implied: use this tool when you need full details for one known policy, while list_policies likely covers enumeration. However, the description does not explicitly state when to prefer this over siblings or mention any prerequisites, so the guidance remains inferential rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an address against Loqate's global reference data. Returns a confidence score (0-1), verification status, and a policy-driven accept/review/reject recommendation. Set 'suggest' to also get alternative addresses suggested by Loqate whenever the address does not clear the policy; offer them to the user and verify the chosen one in a second call before treating it as good. Suggestions require a separately licensed Loqate feature enabled on the account — without it, verification still succeeds and the problem is reported in suggestions.error. Requires a Loqate API key — pass it via the 'key' field (get one at account.loqate.com).
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Your own identifier for this record, echoed back by Loqate | |
| key | No | Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header (get one at account.loqate.com) | |
| policy | No | Policy name: strict shipping standard (default) or permissive | |
| address | No | Full address string (free-form — use this OR structured fields below) | |
| contact | No | Contact name for the delivery | |
| country | No | ISO 2-letter country code (e.g. US GB DE) | |
| options | No | Loqate API options as nested JSON, e.g. {"ServerOptions": {"FieldStatus": "true"}}. Dot notation is equivalent: {"ServerOptions.FieldStatus": "true"}. Pass GeoCode here as a boolean — it is sent at the request root where Loqate expects it. In-Options booleans (Certify Version Enhance Deceased Goneaways) take JSON booleans; ServerOptions values (e.g. OutputCasing DefaultCountry) are strings. Set ServerOptions.FieldStatus to "true" to get the changes list | |
| premise | No | Premise or house number | |
| suggest | No | When true, look up alternative addresses suggested by Loqate and return them in the result as suggestions. Requires the Loqate address-suggestion feature to be enabled on the account (licensed separately from verification) — without it, verification still succeeds and the reason appears in suggestions.error. The lookup runs when the address is not accepted (review or reject) OR when it is accepted below the confidence floor (see suggest_below) — a policy accepts from its own minimum, so an accepted address is not necessarily a confident one. Address-only; off by default | |
| surname | No | Recipient's last name | |
| address2 | No | Second address line | |
| address3 | No | Third address line | |
| address4 | No | Fourth address line | |
| address5 | No | Fifth address line | |
| address6 | No | Sixth address line | |
| address7 | No | Seventh address line | |
| address8 | No | Eighth address line | |
| building | No | Building name | |
| forename | No | Recipient's first name | |
| function | No | Contact's job title or function | |
| latitude | No | Latitude, for a reverse geocode | |
| locality | No | City or town | |
| post_box | No | PO box | |
| postcode | No | Postal or ZIP code | |
| full_name | No | Recipient's full name | |
| longitude | No | Longitude, for a reverse geocode | |
| admin_area | No | State or province | |
| department | No | Department within the organisation | |
| verify_key | No | Custom address verification API key (overrides LOQATE_VERIFY_KEY env var) | |
| verify_url | No | Custom address verification endpoint URL (overrides LOQATE_VERIFY_URL env var) | |
| middle_name | No | Recipient's middle name | |
| organization | No | Company or organisation name | |
| sub_building | No | Sub-building (e.g. flat, apartment or suite) | |
| thoroughfare | No | Street name | |
| suggest_below | No | Confidence floor for suggestions (0-1). An accepted address scoring below it still gets suggestions — policies accept from their own minimum, so an accepted address is not necessarily a confident one. Omit to use the policy value (standard 0.85); 0 disables the floor so only review/reject trigger a lookup | |
| suggest_limit | No | Maximum number of suggestions to return (1-10, default 5). Requires suggest | |
| suggestion_id | No | Id of a suggestion previously returned in address.suggestions. The tool retrieves that address's cleansed components from Loqate and verifies those, which is how you confirm a suggestion the user chose. Use INSTEAD OF address, not alongside it. CONSUMES A LOQATE CREDIT — pass one id, for the one suggestion that was chosen, never several. Ids are not stable over time; a stale one returns SUGGESTION_NOT_FOUND and you must search again rather than retry | |
| detect_country | No | When true and no country is supplied, guess the country from the address and flag the guess in the result (country_guessed). Address-only; off by default | |
| delivery_address | No | Full delivery address | |
| delivery_address1 | No | Delivery address line 1 | |
| delivery_address2 | No | Delivery address line 2 | |
| delivery_address3 | No | Delivery address line 3 | |
| delivery_address4 | No | Delivery address line 4 | |
| delivery_address5 | No | Delivery address line 5 | |
| delivery_address6 | No | Delivery address line 6 | |
| delivery_address7 | No | Delivery address line 7 | |
| delivery_address8 | No | Delivery address line 8 | |
| dependent_locality | No | Dependent locality (e.g. neighbourhood) | |
| sub_building_floor | No | Floor | |
| dependent_thoroughfare | No | Dependent street name | |
| sub_administrative_area | No | Sub administrative area (e.g. county) | |
| double_dependent_locality | No | Double dependent locality | |
| super_administrative_area | No | Super administrative area |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds substantive behavioral context beyond that: an API key requirement, a separately licensed feature whose absence does not fail verification but surfaces in suggestions.error, and the two-call confirmation workflow. It still doesn't mention rate limits, credit cost, or latency for the main verification path.
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?
Four sentences, front-loaded with purpose then output then the suggest caveat then the auth requirement — no filler. There is some verbatim overlap with the 'suggest' parameter description, which is the only real inefficiency.
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?
With 53 parameters and no output schema, the description carries a heavy load; it compensates by naming the returned fields (confidence score, verification status, recommendation) and the error channel for suggestions, plus the auth path. It stops short of describing the overall result structure or the policy field semantics in depth, so it is strong but not exhaustive.
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 the baseline is 3; the description earns an increment by tying the parameters together conceptually — the policy-driven accept/review/reject model, the 'suggest' lookup trigger, and the workflow requirement that a chosen suggestion be verified in a second call rather than trusted directly. Much of the suggest licensing text is duplicated from the schema, which limits the gain.
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+resource ('Verify an address against Loqate's global reference data') and immediately characterizes the output (confidence score, status, accept/review/reject recommendation). The singular scope is distinguishable from the batch sibling, and the suggestion/second-call mechanic makes the tool's role unambiguous.
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?
Gives clear conditional guidance for the 'suggest' path (when to look up alternatives, and that the chosen one must be verified in a second call before being treated as good), plus the licensing precondition. It does not explicitly route between verify_address, verify_address_batch, and retrieve_address, so the sibling-selection guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify up to 100 addresses in one call. Up to 100 records per call; the results array is in submission order and each entry carries its input index, so results can be zipped back onto rows without relying on order. One bad record fails only itself — it carries an error while the rest are verified. Suggestions are not available in batch. Records are grouped by country before being sent, as Loqate recommends, so the cost is one upstream call per distinct country in the batch rather than one per call. Set detect_country to guess the country of records that do not supply one — detection runs per record, before grouping, so a mixed batch still sends each group with the right default. Requires a Loqate API key — pass it via the 'key' field.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header | |
| policy | No | Policy name: strict shipping standard (default) or permissive | |
| options | No | Loqate API options as nested JSON, applied to every record in the batch | |
| addresses | Yes | Addresses to verify, up to 100. Results are returned in the same order, each carrying its input index | |
| verify_key | No | Custom address verification API key | |
| verify_url | No | Custom address verification endpoint URL | |
| detect_country | No | When true, guess the country of any record that does not supply one, from its address text, and flag the guess in that record's result. Records are then grouped by their detected country, so a mixed-country batch each gets the right default. Off by default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description supplies the real behavioral payload: results in submission order with an input index for zipping, per-record error isolation ('one bad record fails only itself'), the absence of suggestions, country-based grouping that changes upstream call cost to one per distinct country, and detection ordering relative to grouping.
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?
Front-loaded with the core capability and largely waste-free, but the country-grouping/cost sentence is dense and slightly overlaps with the detect_country explanation. Most sentences earn their place; a little compression is possible.
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?
With no output schema, the description carries the return-value burden and does so: it describes the results array shape, ordering guarantee, embedded input index, and per-record error field. For a nested, 7-parameter batch tool this is complete enough to call 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 100%, so the baseline is 3, but the description adds genuine meaning: it explains detect_country's per-record-then-grouping ordering and the key field's role as the Loqate credential. It doesn't add anything for policy, options, verify_key or verify_url beyond what the schema already says.
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 ('Verify') and resource ('addresses') with the batch scope ('up to 100 addresses in one call'), which cleanly distinguishes it from the sibling verify_address. An agent can tell exactly what this tool does without opening the schema.
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?
Conveys when this tool applies (bulk verification, up to 100 records) and notes a key limitation versus the single-record path ('Suggestions are not available in batch'), which routes an agent that needs suggestions elsewhere. It never explicitly names verify_address as the alternative for single or suggestion-bearing lookups, so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify address, email, and/or phone together. Returns individual results plus an overall recommendation (most conservative of all provided fields). Set 'suggest' to also get alternative addresses suggested by Loqate whenever the address does not clear the policy; offer them to the user and verify the chosen one in a second call before treating it as good. Suggestions require a separately licensed Loqate feature enabled on the account — without it, verification still succeeds and the problem is reported in suggestions.error. Requires a Loqate API key — pass it via the 'key' field.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Your own identifier for this record, echoed back by Loqate | |
| key | No | Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header | |
| No | Email address to verify | ||
| phone | No | Phone number to verify | |
| policy | No | Policy name: strict shipping standard (default) or permissive | |
| address | No | Full address string | |
| contact | No | Contact name for the delivery | |
| country | No | ISO 2-letter country code | |
| options | No | Loqate API options as nested JSON, e.g. {"ServerOptions": {"FieldStatus": "true"}}. Dot notation is equivalent: {"ServerOptions.FieldStatus": "true"}. Pass GeoCode here as a boolean — it is sent at the request root where Loqate expects it. In-Options booleans (Certify Version Enhance Deceased Goneaways) take JSON booleans; ServerOptions values (e.g. OutputCasing DefaultCountry) are strings. Set ServerOptions.FieldStatus to "true" to get the changes list | |
| premise | No | Premise or house number | |
| suggest | No | When true, look up alternative addresses suggested by Loqate and return them under address.suggestions. Requires the Loqate address-suggestion feature to be enabled on the account (licensed separately from verification). The lookup runs when the address is not accepted (review or reject) OR when it is accepted below the confidence floor (see suggest_below). Address-only — does not affect phone or email; off by default | |
| surname | No | Recipient's last name | |
| address2 | No | Second address line | |
| address3 | No | Third address line | |
| address4 | No | Fourth address line | |
| address5 | No | Fifth address line | |
| address6 | No | Sixth address line | |
| address7 | No | Seventh address line | |
| address8 | No | Eighth address line | |
| building | No | Building name | |
| forename | No | Recipient's first name | |
| function | No | Contact's job title or function | |
| latitude | No | Latitude, for a reverse geocode | |
| locality | No | City or town | |
| post_box | No | PO box | |
| postcode | No | Postal or ZIP code | |
| full_name | No | Recipient's full name | |
| longitude | No | Longitude, for a reverse geocode | |
| admin_area | No | State or province | |
| department | No | Department within the organisation | |
| verify_key | No | Custom address verification API key (overrides LOQATE_VERIFY_KEY env var) | |
| verify_url | No | Custom address verification endpoint URL (overrides LOQATE_VERIFY_URL env var) | |
| middle_name | No | Recipient's middle name | |
| organization | No | Company or organisation name | |
| sub_building | No | Sub-building (e.g. flat, apartment or suite) | |
| thoroughfare | No | Street name | |
| suggest_below | No | Confidence floor for suggestions (0-1). An accepted address scoring below it still gets suggestions. Omit to use the policy value (standard 0.85); 0 disables the floor. Address-only | |
| suggest_limit | No | Maximum number of suggestions to return (1-10, default 5). Requires suggest | |
| suggestion_id | No | Id of a suggestion previously returned in address.suggestions. The tool retrieves that address's cleansed components from Loqate and verifies those, which is how you confirm a suggestion the user chose. Use INSTEAD OF address, not alongside it. CONSUMES A LOQATE CREDIT — pass one id, for the one suggestion that was chosen, never several. Ids are not stable over time; a stale one returns SUGGESTION_NOT_FOUND and you must search again rather than retry | |
| detect_country | No | When true and no country is supplied, guess the country from the address and flag the guess in the result (country_guessed). Address-only — does not affect phone or email; off by default | |
| delivery_address | No | Full delivery address | |
| delivery_address1 | No | Delivery address line 1 | |
| delivery_address2 | No | Delivery address line 2 | |
| delivery_address3 | No | Delivery address line 3 | |
| delivery_address4 | No | Delivery address line 4 | |
| delivery_address5 | No | Delivery address line 5 | |
| delivery_address6 | No | Delivery address line 6 | |
| delivery_address7 | No | Delivery address line 7 | |
| delivery_address8 | No | Delivery address line 8 | |
| dependent_locality | No | Dependent locality (e.g. neighbourhood) | |
| sub_building_floor | No | Floor | |
| dependent_thoroughfare | No | Dependent street name | |
| sub_administrative_area | No | Sub administrative area (e.g. county) | |
| double_dependent_locality | No | Double dependent locality | |
| super_administrative_area | No | Super administrative area |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint, and the description goes well beyond them: it discloses credit consumption ('CONSUMES A LOQATE CREDIT'), the stale-id failure mode (SUGGESTION_NOT_FOUND, and that retrying is wrong), the separately licensed Loqate feature requirement and its failure path (reported in suggestions.error, verification still succeeds), and the auth requirement (key field / Authorization header). These are exactly the operational traits an agent cannot infer from structured fields.
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 front-loads the core purpose and then walks through the suggest/licensing/error conditions in a logical order, with no filler. Sentences are long and dense for a niche feature (suggestions), but each clause carries real operational information rather than restating the schema.
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 55-parameter tool with no output schema, the description supplies the essentials: what is returned, how the overall recommendation is computed, where suggestions surface (address.suggestions), auth and licensing requirements, and one error case. It stops short of detailing the full result structure (e.g. what 'individual results' contain), so an agent must infer some return shape.
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%, so the baseline is 3. The description still adds value above the schema by explaining cross-parameter semantics: the 'overall recommendation' is derived as the most conservative across the provided fields, 'suggest' is address-only, and suggestion_id must be used instead of address and only once. That is meaningful guidance beyond the per-field descriptions.
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 precise verb (Verify) and resource set (address, email, and/or phone) and adds the key differentiator 'together', which separates it from the single-field siblings verify_address, verify_email, and verify_phone. It also states what comes back (individual results plus an overall recommendation that is the most conservative of the provided fields), so an agent can identify the tool and its output shape without opening the schema.
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?
There is useful conditional guidance for the suggest workflow ('offer them to the user and verify the chosen one in a second call') and for suggestion_id ('Use INSTEAD OF address, not alongside it'). However, nothing tells the agent when to pick verify_contact over verify_address/verify_email/verify_phone (e.g. only reach for this when fields must be judged together). Tool-selection guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify up to 100 contacts in one call, each with any combination of address, email and phone, returning an overall recommendation per contact. Results are in submission order and each carries its input index. One bad record fails only itself, and a field that cannot be verified does not remove the contact — the overall recommendation is drawn from whichever fields were checked. The three types run concurrently, so a full batch is paced by email at roughly 7 seconds per 100. Requires a Loqate API key — pass it via the 'key' field.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header | |
| policy | No | Policy name: strict shipping standard (default) or permissive | |
| options | No | Loqate API options as nested JSON, applied to every address in the batch | |
| contacts | Yes | Contacts to verify, up to 100. Results are returned in the same order, each carrying its input index | |
| verify_key | No | Custom address verification API key | |
| verify_url | No | Custom address verification endpoint URL | |
| detect_country | No | When true, guess the country of any contact whose address does not supply one and flag the guess in that contact's address result. Off by default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond readOnlyHint/openWorldHint by disclosing batch-specific traits: one bad record fails only itself, unverifiable fields do not drop a contact, the overall recommendation aggregates only checked fields, submission order/indexing, and a concrete concurrency/pacing figure (~7s per 100, email-bound). The auth requirement is also restated in plain language.
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?
Front-loads the batch scope, then layers failure semantics, partial-verification rules, timing, and auth in five tight sentences with no filler or repetition of the annotations.
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 nested-object batch tool with no output schema, the description covers return ordering, per-record indexing, and the per-contact recommendation, which is enough to call it correctly. It stops short of describing the recommendation's possible values or how policy/options influence results, but the essentials are 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 coverage is 100%, so baseline would be 3; the description adds task-level meaning by telling the caller to pass the Loqate key via the 'key' field, and re-anchoring the 100-item cap and index behavior in operational terms. It does not, however, explain policy/options/detect_country semantics beyond what the schema already carries.
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 (verify), resource (contacts), and scope (up to 100 per call, mixing address/email/phone), plus the return shape (an overall recommendation per contact). An agent can distinguish it from verify_contact and from the per-channel batch tools without opening a schema.
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 batching scope and per-record error isolation imply the right context (many contacts, tolerate partial failures), but the description never explicitly says when to prefer this over verify_contact or the single-type batch tools, nor states prerequisites beyond the API key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an email address via Loqate. Returns confidence, risk level, and accept/review/reject recommendation. Requires a Loqate API key — pass it via the 'key' field.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header | |
| Yes | Email address to verify | ||
| policy | No | Policy name: strict shipping standard (default) or permissive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful behavioral context beyond that: it returns confidence/risk/recommendation and requires a Loqate API key. It slightly oversimplifies by saying a key is required when the schema notes it can be server-configured or supplied via bearer token, but this is not a contradiction of the 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 carry the entire message with no filler. The purpose is front-loaded, the return values are stated compactly, and the API key requirement is placed at the end as an actionable note. Every sentence 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 simple read-only verification tool, the description covers the core purpose, output summary, and authentication requirement. There is no output schema, so mentioning the return fields is helpful. It could be more complete by noting error behavior or the conditional nature of the API key, but the schema already covers parameter-level details.
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%, so each parameter is already documented. The description reinforces that the API key goes in the 'key' field, but it adds no substantial meaning beyond the schema and does not elaborate on the policy parameter or result interpretation.
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 ('Verify') applied to a specific resource ('an email address') and names the provider ('Loqate'). It also previews the result ('confidence, risk level, and accept/review/reject recommendation'), which makes the tool's purpose unmistakable and distinguishes it from sibling verification tools like verify_address, verify_phone, and verify_contact.
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 clearly establishes that this tool is for verifying email addresses, so the usage context is clear. However, it does not explicitly call out when not to use it or direct the agent to sibling tools such as verify_address or verify_phone, so it stops short of full alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify up to 100 email addresses in one call. Up to 100 records per call; the results array is in submission order and each entry carries its input index, so results can be zipped back onto rows without relying on order. One bad record fails only itself — it carries an error while the rest are verified. Suggestions are not available in batch. The batch endpoint returns less detail than single verification: risk, complainer and reason are absent, though the accept/review/reject recommendation and the disposable-mailbox flag are identical. Requires a Loqate API key — pass it via the 'key' field.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header | |
| emails | Yes | Email addresses to verify, up to 100. Results are returned in the same order, each carrying its input index | |
| policy | No | Policy name: strict shipping standard (default) or permissive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the readOnlyHint/openWorldHint annotations: per-record partial failure ('one bad record fails only itself'), the auth requirement via 'key', the submission-order/index guarantee, the absence of suggestions, and the truncated field set (risk, complainer, reason absent). These are exactly the traits an agent cannot infer from the 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?
Front-loads the core capability and packs important behavioral facts into a compact block, but the opening two clauses are redundant ('Verify up to 100 email addresses in one call. Up to 100 records per call'). Otherwise every sentence carries 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?
With no output schema, the description compensates by naming the returned recommendation and disposable flag and listing the omitted fields, plus failure and auth semantics. An agent has everything needed to call it correctly and interpret partial results.
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 three parameters (key, emails, policy) are already documented, and the ordering/index language for 'emails' plus the key requirement largely duplicate the schema's own descriptions. The 'policy' parameter is never addressed in the description, so no meaningful semantics are added beyond the structured fields; baseline 3 applies.
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 (verify), resource (email addresses) and scope (up to 100 in one call), which cleanly separates it from the singular verify_email and the other verify_*_batch siblings. An agent knows exactly what operation it is choosing without opening a schema.
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?
Gives clear context for batch use and compares against single verification ('batch returns less detail than single verification'), which implies the batch/single tradeoff. It never states an explicit cut-off or 'use verify_email instead when...' rule, so the routing guidance is inferential rather than prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a phone number via Loqate. Returns confidence, number type, carrier, and accept/review/reject recommendation. Requires a Loqate API key — pass it via the 'key' field.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header | |
| phone | Yes | Phone number (E.164 format preferred e.g. +442071234567) | |
| policy | No | Policy name: strict shipping standard (default) or permissive | |
| country | No | ISO 2-letter country code (helps with parsing if no country prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so safety is covered. The description adds meaningful behavioral context on top: it discloses that the tool calls Loqate, requires an API key, and returns specific outputs (confidence, number type, carrier, and a recommendation). This is valuable information beyond the 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?
The description is two sentences, front-loads the primary action, and packs in return values plus authentication requirements without any filler. Every sentence contributes 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?
For a tool with no output schema, the description adequately explains what the tool returns and the key prerequisite (API key). Optional parameters and defaults are left to the schema, which is acceptable since the schema is fully descriptive. The main gap is lack of guidance on when to prefer this tool over sibling verification tools, but that is more of a usage-consideration gap than a completeness gap for making a successful call.
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%, so the structured schema already documents all parameters thoroughly. The description adds a small clarification about passing the API key via the 'key' field, but it does not substantially enrich the meaning of parameters such as policy or country beyond what the schema 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 clearly states the tool's function: verifying a phone number via Loqate, and lists the key outputs (confidence, number type, carrier, recommendation). It is specific and unambiguous, but it does not explicitly differentiate itself from sibling tools like verify_contact or verify_email, relying mostly on the resource name 'phone' to signal distinctness.
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 when phone verification is needed and mentions the API key requirement, but it does not provide explicit guidance on when to choose this tool over alternatives such as verify_address or verify_contact. No when-not-to-use conditions or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify up to 100 phone numbers in one call. Up to 100 records per call; the results array is in submission order and each entry carries its input index, so results can be zipped back onto rows without relying on order. One bad record fails only itself — it carries an error while the rest are verified. Suggestions are not available in batch. Phone validation has no bulk endpoint, so numbers are checked concurrently against a shared limit. Measured at around 2.6s for 100 numbers, which is the fastest of the three batch types — email is the slowest, at roughly 7s for 100, because it probes mail servers. Requires a Loqate API key — pass it via the 'key' field.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header | |
| phones | Yes | Phone numbers to verify, up to 100. Results are returned in the same order, each carrying its input index | |
| policy | No | Policy name: strict shipping standard (default) or permissive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint, but the description adds substantial behavior: results are in submission order with an input index for zipping, one bad record fails only itself, suggestions are absent, checks run concurrently against a shared limit, and it requires an API key. It even quantifies latency (~2.6s/100).
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?
Purpose and the record limit are front-loaded, and the sentences carry high information density. The email-latency comparison is mildly tangential but still useful for batch-type selection, so the sizing is close to appropriate.
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 batch tool with no output schema and thin annotations, the description covers ordering, error isolation, auth, concurrency, and latency. It is nearly complete; only the policy parameter's effect on results is left entirely to the schema, which is acceptable.
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 the key, phones, and policy parameters are already fully documented. The description's parameter-relevant statements (100 limit, results carry input index, pass key via 'key' field) largely restate what the schema already says, so it adds little new parameter meaning.
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 and resource with scope: 'Verify up to 100 phone numbers in one call.' It also differentiates itself from the other batch types (email being slowest, this being fastest of the three), so an agent can locate it among its siblings without opening a schema.
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?
Gives clear context for batch use (100-record limit, per-record failure isolation, no bulk upstream endpoint) and notes a limitation (suggestions unavailable in batch). It does not explicitly route single-number callers to verify_phone, so the alternative-selection guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
verify_address8 fields changedInput schema / properties / contactAdded value: +{
+ "description": "Contact name for the delivery",
+ "type": "string"
+}Input schema / properties / departmentAdded value: +{
+ "description": "Department within the organisation",
+ "type": "string"
+}Input schema / properties / forenameAdded value: +{
+ "description": "Recipient's first name",
+ "type": "string"
+}Input schema / properties / full_nameAdded value: +{
+ "description": "Recipient's full name",
+ "type": "string"
+}Input schema / properties / functionAdded value: +{
+ "description": "Contact's job title or function",
+ "type": "string"
+}Input schema / properties / idAdded value: +{
+ "description": "Your own identifier for this record, echoed back by Loqate",
+ "type": "string"
+}Input schema / properties / middle_nameAdded value: +{
+ "description": "Recipient's middle name",
+ "type": "string"
+}Input schema / properties / surnameAdded value: +{
+ "description": "Recipient's last name",
+ "type": "string"
+}verify_address_batch8 fields changedInput schema / properties / addresses / items / properties / contactAdded value: +{
+ "description": "Contact name for the delivery",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / departmentAdded value: +{
+ "description": "Department within the organisation",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / forenameAdded value: +{
+ "description": "Recipient's first name",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / full_nameAdded value: +{
+ "description": "Recipient's full name",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / functionAdded value: +{
+ "description": "Contact's job title or function",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / idAdded value: +{
+ "description": "Your own identifier for this record, echoed back by Loqate",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / middle_nameAdded value: +{
+ "description": "Recipient's middle name",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / surnameAdded value: +{
+ "description": "Recipient's last name",
+ "type": "string"
+}verify_contact8 fields changedInput schema / properties / contactAdded value: +{
+ "description": "Contact name for the delivery",
+ "type": "string"
+}Input schema / properties / departmentAdded value: +{
+ "description": "Department within the organisation",
+ "type": "string"
+}Input schema / properties / forenameAdded value: +{
+ "description": "Recipient's first name",
+ "type": "string"
+}Input schema / properties / full_nameAdded value: +{
+ "description": "Recipient's full name",
+ "type": "string"
+}Input schema / properties / functionAdded value: +{
+ "description": "Contact's job title or function",
+ "type": "string"
+}Input schema / properties / idAdded value: +{
+ "description": "Your own identifier for this record, echoed back by Loqate",
+ "type": "string"
+}Input schema / properties / middle_nameAdded value: +{
+ "description": "Recipient's middle name",
+ "type": "string"
+}Input schema / properties / surnameAdded value: +{
+ "description": "Recipient's last name",
+ "type": "string"
+}verify_contact_batch8 fields changedInput schema / properties / contacts / items / properties / contactAdded value: +{
+ "description": "Contact name for the delivery",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / departmentAdded value: +{
+ "description": "Department within the organisation",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / forenameAdded value: +{
+ "description": "Recipient's first name",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / full_nameAdded value: +{
+ "description": "Recipient's full name",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / functionAdded value: +{
+ "description": "Contact's job title or function",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / idAdded value: +{
+ "description": "Your own identifier for this record, echoed back by Loqate",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / middle_nameAdded value: +{
+ "description": "Recipient's middle name",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / surnameAdded value: +{
+ "description": "Recipient's last name",
+ "type": "string"
+}verify_address8 fields changedInput schema / properties / dependent_locality / descriptionPrevious value: -"Dependent locality (e.g. neighborhood)"New value: +"Dependent locality (e.g. neighbourhood)"Input schema / properties / latitude / descriptionPrevious value: -"Latitude for reverse geocode"New value: +"Latitude, for a reverse geocode"Input schema / properties / longitude / descriptionPrevious value: -"Longitude for reverse geocode"New value: +"Longitude, for a reverse geocode"Input schema / properties / organization / descriptionPrevious value: -"Organization or business name"New value: +"Company or organisation name"Input schema / properties / post_box / descriptionPrevious value: -"PO Box number"New value: +"PO box"Input schema / properties / sub_building / descriptionPrevious value: -"Sub-building (e.g. apartment, suite)"New value: +"Sub-building (e.g. flat, apartment or suite)"Input schema / properties / sub_building_floor / descriptionPrevious value: -"Floor number"New value: +"Floor"Input schema / properties / super_administrative_area / descriptionPrevious value: -"Super administrative area (e.g. region)"New value: +"Super administrative area"verify_address_batch30 fields changedInput schema / properties / addresses / items / properties / address2Added value: +{
+ "description": "Second address line",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / address3Added value: +{
+ "description": "Third address line",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / address4Added value: +{
+ "description": "Fourth address line",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / address5Added value: +{
+ "description": "Fifth address line",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / address6Added value: +{
+ "description": "Sixth address line",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / address7Added value: +{
+ "description": "Seventh address line",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / address8Added value: +{
+ "description": "Eighth address line",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / buildingAdded value: +{
+ "description": "Building name",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / delivery_addressAdded value: +{
+ "description": "Full delivery address",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / delivery_address1Added value: +{
+ "description": "Delivery address line 1",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / delivery_address2Added value: +{
+ "description": "Delivery address line 2",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / delivery_address3Added value: +{
+ "description": "Delivery address line 3",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / delivery_address4Added value: +{
+ "description": "Delivery address line 4",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / delivery_address5Added value: +{
+ "description": "Delivery address line 5",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / delivery_address6Added value: +{
+ "description": "Delivery address line 6",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / delivery_address7Added value: +{
+ "description": "Delivery address line 7",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / delivery_address8Added value: +{
+ "description": "Delivery address line 8",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / dependent_localityAdded value: +{
+ "description": "Dependent locality (e.g. neighbourhood)",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / dependent_thoroughfareAdded value: +{
+ "description": "Dependent street name",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / double_dependent_localityAdded value: +{
+ "description": "Double dependent locality",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / latitudeAdded value: +{
+ "description": "Latitude, for a reverse geocode",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / longitudeAdded value: +{
+ "description": "Longitude, for a reverse geocode",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / organizationAdded value: +{
+ "description": "Company or organisation name",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / post_boxAdded value: +{
+ "description": "PO box",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / premiseAdded value: +{
+ "description": "Premise or house number",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / sub_administrative_areaAdded value: +{
+ "description": "Sub administrative area (e.g. county)",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / sub_buildingAdded value: +{
+ "description": "Sub-building (e.g. flat, apartment or suite)",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / sub_building_floorAdded value: +{
+ "description": "Floor",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / super_administrative_areaAdded value: +{
+ "description": "Super administrative area",
+ "type": "string"
+}Input schema / properties / addresses / items / properties / thoroughfareAdded value: +{
+ "description": "Street name",
+ "type": "string"
+}verify_contact7 fields changedInput schema / properties / dependent_locality / descriptionPrevious value: -"Dependent locality (e.g. neighborhood)"New value: +"Dependent locality (e.g. neighbourhood)"Input schema / properties / latitude / descriptionPrevious value: -"Latitude for reverse geocode"New value: +"Latitude, for a reverse geocode"Input schema / properties / longitude / descriptionPrevious value: -"Longitude for reverse geocode"New value: +"Longitude, for a reverse geocode"Input schema / properties / organization / descriptionPrevious value: -"Organization or business name"New value: +"Company or organisation name"Input schema / properties / post_box / descriptionPrevious value: -"PO Box number"New value: +"PO box"Input schema / properties / sub_building / descriptionPrevious value: -"Sub-building (e.g. apartment, suite)"New value: +"Sub-building (e.g. flat, apartment or suite)"Input schema / properties / sub_building_floor / descriptionPrevious value: -"Floor number"New value: +"Floor"verify_contact_batch30 fields changedInput schema / properties / contacts / items / properties / address2Added value: +{
+ "description": "Second address line",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / address3Added value: +{
+ "description": "Third address line",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / address4Added value: +{
+ "description": "Fourth address line",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / address5Added value: +{
+ "description": "Fifth address line",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / address6Added value: +{
+ "description": "Sixth address line",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / address7Added value: +{
+ "description": "Seventh address line",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / address8Added value: +{
+ "description": "Eighth address line",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / buildingAdded value: +{
+ "description": "Building name",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / delivery_addressAdded value: +{
+ "description": "Full delivery address",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / delivery_address1Added value: +{
+ "description": "Delivery address line 1",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / delivery_address2Added value: +{
+ "description": "Delivery address line 2",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / delivery_address3Added value: +{
+ "description": "Delivery address line 3",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / delivery_address4Added value: +{
+ "description": "Delivery address line 4",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / delivery_address5Added value: +{
+ "description": "Delivery address line 5",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / delivery_address6Added value: +{
+ "description": "Delivery address line 6",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / delivery_address7Added value: +{
+ "description": "Delivery address line 7",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / delivery_address8Added value: +{
+ "description": "Delivery address line 8",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / dependent_localityAdded value: +{
+ "description": "Dependent locality (e.g. neighbourhood)",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / dependent_thoroughfareAdded value: +{
+ "description": "Dependent street name",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / double_dependent_localityAdded value: +{
+ "description": "Double dependent locality",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / latitudeAdded value: +{
+ "description": "Latitude, for a reverse geocode",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / longitudeAdded value: +{
+ "description": "Longitude, for a reverse geocode",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / organizationAdded value: +{
+ "description": "Company or organisation name",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / post_boxAdded value: +{
+ "description": "PO box",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / premiseAdded value: +{
+ "description": "Premise or house number",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / sub_administrative_areaAdded value: +{
+ "description": "Sub administrative area (e.g. county)",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / sub_buildingAdded value: +{
+ "description": "Sub-building (e.g. flat, apartment or suite)",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / sub_building_floorAdded value: +{
+ "description": "Floor",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / super_administrative_areaAdded value: +{
+ "description": "Super administrative area",
+ "type": "string"
+}Input schema / properties / contacts / items / properties / thoroughfareAdded value: +{
+ "description": "Street name",
+ "type": "string"
+}verify_address_batchverify_contact_batchverify_email_batchverify_phone_batchverify_address1 field changedInput schema / properties / options / descriptionPrevious value: -"Loqate API options. Pass GeoCode here as a boolean — it is sent at the request root where Loqate expects it. In-Options booleans (Certify Version Enhance Deceased Goneaways) take JSON booleans; ServerOptions values (e.g. OutputCasing DefaultCountry) are strings"New value: +"Loqate API options as nested JSON, e.g. {\"ServerOptions\": {\"FieldStatus\": \"true\"}}. Dot notation is equivalent: {\"ServerOptions.FieldStatus\": \"true\"}. Pass GeoCode here as a boolean — it is sent at the request root where Loqate expects it. In-Options booleans (Certify Version Enhance Deceased Goneaways) take JSON booleans; ServerOptions values (e.g. OutputCasing DefaultCountry) are strings. Set ServerOptions.FieldStatus to \"true\" to get the changes list"verify_contact1 field changedInput schema / properties / options / descriptionPrevious value: -"Loqate API options. Pass GeoCode here as a boolean — it is sent at the request root where Loqate expects it. In-Options booleans (Certify Version Enhance Deceased Goneaways) take JSON booleans; ServerOptions values (e.g. OutputCasing DefaultCountry) are strings"New value: +"Loqate API options as nested JSON, e.g. {\"ServerOptions\": {\"FieldStatus\": \"true\"}}. Dot notation is equivalent: {\"ServerOptions.FieldStatus\": \"true\"}. Pass GeoCode here as a boolean — it is sent at the request root where Loqate expects it. In-Options booleans (Certify Version Enhance Deceased Goneaways) take JSON booleans; ServerOptions values (e.g. OutputCasing DefaultCountry) are strings. Set ServerOptions.FieldStatus to \"true\" to get the changes list"retrieve_addressverify_address2 fields changedInput schema / properties / suggest / descriptionPrevious value: -"When true, look up alternative addresses suggested by Loqate and return them in the result as suggestions. The lookup runs when the address is not accepted (review or reject) OR when it is accepted below the confidence floor (see suggest_below) — a policy accepts from its own minimum, so an accepted address is not necessarily a confident one. Address-only; off by default"New value: +"When true, look up alternative addresses suggested by Loqate and return them in the result as suggestions. Requires the Loqate address-suggestion feature to be enabled on the account (licensed separately from verification) — without it, verification still succeeds and the reason appears in suggestions.error. The lookup runs when the address is not accepted (review or reject) OR when it is accepted below the confidence floor (see suggest_below) — a policy accepts from its own minimum, so an accepted address is not necessarily a confident one. Address-only; off by default"Input schema / properties / suggestion_idAdded value: +{
+ "description": "Id of a suggestion previously returned in address.suggestions. The tool retrieves that address's cleansed components from Loqate and verifies those, which is how you confirm a suggestion the user chose. Use INSTEAD OF address, not alongside it. CONSUMES A LOQATE CREDIT — pass one id, for the one suggestion that was chosen, never several. Ids are not stable over time; a stale one returns SUGGESTION_NOT_FOUND and you must search again rather than retry",
+ "type": "string"
+}verify_contact2 fields changedInput schema / properties / suggest / descriptionPrevious value: -"When true, look up alternative addresses suggested by Loqate and return them under address.suggestions. The lookup runs when the address is not accepted (review or reject) OR when it is accepted below the confidence floor (see suggest_below). Address-only — does not affect phone or email; off by default"New value: +"When true, look up alternative addresses suggested by Loqate and return them under address.suggestions. Requires the Loqate address-suggestion feature to be enabled on the account (licensed separately from verification). The lookup runs when the address is not accepted (review or reject) OR when it is accepted below the confidence floor (see suggest_below). Address-only — does not affect phone or email; off by default"Input schema / properties / suggestion_idAdded value: +{
+ "description": "Id of a suggestion previously returned in address.suggestions. The tool retrieves that address's cleansed components from Loqate and verifies those, which is how you confirm a suggestion the user chose. Use INSTEAD OF address, not alongside it. CONSUMES A LOQATE CREDIT — pass one id, for the one suggestion that was chosen, never several. Ids are not stable over time; a stale one returns SUGGESTION_NOT_FOUND and you must search again rather than retry",
+ "type": "string"
+}verify_address3 fields changedInput schema / properties / suggestAdded value: +{
+ "description": "When true, look up alternative addresses suggested by Loqate and return them in the result as suggestions. The lookup runs when the address is not accepted (review or reject) OR when it is accepted below the confidence floor (see suggest_below) — a policy accepts from its own minimum, so an accepted address is not necessarily a confident one. Address-only; off by default",
+ "type": "boolean"
+}Input schema / properties / suggest_belowAdded value: +{
+ "description": "Confidence floor for suggestions (0-1). An accepted address scoring below it still gets suggestions — policies accept from their own minimum, so an accepted address is not necessarily a confident one. Omit to use the policy value (standard 0.85); 0 disables the floor so only review/reject trigger a lookup",
+ "type": [
+ "null",
+ "number"
+ ]
+}Input schema / properties / suggest_limitAdded value: +{
+ "description": "Maximum number of suggestions to return (1-10, default 5). Requires suggest",
+ "type": "integer"
+}verify_contact3 fields changedInput schema / properties / suggestAdded value: +{
+ "description": "When true, look up alternative addresses suggested by Loqate and return them under address.suggestions. The lookup runs when the address is not accepted (review or reject) OR when it is accepted below the confidence floor (see suggest_below). Address-only — does not affect phone or email; off by default",
+ "type": "boolean"
+}Input schema / properties / suggest_belowAdded value: +{
+ "description": "Confidence floor for suggestions (0-1). An accepted address scoring below it still gets suggestions. Omit to use the policy value (standard 0.85); 0 disables the floor. Address-only",
+ "type": [
+ "null",
+ "number"
+ ]
+}Input schema / properties / suggest_limitAdded value: +{
+ "description": "Maximum number of suggestions to return (1-10, default 5). Requires suggest",
+ "type": "integer"
+}verify_address1 field changedInput schema / properties / detect_countryAdded value: +{
+ "description": "When true and no country is supplied, guess the country from the address and flag the guess in the result (country_guessed). Address-only; off by default",
+ "type": "boolean"
+}verify_contact1 field changedInput schema / properties / detect_countryAdded value: +{
+ "description": "When true and no country is supplied, guess the country from the address and flag the guess in the result (country_guessed). Address-only — does not affect phone or email; off by default",
+ "type": "boolean"
+}verify_address1 field changedInput schema / properties / options / descriptionPrevious value: -"Loqate API options (e.g. GeoCode, Certify, DefaultCountry, OutputCasing)"New value: +"Loqate API options. Pass GeoCode here as a boolean — it is sent at the request root where Loqate expects it. In-Options booleans (Certify Version Enhance Deceased Goneaways) take JSON booleans; ServerOptions values (e.g. OutputCasing DefaultCountry) are strings"verify_contact1 field changedInput schema / properties / options / descriptionPrevious value: -"Loqate API options (e.g. GeoCode, Certify, DefaultCountry, OutputCasing)"New value: +"Loqate API options. Pass GeoCode here as a boolean — it is sent at the request root where Loqate expects it. In-Options booleans (Certify Version Enhance Deceased Goneaways) take JSON booleans; ServerOptions values (e.g. OutputCasing DefaultCountry) are strings"verify_address1 field changedInput schema / properties / key / descriptionPrevious value: -"Loqate API key — required unless the server has one configured (get one at account.loqate.com)"New value: +"Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header (get one at account.loqate.com)"verify_contact1 field changedInput schema / properties / key / descriptionPrevious value: -"Loqate API key — required unless the server has one configured"New value: +"Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header"verify_email1 field changedInput schema / properties / key / descriptionPrevious value: -"Loqate API key — required unless the server has one configured"New value: +"Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header"verify_phone1 field changedInput schema / properties / key / descriptionPrevious value: -"Loqate API key — required unless the server has one configured"New value: +"Loqate API key — required unless the server has one configured or the request carries an Authorization: Bearer header"list_policiesshow_policyverify_addressverify_contactverify_emailverify_phoneVerify emails and domains for routing, disposable providers, role accounts, and SMTP risk.
Verify emails — deliverability, disposable/role/free detection, MX validity, domain age.
Verify phone numbers, emails and IPs, and check remaining plan credits.
Verify email addresses in real time and find business email addresses with live mailbox checks.
Add one secure layer between your agents and this server.
