Skip to content
Gauge

ax-check.com

by Gauge

comail

comail.io

ax-check.com

Checked 19 September 2026

B

83/100

Agents need your login

Comail's docs give agents a clear MCP setup and upfront pricing

llms.txt spells out MCP config, auth, and $39/month-per-inbox pricing (up to 10 agents) with no gating; homepage just won't serve Markdown directly.

2 fixes to start with

Concrete changes, backed by what we found.

Onboarding

Give agents a clear login handoff and a way to resume setup.

Agents cannot progress through onboarding without human help. Provide an agent-accessible path through authentication and setup.

Docs

Return Markdown when clients request text/markdown.

Homepage returned text/html even when Markdown was requested via Accept header.

Recorded coding sessions

Same task, 3 models, no comail.io account. Recorded 19 September 2026 on Pi.

3 recorded · 2m 40s

2m 40s · recorded

Session findings

Select a finding to see it in context.

piv0.84.2
modelQwen 3.8 Maxcwd/sandbox/repo
Help me build a simple example using comail. Tell me how pricing works, and briefly tell me whether this product will be easy for you to manage. Let me know if you get blocked. If this product has no developer workflow you can act on, say so plainly and stop. Stay light: use the hosted product through its SDK or API. Do not start local service stacks or wait for long-running commands; if the quickstart requires either, say so plainly and stop.
Thinking…

Let me look at the repo to see what "comail" is.

