agentmail
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AGENTMAIL_FIVESIM_KEY | No | API key for 5sim SMS provider. Required if AGENTMAIL_SMS_PROVIDER is set to fivesim. | |
| AGENTMAIL_SMS_PROVIDER | No | SMS provider backend: mock (default, no key needed for dev), fivesim (requires AGENTMAIL_FIVESIM_KEY), twilio (requires TWILIO keys). | mock |
| AGENTMAIL_COMPLIANCE_PROVIDER | No | Compliance provider backend: osint (default, real OFAC data, free), mock (rule-based, for offline tests), paid (ComplyAdvantage passthrough, roadmap). | osint |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_inbox | Create a fresh disposable email inbox (or reuse an existing one by label). Use this when an agent needs an email address to sign up / receive a verification message. Returns the address. Poll fetch_code to get the OTP. |
| fetch_code | Fetch the latest verification code/link from an inbox.
|
| list_inboxes | List all existing labeled inboxes/numbers. |
| create_number | Rent a phone number that can receive SMS/OTP codes. Use this when an agent must verify via phone (WhatsApp, Telegram, banks,
apps requiring SMS). Returns the rented |
| fetch_sms | Fetch the latest SMS (OTP) for a labeled number. Polls up to |
| release_number | Stop renting a phone number and free it. Call when you're done with OTP. |
| kya_verify | Verify an AI agent's identity before transacting with it (Know Your Agent). Call BEFORE paying or trusting another agent. Returns a trust score + flags. evidence keys (any subset): wallet_address, wallet_age_days, domain, pubkey, owner_email, declared_country. Higher trust = more verified attributes and a clean sanctions screen. Use the returned recommendation to decide whether to proceed with a counterparty agent. Returns: {trust_score: 0-100, verified: [...], flags: [...], recommendation} |
| risk_scoreA | Score a transaction's fraud risk BEFORE authorizing payment. Call right before an agent pays. Combines counterparty signals + amount anomalies + sanctions screen + rail/category heuristics. Recommendation is one of: allow / review / decline. 'decline' = abort the payment. rail in: x402, ap2, acp, tap. category in: digital_goods, services, physical. Returns: {score: 0-100, recommendation, reasons: [...], screen_id} |
| sanctions_check | Screen a counterparty against OFAC/EU/UN/UK sanctions lists. Cheapest check, call first. At least one of name / wallet / country required. Free provider uses open sanctions data (no key). Useful as a fast pre-filter before the heavier risk_score call. Returns: {matches: [{list, entity, match_type, confidence}], clean: bool} |
| dispute_open | Open a dispute when an agent-paid transaction went bad (non-delivery, fraud). Records the dispute with a 7-day auto-escalation window. Phase 1 = registry
|
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 1 tool
With only one tool, there is no possibility of confusion between tools. The single tool has a clear, specific purpose.
Although there is only one tool, its name 'risk_score' is descriptive and follows a reasonable noun_noun pattern. No inconsistencies exist.
A single tool is borderline for a server. However, the tool is focused on a critical, well-defined action (fraud scoring before payment), so it is not overly thin.
The server only provides scoring before payment, but agents may need to retrieve past screening results or update risk profiles, which are missing. This limits the server's utility for complex workflows.