Cold email compliance check, 12 countries: per-address verdict, rule cited, signed receipt.
Scored across 4 tools
Each tool has a clearly distinct role: compliance check, opt-out recording, receipt retrieval, and account linking. The only minor wrinkle is that contact_check carries two modes (address verdict and draft email content check) in one tool, but that is described explicitly and does not create cross-tool confusion.
All names are snake_case and readable, with link_account, suppress_contact and verify_receipt following a clean verb_noun pattern. contact_check deviates as noun_verb, a small inconsistency but not confusing.
Four tools is lean but each maps to a real workflow step: check, suppress, verify, authenticate. It is on the sparse side for a compliance service, but nothing is redundant or trivial.
The core lifecycle is covered: pre-send check, opt-out handling, proof verification, and account linking. Minor gaps exist, such as no way to list the opt-out list or view remaining allowance/history, but these are workaroundable and not central to the main flow.
Is it legal to send a cold or marketing email to this person? Check before the first email to any new lead, prospect or contact who is not already a customer, one call per address: a compliance check for B2B sales outreach, prospecting and lead lists. Whether it is allowed, or needs consent first, turns on facts you cannot see in the address, such as whether a UK recipient is a limited company or a sole trader, so it looks them up live (UK Companies House) and applies UK PECR and GDPR, US CAN-SPAM, Canadian CASL, German UWG, French CPCE, Australia's Spam Act, Ireland's ePrivacy Regulations, the Dutch Telecommunicatiewet, Spain's LSSI, Italy's Privacy Code, Latvia's Information Society Services Law and the UAE's PDPL. Returns a verdict (ok_to_email, consent_needed, blocked or unknown), the rule quoted with its source, the footer requirements (who you are, a postal address, an unsubscribe or opt-out), the next step and a signed receipt id to show a client or auditor. Each charged call uses one check from your allowance (free daily allowance, no sign-in); unknown-country answers and one qualifying re-check within a day are free, up to a combined limit of 50 a day. Nothing is sent to the recipient. Not for transactional emails such as invoices, receipts or password resets. To check the email itself, send the draft as email ({ subject, body, from_name, from_email }); the answer then gains email_check, saying whether the footer has an opt-out, the sender's identity and, where the rule needs one, a postal address. The draft is not stored. Addresses on the key's opt-out list (see suppress_contact) come back blocked and free.
| Name | Required | Description | Default |
|---|---|---|---|
| No | The draft email, if you want the answer to say whether its footer meets the rule for the recipient's country. The body is not stored. | ||
| pitch | No | What the email offers, in a few words, for example 'bookkeeping software for dental practices'. Used to judge relevance to the recipient's role. | |
| suppressed | No | True if the recipient is on your own do-not-contact list. | |
| company_name | No | The recipient's company or organisation name if you know it, for example from your CRM. For UK recipients it is used to search Companies House when the domain alone does not find the company. A company is only used when other evidence links it to the recipient, such as one of its officers matching the recipient or the website naming it. | |
| address_source | No | Where the address came from: published (on their website, profile or a directory), bought (a purchased list), scraped (collected by a tool), given (the person gave it to you) or unknown. It affects the verdict, so do not assume published. Default unknown. | |
| company_number | No | UK company number if known (8 characters), so the register can confirm the company. | |
| pitch_relevant | No | True if the pitch relates to the recipient's job or business, false if it does not. | |
| recipient_name | No | The recipient's full name if you know it, for example Jane Smith. For UK recipients it is matched against a company's current officers at Companies House. Precleared does not store it. | |
| sender_country | No | Country the sending business is based in: GB, US, AE (United Arab Emirates) or CA (Canada). Canadian senders must also meet CASL. Not the recipient's country. Default GB. | |
| recipient_email | No | The recipient's email address. Give this or recipient_domain. | |
| recipient_domain | No | The recipient's domain when you have no email address, for example acme.co.uk. | |
| existing_customer | No | True if the recipient has bought from you before. Default false. | |
| recipient_country | No | Two-letter country code of the recipient if known, for example GB or DE. Otherwise it is worked out from the domain, company records and the company's website. | |
| default_recipient_country | No | Two-letter country code to use only when the recipient's country can't be worked out from recipient_country, the domain, company records or the company's website, for example US if all your prospects are in the US. recipient_country always wins. |
| Name | Required | Description |
|---|---|---|
| facts | No | Facts gathered about the recipient. |
| usage | No | Allowance left for the caller. |
| charged | No | |
| reasons | No | The rule that matched, with its text and source, then any notes. |
| receipt | No | Signed receipt for this check. |
| verdict | Yes | The answer for this recipient. |
| next_step | No | What to do next. |
| confidence | No | high, medium or low. |
| disclaimer | No | Fixed disclaimer line. |
| email_check | No | Present when you sent email: whether the draft's footer has what the rule needs. |
| footer_text | No | What the email's footer must include, if the rule sets requirements. |
| held_because | No | |
| rules_applied | No | Rule keys used. |
| rules_version | No | Version of the rule set used. |
| free_recheck_of | No | |
| possible_company | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses live UK Companies House lookups, supported jurisdictions, possible verdicts, footer requirements, signed receipts, and that nothing is sent to the recipient. It also explains charging: one allowance check per charged call, free daily allowance, and free unknown-country or qualifying re-check answers up to a combined limit, which lets an agent predict cost 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 purpose question is front-loaded, and the paragraph is dense with useful constraints rather than filler. However, it is long, includes a sprawling jurisdiction list, and has some run-on sentences that could be structured more crisply.
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 14-parameter, multi-jurisdiction compliance tool with live lookups and billing, the description covers when to use it, exclusions, cost model, data handling, and returned value. With annotations and an output schema already present, it is complete enough for an agent to invoke 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 description coverage is 100%, so the input schema already documents all 14 parameters and their formats. The description adds only modest extra meaning—mainly that sending the email draft yields an email_check result and that the draft is not stored—so the baseline of 3 is appropriate for a high-coverage schema.
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 opens with a specific question ('Is it legal to send a cold or marketing email to this person?') and defines the resource as a per-recipient compliance check for B2B outreach. It clearly separates the tool from transactional email use and names the sibling suppress_contact, so an agent can place it among siblings 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?
It explicitly says to check before the first email to any new lead, prospect, or non-customer contact, and it rules out transactional emails such as invoices or password resets. It also gives the one-call-per-address constraint and points to suppress_contact for opt-out lists, leaving little ambiguity about when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Links this connection to the person's own Precleared key, so checks use their own free allowance, 14-day trial and plan instead of the shared free allowance. Use it when the person asks to sign in to or connect Precleared, or when contact_check says the free checks have run out. If they aren't signed in, Claude will ask them to sign in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety bar is low. The description adds genuinely useful context: the credential switches to the user's allowance, trial and plan, and an interactive sign-in prompt may occur. However, 'links this connection' implies a state change on the connection, which sits in mild tension with readOnlyHint=true and is not reconciled.
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?
Effect is front-loaded and the triggers follow in one sentence, so it reads well. The closing sentence ('If they aren't signed in, Claude will ask them to sign in') is circular and partly redundant with the trigger already stated.
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, no-output-schema tool with rich annotations, the description supplies the missing decision context: when to invoke it and what quota behavior changes. It does not cover what the agent should do after the call (e.g., retry contact_check), which would close the loop.
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 takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. The description correctly conveys that the call is parameterless and driven by the user's sign-in state instead.
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 ('Links this connection to the person's own Precleared key') and immediately explains the effect on quota/trial/plan, so the agent knows exactly what the call accomplishes. It is clearly distinguishable from contact_check and verify_receipt.
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 two concrete triggers: the user asking to sign in/connect, and contact_check reporting that free checks have run out. No explicit 'do not use when' condition or alternative is offered, but the routing to contact_check covers the main decision point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records that a person asked not to be emailed, on this Precleared key's opt-out list, so every agent and tool using the key gets blocked for that address from contact_check. Use it as soon as someone replies stop, unsubscribes, bounces or complains. Give email or domain; set remove to true only when the person asks to be emailed again. Needs a Precleared key (a free one is fine). Never charged. The address is kept only as a hash and a masked copy.
| Name | Required | Description | Default |
|---|---|---|---|
| No | The address. | ||
| domain | No | A whole domain, such as acme.co.uk. | |
| reason | No | Default opted_out. | |
| remove | No | True to take the entry off the list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say this is a non-read-only, idempotent, non-destructive, closed-world write. The description adds real behavioral context beyond that: the entry is key-scoped so every agent and tool using the key is affected, a Precleared key is required (and a free one suffices), there is no charge, and the stored address is retained only as a hash plus a masked copy. That is exactly the kind of side-effect and privacy detail annotations cannot convey.
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 effect are front-loaded in the first sentence, and every subsequent sentence carries operational information. The billing note is split across two short sentences ('Needs a Precleared key (a free one is fine). Never charged.') and could be merged, but there is no filler.
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 4-parameter write tool with no output schema, the description covers prerequisites, scope of effect, storage/privacy behavior, and when to invoke. It does not say what a successful call returns (e.g., the masked address or confirmation), which is the only meaningful remaining gap.
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 would be 3, but the description adds meaning the schema does not: email and domain are alternatives ('Give email or domain'), and remove carries a policy condition rather than just 'true to take the entry off the list'. The reason enum's intended triggers are only loosely implied via the opt-out/bounce/complaint phrasing, keeping it off a 5.
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 ('Records that a person asked not to be emailed... on this Precleared key's opt-out list') and covers both directions (add, and remove via the remove flag). It also names the downstream consumer, contact_check, so an agent can place it relative to the sibling tools 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?
Gives concrete triggering events ('as soon as someone replies stop, unsubscribes, bounces or complains') and an explicit guard on the inverse operation ('set remove to true only when the person asks to be emailed again'). The email-or-domain choice is also stated as a calling instruction rather than left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a Precleared receipt by its id (cc_rcpt_...) to show what was checked, when, and the verdict, with the hashes, Ed25519 signature and public key needed to verify it. Use it when a person or an audit asks for proof of a check.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Receipt id, such as cc_rcpt_0123456789ABCDEF. |
| Name | Required | Description |
|---|---|---|
| id | Yes | Receipt id. |
| verdict | No | Verdict given. |
| algorithm | No | Signature algorithm. |
| signature | No | Ed25519 signature, base64. |
| confidence | No | Confidence given. |
| created_at | No | When the check was made. |
| public_key | No | Public key, base64 SPKI DER. |
| key_version | No | Signing key version. |
| request_hash | No | SHA-256 of the request. |
| response_hash | No | SHA-256 of the response. |
| rules_applied | No | Rule keys used. |
| rules_version | No | Rule set version. |
| sender_country | No | Sender country. |
| recipient_domain | No | Recipient domain. |
| recipient_email_masked | No | Masked recipient address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds value beyond that by disclosing the verification payload (hashes, Ed25519 signature, public key) that tells the agent this is a proof-producing read, not just a record lookup.
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, both load-bearing: the first states the operation and its return contents, the second states the triggering condition. Purpose is front-loaded with zero filler.
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?
Annotations carry the safety profile and an output schema exists, so return values need not be explained, yet the description still tells the agent enough about the receipt's contents to call the tool correctly. Nothing material is missing for a single-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema description coverage, so the schema already documents it fully. The description restates the id format (cc_rcpt_...) without adding syntax or constraints beyond what the schema provides, which lands at the baseline for high-coverage schemas.
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?
Specific verb ('Fetch') plus resource ('Precleared receipt by its id') and an explicit inventory of what the receipt contains: what was checked, when, the verdict, hashes, signature and public key. It does not explicitly distinguish itself from the sibling contact_check, but the two operate on unrelated resources so no real ambiguity exists.
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?
'Use it when a person or an audit asks for proof of a check' gives a concrete triggering condition, which is more than most definitions offer. It stops short of naming when-not-to-use or an alternative tool, so it is clear context without exclusions.
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.
contact_check2 fields changedInput schema / properties / emailAdded value: +{
+ "description": "The draft email, if you want the answer to say whether its footer meets the rule for the recipient's country. The body is not stored.",
+ "properties": {
+ "body": {
+ "description": "Body, plain text or HTML, including the footer and any merge tags such as {{unsubscribe}}.",
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "from_email": {
+ "description": "Sending address.",
+ "maxLength": 254,
+ "type": "string"
+ },
+ "from_name": {
+ "description": "Sender name shown to the recipient.",
+ "maxLength": 120,
+ "type": "string"
+ },
+ "subject": {
+ "description": "Subject line.",
+ "maxLength": 300,
+ "type": "string"
+ }
+ },
+ "required": [
+ "body"
+ ],
+ "type": "object"
+}Output schema / properties / email_checkAdded value: +{
+ "additionalProperties": false,
+ "description": "Present when you sent email: whether the draft's footer has what the rule needs.",
+ "properties": {
+ "country": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "footer_text": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "missing": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "note": {
+ "type": "string"
+ },
+ "requirements": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "detail": {
+ "type": "string"
+ },
+ "key": {
+ "type": "string"
+ },
+ "met": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "required": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "key",
+ "required",
+ "met",
+ "detail"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "enum": [
+ "pass",
+ "fail"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "country",
+ "requirements",
+ "missing",
+ "note"
+ ],
+ "type": "object"
+}suppress_contactcontact_check6 fields changedInput schema / properties / sender_country / descriptionPrevious value: -"Country the sending business is based in: GB, US or AE (United Arab Emirates). Not the recipient's country. Default GB."New value: +"Country the sending business is based in: GB, US, AE (United Arab Emirates) or CA (Canada). Canadian senders must also meet CASL. Not the recipient's country. Default GB."Input schema / properties / sender_country / enumPrevious value: -[
- "GB",
- "US",
- "AE"
-]New value: +[
+ "GB",
+ "US",
+ "AE",
+ "CA"
+]Output schema / properties / chargedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / free_recheck_ofAdded value: +{
+ "type": "string"
+}Output schema / properties / held_becauseAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "case": {
+ "type": "string"
+ },
+ "evidence": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "case",
+ "evidence"
+ ],
+ "type": "object"
+}Output schema / properties / possible_companyAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "number"
+ ],
+ "type": "object"
+}link_accountcontact_check2 fields changedInput schema / properties / company_nameAdded value: +{
+ "description": "The recipient's company or organisation name if you know it, for example from your CRM. For UK recipients it is used to search Companies House when the domain alone does not find the company. A company is only used when other evidence links it to the recipient, such as one of its officers matching the recipient or the website naming it.",
+ "maxLength": 160,
+ "type": "string"
+}Input schema / properties / recipient_nameAdded value: +{
+ "description": "The recipient's full name if you know it, for example Jane Smith. For UK recipients it is matched against a company's current officers at Companies House. Precleared does not store it.",
+ "maxLength": 120,
+ "type": "string"
+}contact_check2 fields changedInput schema / properties / sender_country / descriptionPrevious value: -"Country the sending business is based in, GB or US. Not the recipient's country. Default GB."New value: +"Country the sending business is based in: GB, US or AE (United Arab Emirates). Not the recipient's country. Default GB."Input schema / properties / sender_country / enumPrevious value: -[
- "GB",
- "US"
-]New value: +[
+ "GB",
+ "US",
+ "AE"
+]contact_check1 field changedInput schema / properties / address_source / descriptionPrevious value: -"Where the address came from: published (on their website, profile or a directory), bought (a purchased list), scraped (collected by a tool), given (the person gave it to you) or unknown. It affects the verdict, so do not assume published."New value: +"Where the address came from: published (on their website, profile or a directory), bought (a purchased list), scraped (collected by a tool), given (the person gave it to you) or unknown. It affects the verdict, so do not assume published. Default unknown."contact_check3 fields changedOutput schema / properties / usage / properties / low_balanceAdded value: +{
+ "type": "boolean"
+}Output schema / properties / usage / properties / noticeAdded value: +{
+ "type": "string"
+}Output schema / properties / usage / properties / top_up_urlAdded value: +{
+ "type": "string"
+}contact_check2 fields changedInput schema / properties / default_recipient_countryAdded value: +{
+ "description": "Two-letter country code to use only when the recipient's country can't be worked out from recipient_country, the domain, company records or the company's website, for example US if all your prospects are in the US. recipient_country always wins.",
+ "pattern": "^[A-Za-z]{2}$",
+ "type": "string"
+}Input schema / properties / recipient_country / descriptionPrevious value: -"Two-letter country code of the recipient if known, for example GB or DE. Otherwise it is worked out from the domain and company records."New value: +"Two-letter country code of the recipient if known, for example GB or DE. Otherwise it is worked out from the domain, company records and the company's website."contact_check1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "confidence": {
+ "description": "high, medium or low.",
+ "type": "string"
+ },
+ "disclaimer": {
+ "description": "Fixed disclaimer line.",
+ "type": "string"
+ },
+ "facts": {
+ "additionalProperties": {},
+ "description": "Facts gathered about the recipient.",
+ "properties": {},
+ "type": "object"
+ },
+ "footer_text": {
+ "description": "What the email's footer must include, if the rule sets requirements.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "next_step": {
+ "description": "What to do next.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "reasons": {
+ "description": "The rule that matched, with its text and source, then any notes.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "receipt": {
+ "additionalProperties": {},
+ "description": "Signed receipt for this check.",
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "verify_url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "rules_applied": {
+ "description": "Rule keys used.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rules_version": {
+ "description": "Version of the rule set used.",
+ "type": "string"
+ },
+ "usage": {
+ "additionalProperties": {},
+ "description": "Allowance left for the caller.",
+ "properties": {
+ "credits_remaining": {
+ "type": "number"
+ },
+ "free_remaining_today": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "verdict": {
+ "description": "The answer for this recipient.",
+ "enum": [
+ "ok_to_email",
+ "consent_needed",
+ "blocked",
+ "unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "verdict"
+ ],
+ "type": "object"
+}verify_receipt1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "algorithm": {
+ "description": "Signature algorithm.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "confidence": {
+ "description": "Confidence given.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "description": "When the check was made.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Receipt id.",
+ "type": "string"
+ },
+ "key_version": {
+ "description": "Signing key version.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "public_key": {
+ "description": "Public key, base64 SPKI DER.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "recipient_domain": {
+ "description": "Recipient domain.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "recipient_email_masked": {
+ "description": "Masked recipient address.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "request_hash": {
+ "description": "SHA-256 of the request.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "response_hash": {
+ "description": "SHA-256 of the response.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rules_applied": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Rule keys used."
+ },
+ "rules_version": {
+ "description": "Rule set version.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sender_country": {
+ "description": "Sender country.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "signature": {
+ "description": "Ed25519 signature, base64.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verdict": {
+ "description": "Verdict given.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+}contact_check10 fields changedInput schema / properties / address_source / descriptionPrevious value: -"Where the address came from. Default published."New value: +"Where the address came from: published (on their website, profile or a directory), bought (a purchased list), scraped (collected by a tool), given (the person gave it to you) or unknown. It affects the verdict, so do not assume published."Input schema / properties / company_number / descriptionPrevious value: -"UK company number, if known. Speeds up UK checks."New value: +"UK company number if known (8 characters), so the register can confirm the company."Input schema / properties / existing_customer / descriptionPrevious value: -"Whether the recipient is already a customer. Default false."New value: +"True if the recipient has bought from you before. Default false."Input schema / properties / pitch / descriptionPrevious value: -"A short description of what the email offers."New value: +"What the email offers, in a few words, for example 'bookkeeping software for dental practices'. Used to judge relevance to the recipient's role."Input schema / properties / pitch_relevant / descriptionPrevious value: -"Whether the pitch relates to the recipient's role or business."New value: +"True if the pitch relates to the recipient's job or business, false if it does not."Input schema / properties / recipient_country / descriptionPrevious value: -"ISO 3166 two-letter country of the recipient, if known."New value: +"Two-letter country code of the recipient if known, for example GB or DE. Otherwise it is worked out from the domain and company records."Input schema / properties / recipient_domain / descriptionPrevious value: -"Recipient domain, used when there is no email address."New value: +"The recipient's domain when you have no email address, for example acme.co.uk."Input schema / properties / recipient_email / descriptionPrevious value: -"Recipient email address. Give this or recipient_domain."New value: +"The recipient's email address. Give this or recipient_domain."Input schema / properties / sender_country / descriptionPrevious value: -"Where the sender is based. GB or US. Default GB."New value: +"Country the sending business is based in, GB or US. Not the recipient's country. Default GB."Input schema / properties / suppressed / descriptionPrevious value: -"Set true if the recipient is on your own suppression list."New value: +"True if the recipient is on your own do-not-contact list."contact_checkverify_receiptVerify email addresses before you send: honest verdicts, no address kept, EU-hosted.
Verify email deliverability by SMTP. Catch-all/disposable/role detection. EU-hosted, GDPR-ready.
EU compliance checks for AI agents: sanctions, company, VAT ID, IBAN, email. Pay per call.
Email validation for AI assistants: verdict, risk score, evidence. Free: 100 checks a month.
Add one secure layer between your agents and this server.
