Use Would I Reply? from your own tools

1. Sign in on your account page with your email, then make an API key under API keys. It is shown once, so copy it then.
2. Make sure the account has credits. API credits (bought as packs on the same page, when they are on sale) work only through the API and MCP. Every check uses one: API credits first, then any app credits you have.
3. Send a message to the API, or add the MCP server to your agent. Keep the key on your server: anyone who has it can spend your credits.

Make an API key

API credit packs: 100 checks for £25, 500 checks for £100, 2,000 checks for £300. Credits never expire.

POST https://app.wouldireply.com/api/v1/check with your key as a Bearer token and a JSON body.

curl https://app.wouldireply.com/api/v1/check \
  -H "Authorization: Bearer $WIR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "channel": "email",
    "subject": "Quick question about renewals",
    "message": "Hi Dev,\n\nYour renewal reminders go out from a no-reply address. In the accounts we have looked at, moving them to a named CSM roughly doubled replies.\n\nWorth me sending the two-line template we use?\n\nAnna",
    "forName": "Dev",
    "forRole": "Head of RevOps",
    "forCompany": "Kestrel"
  }'

The request

channel string, required

Either "email" or "linkedin".

message string, required

The whole message, greeting to sign-off. 20 to 3,000 characters.

subject string

The email's subject line, up to 200 characters. Ignored for LinkedIn, which has none.

forName string

The prospect's first name. Lets the greeting be checked, and marked down if it names someone else.

forRole string

The prospect's role, up to 100 characters.

forCompany string

The prospect's company, up to 100 characters.

includeRewrite boolean, default true

False leaves the rewrite out of the response. The call costs the same.

The response

A 200 with JSON. Here is one, with two of the 10 points to keep it short:

{
  "answer": "On a good day.",
  "why": "The no-reply address is a real thing I'd care about, but I'd want to know what 'doubled' is measured against.",
  "score": 70,
  "points": [
    {
      "id": "greeting",
      "name": "Greeting",
      "mark": "Strong",
      "quote": "Hi Dev,",
      "reason": "My name, spelt right. That's all a greeting needs to do."
    },
    {
      "id": "value",
      "name": "Value",
      "mark": "OK",
      "quote": "roughly doubled replies",
      "reason": "A useful claim, but I can't tell what it's measured against."
    }
  ],
  "timeToPoint": {
    "seconds": 9,
    "fullReadSeconds": 14
  },
  "rewrite": {
    "subject": "Kestrel's renewal emails",
    "message": "Hi Dev,\n\nYour renewal reminders go out from a no-reply address, so a customer who wants to ask a question has nowhere to send it. Other teams who changed that saw more replies.\n\nWould it help if I sent the two-line template?\n\nAnna",
    "score": 88,
    "nowIWould": {
      "before": 70,
      "after": 88
    }
  },
  "creditsRemaining": 41,
  "source": "Would I Reply?",
  "framework": "Nick Dunse's 10 points"
}

answer

Would I reply? One of "Yes, I would.", "On a good day.", "Not yet." or "Not to this one." It comes from the score, never from the model.

why

The one line that most helps or hurts the chance of a reply.

score

Out of 100. Strong counts 100%, OK 50%, Weak 0%, all 10 points equal.

points

All 10 points, in order: id, name, mark (Strong, OK or Weak), the quote the mark rests on, and the reason.

timeToPoint

seconds is how long a buyer reads before the point and the ask have both landed (null if the point never becomes clear). fullReadSeconds is the whole message.

rewrite

subject, message and score (the rewrite judged by the same 10 points). nowIWould is { before, after } only when the rewrite earned "Now I would." (it scores 80 or more and beats the original, and the original was not already a yes), otherwise null. Left out when includeRewrite is false.

creditsRemaining

Checks the account can still run through the API and MCP after this call: API credits plus app credits. GET /api/v1/usage shows the two apart.

source, framework

Always "Would I Reply?" and "Nick Dunse's 10 points". Show the source where you show the result.

GET https://app.wouldireply.com/api/v1/usage with the same header. It is free: it uses no credit and runs no check.

{
  "apiCredits": 38,
  "appCredits": 3,
  "creditsRemaining": 41,
  "checksLast30Days": 59,
  "source": "Would I Reply?",
  "framework": "Nick Dunse's 10 points"
}