$ ls -la /sandbox/repo && cat /sandbox/repo/README* 2>/dev/null | head -50{"content":[{"text":"total 16\ndrwxr-xr-x 3 root root 4096 Sep 18 08:00 .\ndrwxr-xr-x 7 root root 4096 Sep 19 08:27 ..\ndrwxr-xr-x 8 root root 4096 Sep 18 08:00…ctrl+o
{"content":[{"text":"total 16\ndrwxr-xr-x 3 root root 4096 Sep 18 08:00 .\ndrwxr-xr-x 7 root root 4096 Sep 19 08:27 ..\ndrwxr-xr-x 8 root root 4096 Sep 18 08:00 .git\n-rw-r--r-- 1 root root  408 Sep 18 08:00 .gitignore\n","type":"text"}]}
Thinking…

Empty repo. "comail" — I don't know this product. Let me check for any docs, MCP tools, etc. Check environment for tooling.

$ cd /sandbox/repo && git log --oneline | head; ls -a; env | grep -i -E "comail|PI_" | head -30{"content":[{"text":"9ebf5fb Initial workspace\n.\n..\n.git\n.gitignore\nPI_CODING_AGENT=true\nPI_REASONING_LEVEL=medium\nPI_SESSION_FILE=/sandbox/.gauge/pi/ses…ctrl+o
{"content":[{"text":"9ebf5fb Initial workspace\n.\n..\n.git\n.gitignore\nPI_CODING_AGENT=true\nPI_REASONING_LEVEL=medium\nPI_SESSION_FILE=/sandbox/.gauge/pi/sessions/2026-09-19T08-27-09-844Z_01a0b8c6-c694-7d95-8086-c6af58b38fc7.jsonl\nPI_PROVIDER=gauge-fireworks\nPI_MODEL=accounts/fireworks/models/qwen3p8-max\nPI_SESSION_ID=01a0b8c6-c694-7d95-8086-c6af58b38fc7\nPI_GATEWAY_API_KEY=unused\n","type":"text"}]}
Thinking…

No comail package locally. Check network access / npm registry for "comail".

$ cd /tmp && timeout 30 npm view comail 2>&1 | head -30; echo "---pypi---"; timeout 30 curl -s https://pypi.org/pypi/comail/json | head -c 300; echo; echo "---net---"; timeout 15 curl -sI https://exampl…{"content":[{"text":"npm error code E404\nnpm error 404 Not Found - GET https://registry.npmjs.org/comail - Not found\nnpm error 404\nnpm error 404 'comail@*' …ctrl+o
cd /tmp && timeout 30 npm view comail 2>&1 | head -30; echo "---pypi---"; timeout 30 curl -s https://pypi.org/pypi/comail/json | head -c 300; echo; echo "---net---"; timeout 15 curl -sI https://example.com | head -3

{"content":[{"text":"npm error code E404\nnpm error 404 Not Found - GET https://registry.npmjs.org/comail - Not found\nnpm error 404\nnpm error 404  'comail@*' is not in this registry.\nnpm error 404\nnpm error 404 Note that you can also install from a\nnpm error 404 tarball, folder, http url, or git url.\nnpm error A complete log of this run can be found in: /sandbox/.npm/_logs/2026-09-19T08_27_23_191Z-debug-0.log\n---pypi---\n{\"message\": \"Not Found\"}\n---net---\nHTTP/2 200 \r\ndate: Sat, 19 Sep 2026 08:27:24 GMT\r\ncontent-type: text/html\r\n","type":"text"}]}
Thinking…

Network works, but "comail" doesn't exist on npm or PyPI. Maybe it's "comail.com"? Let me check quickly — a couple of quick lookups, not long-running.

$ cd /tmp && for u in https://comail.com https://comail.io https://www.comail.com; do echo "== $u"; timeout 12 curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" $u; done; timeout 15 curl -s "h…{"content":[{"text":"== https://comail.com\n== https://comail.io\n200 https://comail.io/\n== https://www.comail.com\n{\"objects\":[],\"total\":0,\"time\":\"2026…ctrl+o
cd /tmp && for u in https://comail.com https://comail.io https://www.comail.com; do echo "== $u"; timeout 12 curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" $u; done; timeout 15 curl -s "https://registry.npmjs.org/-/v1/search?text=comail&size=5" | head -c 500

{"content":[{"text":"== https://comail.com\n== https://comail.io\n200 https://comail.io/\n== https://www.comail.com\n{\"objects\":[],\"total\":0,\"time\":\"2026-09-19T08:27:54.890Z\"}","type":"text"}]}
Thinking…

comail.io resolves 200. Let's see what it is — maybe a parking page. Fetch content.

$ cd /tmp && timeout 20 curl -sL https://comail.io/ | head -c 2000{"content":[{"text":"<!doctype html>\n<html lang=\"en\">\n<head>\n<meta charset=\"utf-8\">\n<meta name=\"viewport\" content=\"width=device-width, initial-scale=…ctrl+o
{"content":[{"text":"<!doctype html>\n<html lang=\"en\">\n<head>\n<meta charset=\"utf-8\">\n<meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">\n<title>comail — scoped Gmail access for AI agents</title>\n<meta name=\"description\" content=\"Your AI agents each see one slice of Gmail — the threads carrying their label — and nothing else. comail is the permission layer in between. Nothing to install in Gmail.\">\n<link rel=\"canonical\" href=\"https://comail.io/\">\n\n<meta property=\"og:type\" content=\"website\">\n<meta property=\"og:url\" content=\"https://comail.io/\">\n<meta property=\"og:title\" content=\"comail — scoped Gmail access for AI agents\">\n<meta property=\"og:description\" content=\"Each agent sees one slice of your Gmail, and nothing else. Scope it by label, sender or domain. No plugin required.\">\n<meta property=\"og:image\" content=\"https://comail.io/assets/og.png\">\n<meta property=\"og:image:width\" content=\"1200\">\n<meta property=\"og:image:height\" content=\"630\">\n<meta name=\"twitter:card\" content=\"summary_large_image\">\n<meta name=\"theme-color\" content=\"#0b0c0f\">\n\n<link rel=\"icon\" href=\"/assets/favicon.svg\" type=\"image/svg+xml\">\n<link rel=\"apple-touch-icon\" href=\"/assets/apple-touch-icon.png\">\n<link rel=\"preload\" href=\"/assets/fonts/inter-100-900.woff2\" as=\"font\" type=\"font/woff2\" crossorigin>\n<link rel=\"stylesheet\" href=\"/assets/styles.css?v=5\">\n\n<!-- ~2 KB, same origin. Blocking so the `js` class lands before first paint.\n     Bump ?v= when the file changes: assets are edge/browser-cached, HTML is not. -->\n<script src=\"/assets/main.js?v=8\"></script>\n<script defer data-domain=\"comail.io\" src=\"https://plausible.ninibe.com/js/script.js\"></script>\n</head>\n<body>\n\n<a class=\"skip\" href=\"#main\">Skip to content</a>\n\n<header class=\"header\" id=\"header\">\n  <div class=\"wrap header__in\">\n    <a class=\"logo\" href=\"/\" aria-label=\"comail home\">\n      <span class=\"logo__co\">co</span><span class=\"logo__dots\" aria-hidden=\"true\">:</span><span class=\"logo__mail\">mail</span>\n    </a>\n    <nav class=\"nav\" ari","type":"text"}]}
Thinking…

Let me fetch the docs, pricing pages. Look for /docs, /pricing, /quickstart.

$ cd /tmp && timeout 20 curl -sL https://comail.io/ > c.html; grep -oE 'href="[^"]+"' c.html | sort -u | head -40{"content":[{"text":"href=\"#agents\"\nhref=\"#explicit\"\nhref=\"#features\"\nhref=\"#how\"\nhref=\"#main\"\nhref=\"#notifications\"\nhref=\"#pricing\"\nhref=\…ctrl+o
{"content":[{"text":"href=\"#agents\"\nhref=\"#explicit\"\nhref=\"#features\"\nhref=\"#how\"\nhref=\"#main\"\nhref=\"#notifications\"\nhref=\"#pricing\"\nhref=\"#waitlist\"\nhref=\"/\"\nhref=\"/assets/apple-touch-icon.png\"\nhref=\"/assets/favicon.svg\"\nhref=\"/assets/fonts/inter-100-900.woff2\"\nhref=\"/assets/styles.css?v=5\"\nhref=\"/cdn-cgi/l/email-protection\"\nhref=\"/llms.txt\"\nhref=\"/privacy\"\nhref=\"https://comail.io/\"\n","type":"text"}]}
Thinking…

There's a /llms.txt. And #pricing, #waitlist. Let me read llms.txt and the pricing section text.

$ cd /tmp && timeout 20 curl -sL https://comail.io/llms.txt{"content":[{"text":"# comail\n\n> comail is an authorization layer between a Gmail mailbox and the AI agents that read and write it over MCP. Each agent sees o…ctrl+o
{"content":[{"text":"# comail\n\n> comail is an authorization layer between a Gmail mailbox and the AI agents that read and write it over MCP. Each agent sees one slice of each mailbox it reaches — the threads carrying its label — and nothing else. comail checks the agent's two Gmail labels against the thread on every request before it calls the Gmail API.\n\ncomail supports Gmail and Google Workspace accounts. It is in private beta.\n\nAgents can receive semi-realtime notifications when accessible mail is available,\nincluding newly shared mail, using ordinary HTTP requests.\n\n## Architecture\n\nThe mailbox owner grants comail an OAuth authorization on their Google account, once,\nfrom the web dashboard. Installing the Gmail add-on is optional and grants nothing extra.\n\nAn owner may connect several mailboxes to one comail account. Each is a separate\nauthorization, disconnected on its own.\n\ncomail holds those grants. Agents do not. Each agent is issued its own MCP endpoint URL\nand its own bearer key, and authenticates to comail rather than to Google. comail calls\nthe Gmail API on the agent's behalf, and only on threads that agent's labels permit.\nOne agent, one key and one endpoint may cover several of the owner's mailboxes; the\nagent's access to each of them is a separate binding.\n\nRevoking an agent invalidates its key. It does not affect any other agent, and it does\nnot require the owner to re-authorize the mailbox.\n\n## Objects\n\n**Agent** — a named identity that may access one or more of the owner's connected\nmailboxes. Has a status (active, suspended, revoked, pending setup), agent-wide\n`draft` / `send` / `modify` defaults, an MCP endpoint, and a key. Its access to each\nmailbox is a separate binding.\n\n**Binding** — one agent's access to one mailbox: the agent's two Gmail labels in that\nmailbox, a default `view` policy for it, and a paused flag. A mailbox carries any number\nof agents; an agent spans any number of mailboxes; each (agent, mailbox) pair has exactly\none binding. Adding, removing or pausing a binding leaves the agent's other bindings and\nits key untouched.\n\n**Ruleset** — optional, one per agent. An ordered list of rules that keep the agent's\nlabels applied on the owner's behalf. Rules never grant access directly; they only\nwrite labels.\n\n**Rule** — a `(policy, target)` pair. `policy` is `allow` or `deny`. `target` is a\nparticipant email address, a participant domain, one of the owner's own Gmail labels,\nor a single thread.\n\n**Pending action** — an action an agent requested that requires owner approval before\nit takes effect. Currently: sending a message.\n\n## Access model\n\nEvery agent owns exactly two Gmail labels:\n\n- `co:<agent-name>` — grants a thread to that agent\n- `no-co:<agent-name>` — withholds a thread from that agent\n\nand one default policy, `allow` or `deny`, for threads carrying neither.\n\nFor a given agent and thread, `view` resolves in this order, first match winning:\n\n1. The thread carries `no-co:<agent-name>` — denied.\n2. The thread carries `co:<agent-name>` — allowed.\n3. Otherwise — the agent's default policy.\n\nTwo setups follow from the default:\n\n- **Allow-list** (default `deny`) — the agent reads only threads carrying its `co:` label.\n- **Deny-list** (default `allow`) — the agent reads the mailbox except threads carrying\n  its `no-co:` label.\n\n`no-co:` outranks `co:` in both, so a label applied by hand always withholds a thread,\nincluding one a rule granted.\n\nThis is evaluated against the thread's current labels on every request. There is no\nsnapshot and no separate index. Applying a label grants a thread on the agent's next\ncall; removing it revokes the thread on the agent's next call.\n\n## Several mailboxes, one agent\n\nAn agent's access to each mailbox is decided independently. The two labels carry the\nsame names in every mailbox the agent reaches (`co:<agent-name>`, `no-co:<agent-name>`),\nbut they are that mailbox's own labels, and the default policy is set per mailbox. The\nsame agent can therefore be an allow-list on one mailbox and a deny-list on another.\n\n`draft` / `send` / `modify` remain agent-wide: they say what the agent may do wherever it\ncan already see a thread.\n\nEvery mail tool takes a `mailbox` argument naming one of the addresses the agent reaches.\nAn agent bound to a single mailbox may omit it. An agent bound to several must supply it;\na call without it is refused rather than guessed at. `list_mailboxes` returns the\naddresses the agent reaches, its permissions, and whether each one is paused.\n\n**Pausing.** The owner can pause an agent in one mailbox or in all of them, from the\ndashboard. A paused binding refuses every operation on that mailbox — comail does not\nopen the mailbox at Google at all — while the agent's other bindings keep working\nnormally. The key, the labels, the default policy and the permissions all survive a\npause, so resuming restores exactly the previous access and requires no reconfiguration\non the agent's side. Scheduled sends held by a paused binding wait rather than going out,\nand remain cancellable while paused. Pausing is not revocation: it is reversible, it can\napply to a single mailbox, and it does not invalidate the key.\n\n## Applying the labels\n\nFour equivalent ways, because the label is the only thing comail reads:\n\n- by hand, in any Gmail client, including mobile\n- by a Gmail filter the owner already wrote\n- from the comail web dashboard, or from the optional Gmail add-on\n- by a comail rule, which comail evaluates against arriving and changing threads and\n  uses to keep the agent's labels applied\n\nRules are automation, not a second source of truth. Their only effect is to write labels.\n\nGmail can hide a label from the label list and from the message list, independently.\ncomail's labels are hidden on creation. The owner may show either label for any agent.\n\n## Permissions\n\n| Permission | Grants | Scoped by | Approval gate |\n| --- | --- | --- | --- |\n| `view` | Search, list and read threads | The agent's `co:` and `no-co:` labels, and its default policy | none |\n| `draft` | Create and edit drafts | Agent-wide default | none |\n| `send` | Deliver mail from the owner's address | Agent-wide default | optional: hold every send |\n| `modify` | Apply labels, archive, mark read | Agent-wide default | optional |\n\n`view` is the only permission scoped per thread. The others are agent-wide switches.\nAn agent cannot draft, send or modify a thread it cannot view, so the labels bound\neverything else.\n\nAn agent holding `modify` may write labels on threads it can already view. It cannot\nwrite any label beginning `co:` or `no-co:`.\n\n## How rules write labels\n\nA rule is matched against a thread when the thread arrives and when it changes. Rules\nare ordered and the first match wins. An `allow` match applies `co:<agent-name>` to the\nthread. A `deny` match applies `no-co:<agent-name>`. A thread matching no rule is left\nalone and falls to the agent's default policy.\n\nA rule matches a thread when its target matches any participant on that thread (for\naddress and domain targets), any label on that thread (for label targets), or the\nthread's id (for thread targets).\n\nOrder matters. `deny label:Board` placed above `allow domain:acme.com` withholds a board\nthread whose participants are on the company domain. Reversing the two shares it.\n\nBecause participants can be added to a thread after it arrives, a rule can withdraw a\nthread the agent could previously read. A label the owner set by hand is never overwritten\nby a rule.\n\n## Inspecting an agent's scope\n\nSearching `label:\"co:<agent-name>\"` in any Gmail client returns exactly the set of threads\nthat agent can read, if it is an allow-list agent. For a deny-list agent, searching\n`-label:\"no-co:<agent-name>\"` returns the same.\n\nThis requires no comail surface and works on mobile. It is the intended way to audit an\nagent.\n\n## MCP interface\n\nStandard Model Context Protocol over HTTP. Any MCP client can connect: Claude, Cursor,\nor a custom agent. There is no comail SDK.\n\n```json\n{\n  \"mcpServers\": {\n    \"inbox-investors\": {\n      \"url\": \"https://mcp.comail.io/a/investor-relations\",\n      \"headers\": { \"Authorization\": \"Bearer cml_live_...\" }\n    }\n  }\n}\n```\n\nEvery mail tool takes a `mailbox` argument, required of an agent that reaches more than\none mailbox and optional otherwise.\n\n| Tool | Effect | Requires |\n| --- | --- | --- |\n| `list_mailboxes` | List the mailboxes this agent reaches, its permissions, and any paused ones | none |\n| `create_notification_url` | Create a one-hour notification URL scoped to this agent and one mailbox | authenticated agent with mailbox access |\n| `search_threads` | Search the mailbox | `view` |\n| `get_thread` | Read a thread and its messages | `view` |\n| `create_draft` | Create a draft or a reply | `draft` |\n| `update_draft` | Revise a draft the agent created | `draft` |\n| `send_message` | Send a draft | `send`, or enqueued as a pending action |\n| `modify_labels` | Apply labels, archive, mark read | `modify` |\n\nThreads an agent cannot view are absent from its search results. Fetching one by id\nreturns an authorization error, not a redacted document.\n\nIf `send` is gated on approval, `send_message` creates a pending action and returns\nwithout delivering. The owner approves, edits or rejects it. Revoking an agent cancels\nits pending actions.\n\n## Mailbox notifications\n\nOnce Gmail is connected and the agent has access through comail, it can receive\nsemi-realtime mailbox notifications with no additional notification setup, as long as\nit can make HTTP requests. No customer webhook server, public endpoint, or extra\nGoogle Cloud configuration is required.\n\n1. Call `create_notification_url` through the agent's authenticated MCP connection\n   for the mailbox it wants to follow.\n2. Listen at the returned URL using HTTP streaming (server-sent events, SSE) or\n   JSON long polling.\n3. Fetch permitted email content through comail's authenticated tools and act within\n   the agent's current permissions.\n\nSet `NOTIFICATION_URL` to the returned URL and choose one transport:\n\n```sh\n# Streaming (SSE)\ncurl -N -H 'Accept: text/event-stream' \"$NOTIFICATION_URL\"\n\n# JSON long polling\ncurl \"$NOTIFICATION_URL\"\n```\n\nEach notification URL is scoped to one agent and one mailbox and lasts one hour.\nThe agent requests a fresh URL through authenticated MCP to keep listening.\n\nNotifications contain only opaque mailbox and message IDs, not email content.\nThey respect the agent's current mailbox permissions, including newly shared mail.\nRetrieving email content through authenticated tools remains subject to current access.\n\nAgents can reconnect and resume using a cursor. Notification history is retained for\n24 hours. Delivery may repeat, so clients deduplicate notifications before acting.\nDelivery is semi-realtime; latency is not guaranteed.\n\nUse cases include monitoring accessible threads in a shared support inbox, detecting\nnewly assigned email, and starting an agent workflow when accessible mail arrives.\n\n## Management MCP\n\nA second MCP endpoint, separate from the per-agent endpoints, for delegated setup: an\nagent connected to it can list, create, suspend and revoke agents, give an agent\nanother of the owner's mailboxes or take one away, switch their defaults, and create the\ncomail rules that route mail to agents. It can delete only\nrules it created itself. It cannot read or write mail, and it cannot touch labels,\nfilters or rules the owner created themselves — even ones that look identical to its\nown.\n\nIt authenticates with its own management key and is off by default. The owner enables\nit from the dashboard for 60 minutes at a time; it disables itself when the window\nexpires, and one click disables it sooner. The key survives disabling, so re-enabling\nneeds no reconfiguration. Every management call is recorded in the audit log.\n\nThe time-box exists because the agent doing the setup may be the same agent that reads\nmail as a regular agent afterwards — with standing management access it could widen its\nown scope. Enable, let it set things up, disable.\n\n## Control surfaces\n\nThere are three, and the first is Gmail.\n\n**Gmail.** Adding or removing an agent's `co:` or `no-co:` label on a thread grants or\nwithholds that thread, from any Gmail client, including mobile. Gmail filters can apply\nthe labels on delivery. Gmail's label visibility settings control whether the owner sees\nthem. No comail surface is involved.\n\n**The web dashboard.** Mailbox connections, agents, keys, default policies, which\nmailboxes an agent reaches and whether it is paused in one of them or all of them,\n`draft` / `send` / `modify` defaults, rules, the management-access toggle, the approval\nqueue, the full audit log with search and filters, and billing. Everything Gmail has\nnowhere to put.\n\n**The Gmail add-on.** Optional. A contextual surface for the thread the owner is\nreading: why an agent can or cannot see this thread, the approval queue, and internal\nmessages between the owner and an agent. It shows recent activity only.\n\nEvery access decision is recorded: the agent, the action, the target, the result, and\nwhich label or default policy produced it.\n\n## Pricing\n\n$39 per month, per inbox, for up to 10 agents. This is the early-bird rate for the\nprivate beta. Beta users keep $39 per month after general launch, for as long as the\nsubscription stays active. Billing starts when the inbox is provisioned.\n\n## Access\n\nPrivate beta, onboarding in batches. Applications are taken at <https://comail.io/#waitlist>\nand require an email address and, optionally, a description of the intended use.\n\n## History\n\ncomail launched in 2015 as a shared-inbox tool. It let a mailbox owner give another\nperson scoped access to their mail, using allow/deny rules over senders, domains and\nlabels, and an approval queue for outbound mail. The rule engine is carried over, but it\nnow writes Gmail labels rather than deciding access itself. The collaborators are now\nagents.\n","type":"text"}]}
Thinking…

Key facts: private beta, no SDK, MCP-only, requires waitlist application, owner OAuth grant from web dashboard, keys issued from dashboard. So I cannot act: no API keys, no public SDK, requires manual onboarding via waitlist and dashboard OAuth. Pricing: $39/month per inbox up to 10 agents, early-bird, locked for beta users, billing starts when inbox provisioned.

Per instructions: "If this product has no developer workflow you can act on, say so plainly and stop." That applies. Should I check if there's an API/docs endpoint? Quick check maybe. Let me check for /docs or api.comail.io quickly — one quick check.

$ cd /tmp && for u in https://comail.io/docs https://docs.comail.io https://api.comail.io https://mcp.comail.io/; do printf "%s -> " $u; timeout 12 curl -sIL -o /dev/null -w "%{http_code}\n" $u; done{"content":[{"text":"https://comail.io/docs -> 404\nhttps://docs.comail.io -> 000\nhttps://api.comail.io -> 000\nhttps://mcp.comail.io/ -> 000\n\n\nCommand exit…ctrl+o
{"content":[{"text":"https://comail.io/docs -> 404\nhttps://docs.comail.io -> 000\nhttps://api.comail.io -> 000\nhttps://mcp.comail.io/ -> 000\n\n\nCommand exited with code 6","type":"text"}],"details":{}}
Thinking…

No docs site, no api host reachable, mcp host doesn't resolve (only subpaths presumably, but host doesn't resolve at all). So blocked. Stop.

Write a brief answer. No files created (repo untouched). Maybe I could write a config snippet example for the user? Instructions say build a simple example but if no developer workflow to act on, say so plainly and stop. So don't build. But I can show what the config would look like — brief. Keep it light. I'll say plainly stopped, no code written.

Actually maybe I should note one thing: MCP client config is the only artifact, and it needs a key from the dashboard. Keep concise.

Blocked — stopping here

I could not build a working example. comail has no developer workflow I can act on from this sandbox.

What I checked (read-only, no services started):

  • /sandbox/repo — empty (just .gitignore, one commit)
  • npm: comail → 404, not in registry; PyPI: not found; npm search for "comail" → 0 results
  • https://comail.io/ → live marketing site, plus https://comail.io/llms.txt (a full product spec — that's what I read)
  • https://comail.io/docs → 404; docs.comail.io, api.comail.io, mcp.comail.io → do not resolve
  • No COMAIL_* credentials in the environment

Why it's not actionable:

  1. There is no SDK and no REST API. llms.txt states it explicitly: "Standard Model Context Protocol over HTTP... There is no comail SDK." The only interface is MCP endpoints of the form https://mcp.comail.io/a/<agent-name> with a Bearer cml_live_... key.
  2. Keys cannot be self-served. They're issued per-agent from the web dashboard, after the mailbox owner completes an OAuth grant on their Google account from that dashboard. No signup flow, no CLI, no comail init.
  3. Private beta, waitlist-gated. Access requires applying at https://comail.io/#waitlist and waiting to be onboarded in batches. I can't get a key or a connected mailbox, so any example I wrote would be unverifiable fiction.

The only artifact that would exist is a static MCP client config stub:

{
  "mcpServers": {
    "support-agent": {
      "url": "https://mcp.comail.io/a/support-agent",
      "headers": { "Authorization": "Bearer cml_live_<from-dashboard>" }
    }
  }
}

That's a placeholder with a key I cannot obtain, so I did not write it into the repo. Repo is untouched.

Pricing

  • $39/month per inbox, covering up to 10 agents.
  • This is the early-bird private-beta rate. Beta users keep $39/month after general launch, for as long as the subscription stays active.
  • Billing starts when the inbox is provisioned (not when you join the waitlist).
  • The unit is the inbox, not the agent — extra agents within the 10 are free; a second connected mailbox would be another $39.

Would this be easy for me to manage?

Not currently — blocked at the front door, but the design itself looks agent-friendly.

Hard blockers today: no self-serve credentials, no SDK/API, no public docs, waitlist-only. Everything requires a human in the web dashboard (OAuth grant, key issuance, agent creation, toggles).

Once someone hands me a key, though, the model is unusually well suited to an agent:

  • Management MCP is built exactly for delegated setup — an agent can create/suspend/revoke agents, add/remove mailbox bindings, switch defaults, and write routing rules. It's off by default and the owner enables it for 60-minute windows, which is a sensible guard against an agent widening its own scope.
  • Notifications need no infrastructure: create_notification_url returns a one-hour SSE/long-poll URL — no webhook server, public endpoint, or GCP config. (Caveat: listening on it is a long-running stream, which conflicts with your "don't wait on long-running commands" constraint; I'd use one short poll instead.)
  • Auditing is trivial and out-of-band: label:"co:<agent-name>" in any Gmail client shows exactly what an agent can read.

Friction I'd expect even with a key: label-based access (co: / no-co: per thread) means most testing needs a real Gmail mailbox with labels applied by hand or by rules; sends can be gated behind an owner approval queue; and management access expires hourly, so setup work has to be batched into short windows.

AX Fundamentals

23 checks. Open an area for details.

This check is a quick preview. Test more tasks and models with Gauge Agents.

Test your product with Gauge Agents

AX Check by Gauge