
Winnr
app.winnrv0.6.1Updated Oct 7, 2026
Cold email infrastructure: buy domains, create SMTP mailboxes, set DNS, run warming, read mail.
Overview
Lets an assistant manage cold-email infrastructure: buy domains, create SMTP mailboxes, configure DNS, run warming, and read or send mail.
- What it does
- Winnr exposes the Winnr cold-email infrastructure API as 55 tools, 26 of them read-only, plus 8 resources and 5 prompt playbooks. Assistants can list and inspect domains, mailboxes, inbox messages, warming metrics, pre-warmed marketplace listings, jobs and webhooks; create or delete domains and mailboxes; send email; and run DNS provisioning and verification. Four tools charge the card: domain purchase, two pre-warmed purchase tools, and enabling warming.
- When to use it
- Use it when an assistant should operate a cold-email setup end to end: provisioning domains and mailboxes, checking DNS and warming health, triaging replies, or buying pre-warmed domains. Read-only tokens suit reporting and reply triage without any write or spending capability.
- Requirements
- Remote endpoint at with OAuth 2.1 + PKCE sign-in, or local run via uvx winnr-mcp (or pip install winnr-mcp) over stdio. Local use needs uv and a Winnr API token in WINNR_API_TOKEN; optional WINNR_API_URL, WINNR_TIMEOUT, WINNR_READ_ONLY, WINNR_NO_PURCHASES, WINNR_CONFIRM_SECRET. Network access to the Winnr API.
Installation
In SourceWeft
- Open Winnr in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Other MCP clients
Add this to your client's mcpServers config.
{
"mcpServers": {
"winnr": {
"type": "http",
"url": "https://mcp.winnr.app/mcp"
}
}
}README
winnr-mcp
MCP server for the Winnr cold-email infrastructure API.
Lets Claude (web, mobile and desktop), ChatGPT, Claude Code, Cursor, Windsurf, VS Code (Copilot) and any other MCP client manage your domains, mailboxes, warming, inbox, pre-warmed marketplace and webhooks through natural language.
55 tools, 26 of them read-only, plus 8 resources and 5 prompt playbooks.
Two ways to run it:
Setup either way: app.winnr.app/mcp.
Hosted server
Add https://mcp.winnr.app/mcp as a custom connector / remote MCP server. The client
registers itself (RFC 7591), sends you to Winnr to sign in, and you choose what it may do:
Scopes imply each other (purchase ⊃ write ⊃ read), and a session only ever sees
the tools its scopes allow. Each grant is backed by a normal API token named
MCP · <client>, so it appears on the dashboard's API page and revoking it there cuts
the assistant off.
Quick start (local)
1. Get a token
app.winnr.app/mcp (or API → Create Token). Tokens start with
wnr_. Pick read-only if you only want reports and reply triage: every tool that
creates, sends, buys or deletes is then hidden from the assistant. Add
WINNR_NO_PURCHASES=true (or --no-purchases) to keep full write access while hiding the
four tools that charge the card.
2. Install uv
The server runs with uvx, so uv must be installed once:
No uv? pip install winnr-mcp and use "command": "winnr-mcp" with no args instead.
3. Add the server to your client
Claude Desktop
Settings → Developer → Edit Config, then paste (macOS
~/Library/Application Support/Claude/claude_desktop_config.json, Windows
%APPDATA%\Claude\claude_desktop_config.json). Fully quit and reopen Claude.
Claude Code
Then /mcp inside Claude Code shows Winnr as connected. Optional guided workflows
(/winnr setup, /winnr health, /winnr export) come from
winnr-claude-skills:
Cursor
~/.cursor/mcp.json (global) or .cursor/mcp.json (project) — same JSON as Claude
Desktop. Settings → MCP shows Winnr with a green dot when it is up.
Windsurf
~/.codeium/windsurf/mcp_config.json — same JSON. Refresh in Settings → Cascade → MCP Servers.
VS Code (Copilot agent mode)
.vscode/mcp.json:
4. Try it
What's in my Winnr account, and how much capacity do I have left?
The assistant calls winnr_get_account and winnr_get_usage. The
app.winnr.app/mcp page flips to Connected once the
token has been used.
Configuration
CLI args take precedence over environment variables.
At startup the server calls GET /v1/account. An invalid token exits immediately with
a clear message (a server that starts and then fails every call is worse). If the token
is read-only, write tools are hidden automatically — no flag needed.
Spending money is always two steps
The four tools that charge the card — winnr_purchase_domains,
winnr_purchase_prewarmed, winnr_purchase_prewarmed_batch, winnr_enable_warming —
never charge on the first call. They return a live quote (availability re-checked,
exact prices, monthly total) plus a confirmation_token valid for 10 minutes. The
assistant shows the quote, gets an explicit yes, and calls again with the token. The
quote is recomputed at that moment and the token is an HMAC over it, so if a price moved
or a domain sold, the purchase is refused with a fresh quote instead of a surprise charge.
How the assistant is guided
The server ships instructions to the client (most hosts put them in the system
prompt), and every tool carries MCP annotations (readOnlyHint, destructiveHint,
idempotentHint) so hosts can ask for confirmation at the right moments. The
instructions cover:
- IDs and async jobs (
job_id→ pollwinnr_get_job) - The four tools that charge the card (domain purchase, pre-warmed purchase ×2, warming enable) and the rule to get an explicit yes with the exact price first. Domain purchases re-check availability and price right before ordering and refuse the order if anything changed, so the confirmed total is the charged total
- Never retrying a purchase after a timeout without checking
winnr_list_jobs - Domain-name hygiene (brand-like names; no outreach/blast/bulk words)
- Cold-email ratios (2–5 mailboxes per domain, warm 2–3 weeks, modest daily sends)
It also ships resources (read-only records the host can attach to a conversation:
winnr://account, winnr://usage, winnr://domains, winnr://domains/{id},
winnr://domains/{id}/dns-records, winnr://domains/{id}/dns-status,
winnr://warming/overview, winnr://jobs/{id}) and prompts — parameterised
playbooks: winnr_setup_infrastructure, winnr_health_check, winnr_reply_triage,
winnr_connect_own_domain, winnr_scale_up.
Tools
Permission is the token scope the tool needs. Read tools are visible to every token.
Account, jobs, export
Domains
Mailboxes (email users)
Inbox
Warming
Pre-warmed marketplace
Webhooks
Errors
Every tool returns JSON. Failures look like:
so an agent can branch on code. Read-only 403s explain that the token lacks write
scope; 429s on reads are retried once automatically.
Security
- Token-scoped. Everything runs as one account, with the token's permissions. Revoke it in the dashboard and the assistant is cut off instantly.
- Passwords never appear in tool output. Credentials leave only through
winnr_export_email_users, a 15-minute presigned CSV link that needs a read/write token. - Nothing is logged. The token is sent as a bearer header and never printed; the server writes one startup line to stderr.
- Rate limits are the API's (300 req/min Startup, 500 Enterprise). The server warns when fewer than 10 requests remain in the window.
Development
Deploying the hosted server
python scripts/deploy_remote.py provisions everything in AWS (DynamoDB table for OAuth
state, SSM secret, arm64 Lambda + layer, HTTP API, ACM certificate, mcp.winnr.app
domain and Route53 alias) and verifies the deployment.
License
MIT
Source: README.md at commit 7bcaf26
Tools
0Version history
1- v0.6.1LatestOct 7, 2026
