Skip to main content
Glama
Sign In
Precleared MCP Server

Precleared MCP Server

by gabrielaoimevbore-beep
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Contact check

contact_check

Checks whether a cold marketing email to one recipient is lawful before sending, returning a per-address verdict, the governing rule, required footer content and a verifiable receipt.

Instructions

Check whether a cold or unsolicited marketing email to one recipient is allowed under 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, the UAE's PDPL, Egypt's Personal Data Protection Law and Qatar's Personal Data Privacy Protection Law. Use it before the first email to a new contact, one call per address. Not needed for transactional emails such as invoices, receipts or password resets. Returns the verdict, confidence, the rule quoted with its source, what the email's footer must include, the next step and the facts used. Pass the draft in email and the answer also reports whether its footer meets the rule (email_check). Each charged check uses one check from your allowance and is saved as a signed receipt; answers where no rule applied, and one re-check within a day, are free. It does not send anything.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "contact_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
emailNoThe 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; only a hash of it goes on the receipt.
pitchNoWhat the email offers, in a few words, for example 'bookkeeping software for dental practices'. Used to judge relevance to the recipient's role.
suppressedNoTrue if the recipient is on your own do-not-contact list.
company_nameNoThe 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.
address_sourceNoWhere 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.
company_numberNoUK company number if known (8 characters), so the register can confirm the company.
pitch_relevantNoTrue if the pitch relates to the recipient's job or business, false if it does not.
recipient_nameNoThe 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_countryNoCountry 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_emailNoThe recipient's email address. Give this or recipient_domain.
recipient_domainNoThe recipient's domain when you have no email address, for example acme.co.uk.
existing_customerNoTrue if the recipient has bought from you before. Default false.
recipient_countryNoTwo-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_countryNoTwo-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.

Output Schema

NameRequiredDescriptionDefault
factsNoFacts gathered about the recipient.
usageNoAllowance left for the caller.
chargedNoFalse when the answer was free (no rule applied, a re-check within a day, or an address on your opt-out list).
reasonsNoThe rule that matched, with its text and source, then any notes.
receiptNoSigned receipt for this check, with id and verify_url.
verdictYesThe answer for this recipient.
next_stepNoWhat to do next.
confidenceNohigh, medium or low.
disclaimerNoFixed disclaimer line.
email_checkNoOnly when a draft was passed in email: status (pass or fail), the requirements checked (opt_out, sender_identity, postal_address, commercial_nature), which are missing, and a note.
footer_textNoWhat the email's footer must include, if the rule sets requirements.
rules_appliedNoRule keys used.
rules_versionNoVersion of the rule set used.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), the description discloses billing mechanics ('uses one check from your allowance'), receipt creation ('saved as a signed receipt'), free cases ('answers where no rule applied, and one re-check within a day, are free'), data handling ('body is not stored; only a hash'), and that it does not send anything. This is unusually rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and usage rules, then moves to returns, billing, and limitations. The long enumeration of jurisdictions is purposeful scope-setting, though it could be tightened. Overall it is efficient but slightly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, open-world tool with an output schema and annotations, the description covers purpose, timing, exclusions, return contents, cost model, privacy handling, and non-sending behavior. An agent has everything needed to call it correctly without opening the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 thoroughly, including nested fields and enums. The description adds only a small clarification that passing a draft email enables the footer compliance check; otherwise it does not add meaning beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Check whether a cold or unsolicited marketing email to one recipient is allowed' under a named set of laws. It is immediately distinguishable from the siblings (suppress_contact, verify_receipt), and the scope (single recipient pre-send compliance check) is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use ('before the first email to a new contact, one call per address') and when-not-to-use ('Not needed for transactional emails such as invoices, receipts or password resets'). It also explains the optional footer-check behavior via the email parameter, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools