The Qorami MCP server acts as an AI email safety gate, providing two primary tools:
verify_email: Submit an email (recipient, subject, body, and optional policy profile) to get a permission decision before sending. The agent must obey the returned decision, which is one of:
send — email is allowed
request_human_confirmation — a human must review first; poll for the outcome using check_action_status
do_not_send — email is blocked; the suggestions field explains what to fix
Optionally returns a remediation.safeBody with sensitive content redacted when auto-remediation is possible
check_action_status: Poll the status of a pending human review using the actionId returned by verify_email. Continue polling until the decision becomes either send (approved) or do_not_send (blocked).
Official clients, tool schemas and an MCP server for Qorami — a control point between your AI agents and actually sending email. Before each send, the agent asks Qorami, which replies send, request_human_confirmation, or do_not_send.
Get an API key in the dashboard. Full API reference: https://qorami.fr/docs.
Path | What |
Zero-dependency JavaScript / TypeScript client ( | |
Zero-dependency Python client (stdlib only) + LangChain, CrewAI, LlamaIndex & OpenAI-Agents tools. | |
Drop-in OpenAI function-calling & Anthropic tool-use schemas for | |
Stdio MCP server ( | |
n8n community node ( | |
No-code recipe: guard a workflow's email with a plain HTTP Request node (no install). | |
Runnable Node & Python quickstarts. |
import { QoramiClient } from './js/qorami.mjs'
const qorami = new QoramiClient({ apiKey: process.env.QORAMI_API_KEY })
await qorami.guard(
{ recipient: 'client@example.com', subject: 'Our offer', body, policyProfile: 'sales' },
{
send: () => mailer.send(), // allowed
requestHumanConfirmation: (r) => queue(r.action.id), // a human was notified
doNotSend: (r) => log('blocked', r.decision), // do not send
},
)Or step by step with qorami.verify(...) and, after a review, poll
qorami.status(actionId) until nextAction.type === 'send'.
Related MCP server: Agent Prompt Injection Firewall MCP
from qorami import QoramiClient
qorami = QoramiClient(api_key=os.environ["QORAMI_API_KEY"])
result = qorami.verify(recipient="client@example.com", subject="Our offer",
body=email_body, policy_profile="sales")
if result.next_action_type == "send":
send_email()
elif result.next_action_type == "request_human_confirmation":
queue_for_review(result.action_id) # a human was notified by email
# else: do_not_sendpip install qorami[<framework>] ships a drop-in qorami_check_email wrapper —
each returns ALLOWED / NEEDS HUMAN APPROVAL / BLOCKED and reuses the client:
Framework | Install | Import |
LangChain |
|
|
CrewAI |
|
|
LlamaIndex |
|
|
OpenAI Agents SDK |
|
|
from qorami_langchain import build_qorami_tool
tool = build_qorami_tool() # reads QORAMI_API_KEYNo-code workflows (n8n) use a plain HTTP Request node — see n8n/.
Register Qorami as a native tool in Claude Desktop / Cursor / any MCP client —
see mcp/. It exposes qorami_health, verify_email and check_action_status over stdio.
Every client returns the same decision the agent must obey via nextAction.type:
send, request_human_confirmation (a human approves first — poll the action),
or do_not_send. See https://qorami.fr/docs.
When an email is risky only because of mechanically-removable content (a leaked
secret, a suspicious link, an IBAN/card/SSN), the verify result carries a cleaned,
sendable copy — send remediation.safeBody instead of blocking outright:
const r = await qorami.verify({ recipient, subject, body, policyProfile: 'general' })
if (r.nextAction.type === 'do_not_send' && r.remediation?.safeToSend) {
mailer.send({ ...email, body: r.remediation.safeBody }) // safe, redacted copy
}r = qorami.verify(recipient=..., subject=..., body=email_body)
if r.next_action_type == "do_not_send" and (r.remediation or {}).get("safeToSend"):
send_email(body=r.remediation["safeBody"]) # safe, redacted copyremediation.removed lists what was stripped (e.g. ["secret", "link"]). The MCP
server surfaces the same field.
MIT — see LICENSE.
After request_human_confirmation, poll this with the actionId until nextAction.type becomes "send" (approved) or "do_not_send" (blocked).
| Name | Required | Description | Default |
|---|---|---|---|
| actionId | Yes | The action id returned by verify_email |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes polling behavior and termination conditions without annotations; no side effects noted but read-only implied.
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?
Single sentence front-loaded with usage context, every word 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?
Complete for a simple polling tool with one parameter and no output schema; clearly explains termination condition.
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 already defines actionId well; description only references it ('poll this with the actionId'), adding no extra semantic depth.
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 specifies polling an actionId until a terminal state ('send' or 'do_not_send') is reached, clearly distinguishing from sibling tool verify_email.
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 states 'After request_human_confirmation, poll this' and outlines expected outcomes, though lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before sending ANY email, call this to get permission from Qorami. Returns a decision the agent MUST obey: send (allowed), request_human_confirmation (a human must approve first — then poll check_action_status), or do_not_send (blocked). When not allowed, "suggestions" says what to fix.
| Name | Required | Description | Default |
|---|---|---|---|
| recipient | Yes | Recipient email address | |
| subject | Yes | Email subject | |
| body | Yes | Full email body | |
| policyProfile | No | Risk profile (default general) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the decision outcomes and the 'suggestions' field for fixes. However, it does not disclose whether the tool has side effects (e.g., logging) or authorization requirements, leaving some behavior opaque.
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 extremely concise at two sentences, front-loaded with the most critical usage instruction. Every part is necessary and clear.
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?
Despite the absence of an output schema, the description explains the key return values and their meanings. A decision tool with multiple outcomes is adequately covered, though it could mention the format of 'suggestions' or any error conditions.
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 parameters are well-documented in the schema. The description does not add any extra semantics beyond what the schema provides. The 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?
The description clearly states the tool's purpose: to get permission before sending emails. It specifies the three possible return values (send, request_human_confirmation, do_not_send) and how the agent must obey. This distinguishes it from the sibling tool check_action_status, which is referenced for polling.
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 instructs to call this tool 'before sending ANY email', providing clear usage guidance. It also tells the agent what to do based on the response: obey the decision, and if not allowed, use suggestions to fix. It references the sibling tool for following up on human confirmation.
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.
v1.0.0check_action_statusverify_emailScored across 2 tools
The two tools have clearly distinct purposes: verify_email handles the initial permission check, and check_action_status polls the result of a human confirmation request. There is no overlap.
Both tool names follow the verb_noun pattern (verify_email, check_action_status) and use snake_case consistently.
With only 2 tools, the set is on the thin side for a standalone MCP server, but it covers the core email verification workflow without unnecessary additions.
The tools cover the entire permission lifecycle: initial decision via verify_email and subsequent polling for human confirmation via check_action_status. No obvious gaps for the intended domain.
Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.
Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.
Governed email for AI agents (Mailbuttons / mbag.ai): sandbox inboxes, policy gate, audit log.
Stateful email for AI agents — read inboxes, reply in-thread, draft with approval.