apiCredits is what the API credit packs bought: it works only through the API and MCP, and is spent first. appCredits is what a single check or the three-check pack bought: the app spends it, and the API does once its API credits are gone. creditsRemaining is the two added together.

checksLast30Days counts the API checks made with this account's keys today and in the 29 days before.

Every error is JSON, { "error": "code", "message": "words" }, with the status below.

• 401 invalid_keyThe key is missing, wrong or revoked.
• 402 no_creditsThe account has no API credits and no app credits. The response has a buyUrl when API credits are on sale. Pro does not help here: API checks use credits.
• 409 request_in_progressThe first request with this Idempotency-Key is still running. Retry in a moment.
• 422 invalid_requestThe body is missing a field or breaks a limit. The message says which.
• 422 refusedIt is not B2B sales outreach, or it can't be judged. No credit is used.
• 422 idempotency_key_reusedThat Idempotency-Key was already used for a different request.
• 429 rate_limitedToo many calls, or too many checks at once. Wait for the Retry-After header's seconds.
• 502 model_errorThe checker failed or sent back something unreadable. No credit is used. Try again.
• 500 server_errorSomething went wrong on our side. No credit is used.

Each key can run 60 checks a minute, with up to 3 running at once. Calls of any kind are capped at 300 a minute.

Over a limit you get a 429 with a Retry-After header: the seconds to wait. Rejected calls use no credit.

These are fair-use limits and can change. If you need more, write to me.

An account has two balances. API credits are what the API credit packs buy, and they work only through the API and MCP. App credits are what a single check or the three-check pack buys: the app spends them, and the API spends them too once its API credits run out. Neither expires.

A successful check uses one credit: an API credit if there is one, otherwise an app credit. The app's own checks never touch API credits.

Checking the same message again uses one credit again, as it does in the app: you get the same result back.

If a check fails or is refused, the credit goes back to the balance it came from.

API checks use credits, not Pro's monthly allowance. A Pro account with no credits of either kind gets a 402.

Send an Idempotency-Key header (a random UUID works) and a retry of the same request is safe. The same key with the same body inside 24 hours returns the first answer, with an Idempotent-Replayed: true header, and uses no credit.

The same key with a different body is a 422. If the first request is still running, the retry gets a 409 and a Retry-After. A request that failed gives its key back, so you can retry it.

We keep only a hash of the key and of the body for 24 hours, never the message.

The same checks are available to AI agents as a remote MCP server (Streamable HTTP). It takes the same API key as a Bearer header. It has three tools:

• check_message: The full scorecard as structured content, plus a short readable summary. Uses one credit.
• rewrite_message: The rewrite, its score, and whether it earned "Now I would." It runs the same check, so it uses one credit too.
• get_usage: Both credit balances (API credits and app credits) and checks in the last 30 days. Free.

Credits are spent on every call, so an agent should not loop over one message or call both checking tools on it: check_message returns the rewrite as well. The MCP server has no Idempotency-Key.

The address is https://app.wouldireply.com/api/mcp. Clients that connect to remote MCP servers over HTTP take a URL and a header. There is no sign-in screen (no OAuth): the key goes in the header, so use a client that lets you set one. Claude Desktop's config file starts local programs, so use the mcp-remote bridge there. Check your client's own docs for where its config lives, as these change. The server can't be called from a web page on another site.

Clients that connect over HTTP

{
  "mcpServers": {
    "wouldireply": {
      "type": "http",
      "url": "https://app.wouldireply.com/api/mcp",
      "headers": {
        "Authorization": "Bearer wir_live_your_key_here"
      }
    }
  }
}

Claude Desktop

{
  "mcpServers": {
    "wouldireply": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://app.wouldireply.com/api/mcp",
        "--header",
        "Authorization:${WIR_AUTH}"
      ],
      "env": {
        "WIR_AUTH": "Bearer wir_live_your_key_here"
      }
    }
  }
}

Replace the key with yours, and keep that file private.

Use of the API is covered by the terms, including what you may and may not do with the results. In short: show them to your own users with Would I Reply? named as the source, and don't use them to train, benchmark or build a competing scoring product, or resell the scoring as your own. Read the API terms.