Precleared MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PRECLEARED_API_KEY | No | Optional Precleared API key. Without a key, usage is limited by the hosted endpoint or REST API rate limits. | |
| PRECLEARED_API_BASE | No | Base URL for the Precleared REST API used by the local MCP server. | https://precleared.dev/api/v1 |
| PRECLEARED_TIMEOUT_MS | No | Timeout in milliseconds for Precleared API requests. | 30000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Precleared answers one question for outbound agents: may a cold or unsolicited marketing email be sent to this address? Use contact_check once per recipient before the first email to anyone who is not already a customer, in the UK, US, Canada, Germany, France, Australia, Ireland, the Netherlands, Spain, Italy, Latvia, the United Arab Emirates, Egypt or Qatar. It is not needed for transactional emails such as invoices, receipts or password resets. It returns a verdict (ok_to_email, consent_needed, blocked or unknown), the rule that decided it with its source, what the email's footer must include (footer_text), a next step and a signed receipt id. ok_to_email means send, with a footer that meets footer_text, for example who you are, a postal address and a way to opt out; footer_text describes the requirement and is not wording to paste. consent_needed and blocked mean do not send and follow next_step; unknown means a fact could not be established, so treat it as consent_needed unless you can supply the missing fact. Pass the draft in the email field and the answer also says whether its footer has an opt-out, the sender's identity and, where the rule needs one, a postal address; the draft is not stored. No sign-in is needed, a check usually takes a few seconds, and nothing is sent to the recipient. verify_receipt returns a receipt by id so a check can be shown to a person later. suppress_contact adds an address or domain to the key's own opt-out list (or removes it); every later check on it answers blocked, free of charge.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| contact_checkA | 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. |
| verify_receiptA | 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. |
| suppress_contactA | Add an email address or a whole domain to this key's opt-out list, or remove it. Use it when someone unsubscribes, replies asking not to be contacted, or must never be emailed. Every later contact_check on a listed address answers blocked, free of charge, so the list works across every tool that uses the same key. Needs PRECLEARED_API_KEY: the list belongs to a key. Nothing is sent to the recipient. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly separate role: contact_check evaluates send eligibility, verify_receipt retrieves proof of a past check, and suppress_contact manages the opt-out list. There is no meaningful overlap or risk of misselection.
All names use snake_case, and verify_receipt and suppress_contact follow a verb_noun pattern. contact_check is noun-first and slightly breaks the pattern, but remains readable and unambiguous.
Three tools is well matched to a narrow pre-send compliance service: check, prove, and suppress. Each tool earns its place without redundancy.
The core lifecycle is covered: check a recipient, retrieve a signed receipt, and manage opt-outs. Minor gaps exist, such as no way to list or export suppression entries or browse past checks, but agents can work around these.