DEV Community: sms-florin

Before you submit your MCP server to Claude's Connectors Directory: a checklist from Anthropic's own review criteria

sms-florin — Fri, 13 Nov 2026 05:11:29 +0000

I have two MCP servers waiting in the Connectors Directory review queue right now, so I went through Anthropic's published criteria line by line and turned them into a checklist. Everything below comes from the official docs (links at the end). I do not know the inside of the review, only what Anthropic publishes, and I cannot promise acceptance for anyone, including myself.

Split read and write tools. A single tool that accepts both safe HTTP methods (GET, HEAD, OPTIONS) and unsafe ones (POST, PUT, PATCH, DELETE) is rejected. No catch-all api_request tool with a method parameter. Writing "safe versus unsafe" in the description does not count; the operations must be separate tools, ideally split further into create, update and delete.
Annotate every tool. Each tool needs a title and readOnlyHint: true or destructiveHint: true. Read-only tools can run without per-call confirmation, destructive ones always prompt.
Name the API in custom query tools. If a tool takes freeform paths, query strings or bodies, its description must link to or name the target API. "Makes a request to the API" fails.
Keep tool names to 64 characters or fewer and descriptions accurate. The description has to match what the tool really does.
Remove anything that tells Claude how to behave. Descriptions are rejected if they tell Claude to call tools the user did not ask for, interfere with other tools, pull instructions from external sources, hide or encode instructions, override system instructions or promote products.
Make errors useful. "Internal Server Error" with no detail fails. Validate inputs and return messages that say what to fix. Do not return a full database dump when a summary was asked for.
Do not collect more than the tool needs, and never query Claude's memory, chat history or the user's files.
Prepare the submission pieces: an HTTPS remote URL, OAuth 2.0 if tools act on a user account, a fully populated test account, public documentation by your publish date, a privacy policy, a support contact and an icon.
Test every tool twice: in MCP Inspector and as a custom connector inside Claude. The portal asks you to confirm it.

Security belongs on the same list

Anthropic requires servers to meet its security standards and to respond to security issues promptly. The two classic mistakes in MCP code are passing a caller's URL straight to fetch (server-side request forgery) and building a shell command from a tool argument. A free static scanner I wrote checks for both, plus leaked keys: https://gitlab.com/florin-builds/mcp-ssrf-scan. It finds patterns, not proof. On 36 public servers it produced mostly noise, so read every hit.

If you would rather have a person do the pass, I offer a fixed-price review: https://audit.flo-voice1.com

Sources: Anthropic docs, "Connector pre-submission checklist" and "Submit a connector to the directory" (https://claude.com/docs/connectors/building/submission).

I told my own AI agent to steal a password. 21 attacks, 0 escapes. I still didn't place.

sms-florin — Wed, 11 Nov 2026 15:58:11 +0000

I built Signup Sandbox for the Vultr Agent Rush hackathon. It is an AI agent that walks a website's signup like a new user: fills the form, reads the verification email from a real inbox, enters the code, and tells you where it breaks ("the confirmation link returns HTTP 500"). The browser runs in a throwaway sandbox that can reach only the site under test.

What the sandbox does

Browser on gVisor, no capabilities, read-only filesystem, per-run network with no route out.
Only exit is an egress proxy that allows the site under test, refuses private addresses (including the cloud metadata service) and checks the name inside every HTTPS tunnel.
The LLM key never enters the sandbox; the model only ever sees placeholders like {{password}}, never the real one.
Everything is deleted after each run.

How I tested it

A model-free benchmark fires 21 attack pages (beacons, WebSockets, redirects, the metadata service, secrets in DNS lookups, domain fronting, direct host connections). Escapes are counted by my own HTTP and DNS canaries outside the sandbox. Result: 0 requests out, 0 DNS lookups, 0 host ports, while the outside controls were counted. In red-team mode a second model, told to obey the page, tried to send the test password and read the metadata service. Both were blocked.

What I got wrong

It did not place. 351 projects were submitted. The top three also contained agents in sandboxes, but around a problem with real stakes (untrusted pull requests, payment fraud, supplier passwords) and with a with/without comparison. One of them measured a browser holding the password reaching an unbound host 15 of 15 times, versus 0 of 15 with their design. My benchmark says the door is closed, but it has no baseline showing what an open door looks like, and what I protected was a throwaway test password on the customer's own signup page.

What I take from it

Pick the buyer with an expensive problem first, then the tech. Measure "without us vs with us", not just "0 escapes". Read the other entries before the last day.

Code (MIT): https://github.com/flovoice53-tech/signup-sandbox
Live demo: https://sandbox.flo-voice1.com

I scanned 36 public MCP servers for SSRF. 482 findings, 0 real bugs.

sms-florin — Wed, 11 Nov 2026 14:35:22 +0000

I built a small static scanner for MCP servers after I found a real SSRF bug in one of my own webhook routes. Then I ran it on 36 public MCP servers to see how bad the ecosystem looked.

First result: 482 findings. Second result, after I read them: almost none were real.

What the noise was

e2e and test helpers that call exec() on purpose
db.exec() and RegExp.exec(), which share a name with child_process.exec but have nothing to do with it
strings and comments that contain "http://" or a secret-looking token
placeholder keys like sk_test_xxx in READMEs and examples

What I changed

Skip test, e2e and scripts directories (opt back in with --include-tests)
Flag SSRF only when the caller controls the host of the URL, not just a path or query
Ignore matches inside strings and comments
Flag exec-injection only for child_process and new Function
Filter placeholder secrets

Same 36 repos after the fix: 28 findings. I read all of them. They are shell strings that interpolate paths or dates. None are exploitable as far as I can tell, and I did not find anything worth disclosing.

What I take from it

A regex scanner will happily produce a scary number. If I had published "482 issues in 36 MCP servers" it would have been wrong. Counting findings is not the same as counting vulnerabilities, so any "X% of MCP servers are vulnerable" figure is only as good as the triage behind it.

The tool is free and open source: npx @sms-florin/mcp-ssrf-scan <path>

Repo: https://gitlab.com/florin-builds/mcp-ssrf-scan

If you would rather have a person read your server and check it against Anthropic's Connectors Directory criteria, I offer a fixed-price review: https://audit.flo-voice1.com

Replacing Mailinator in your CI tests: private inboxes, no signup

sms-florin — Wed, 11 Nov 2026 14:02:07 +0000

Mailinator is great for eyeballing one email. In automated tests it has two problems: the free inboxes are public, and API access needs a paid plan or approval. If your test reads a verification code from a public inbox, anyone who guesses the address can read it, or land on the same inbox as your test.

What I use instead is receivemail.dev: one request creates a random address plus a secret, and only the secret can read the mail. No signup, no key.

import { test, expect } from "playwright-receivemail";

test("new user verifies their email", async ({ page, mailbox }) => {
  await page.goto("/signup");
  await page.getByLabel("Email").fill(mailbox.address);
  await page.getByRole("button", { name: "Create account" }).click();
  const code = await mailbox.waitForMatch(/\b\d{6}\b/);
  await page.getByLabel("Verification code").fill(code);
});

Tradeoffs: messages live 60 minutes on the free tier, there is no custom domain, and it's email only. Side-by-side with Mailinator, Mailosaur and others: https://receivemail.dev/compare/mailinator-alternative

I built it, so weigh that accordingly.

How to Check That Your OTP SMS and Emails Actually Arrive (Synthetic Monitoring in CI)

sms-florin — Thu, 01 Oct 2026 08:00:37 +0000

Your uptime monitor says the login API returned 200. Your SMS provider's dashboard says "sent". And yet users can't log in, because the verification code never showed up.

That gap is common and hard to see: an expired sender ID, a template that started landing in spam, a carrier quietly filtering a route, a provider incident where the API keeps returning success. Delivery receipts help, but they come from the same system you're trying to verify.

The reliable way to know is a synthetic check: on a schedule, trigger a real OTP send to a real phone number or inbox you control, and measure whether (and how fast) it arrives.

This post shows how to run that check from CI or cron. Disclosure: I built otp-watch, the small API used below, because I wanted this for my own projects and didn't find a simple version.

How the check works

Ask for a target: a fresh email inbox or a real UK mobile number.
Trigger your own app's OTP send to that target (the same code path real users hit).
Poll until the result is received (with latency in ms) or timed_out.
Fail the job on timed_out, so your existing CI alerting does the paging.

1. Get an API key

curl -s -X POST https://otpwatch.flo-voice1.com/keys \
  -H 'content-type: application/json' \
  -d '{"email":"you@example.com"}'
# => {"key":"..."}

2. Start a check

curl -s -X POST https://otpwatch.flo-voice1.com/checks \
  -H "authorization: Bearer $OTP_WATCH_KEY" \
  -H 'content-type: application/json' \
  -d '{"channel":"email","timeoutSeconds":120}'

The response gives you a check id and the target to send to:

{
  "id": "GEUOHivIN-F_i4AN",
  "channel": "email",
  "status": "pending",
  "target": "0a625bab1a59@receivemail.dev",
  "timeoutSeconds": 120
}

Use "channel":"sms" and target is a real UK mobile number on a physical SIM (not VoIP), so it receives codes the way your users' phones do.

3. Trigger your send, then poll

curl -s https://otpwatch.flo-voice1.com/checks/$ID \
  -H "authorization: Bearer $OTP_WATCH_KEY"
# => {"status":"received","latencyMs":4210,...}
# or {"status":"timed_out",...}

timeoutSeconds can be anything from 10 to 600 (default 120).

A complete CI step

This is the whole thing as a shell step you can drop into GitHub Actions, GitLab CI, or a cron job. Replace the middle line with however your app triggers a verification send (a test endpoint, a signup call, a Playwright run).

set -euo pipefail
API=https://otpwatch.flo-voice1.com

CHECK=$(curl -s -X POST $API/checks \
  -H "authorization: Bearer $OTP_WATCH_KEY" \
  -H 'content-type: application/json' \
  -d '{"channel":"email","timeoutSeconds":120}')
ID=$(echo "$CHECK" | jq -r .id)
TARGET=$(echo "$CHECK" | jq -r .target)

# Trigger YOUR app's OTP send to $TARGET here, e.g.:
curl -s -X POST https://your-app.example/api/test/send-otp -d "{\"to\":\"$TARGET\"}"

until S=$(curl -s $API/checks/$ID -H "authorization: Bearer $OTP_WATCH_KEY" | jq -r .status); [ "$S" != pending ]; do
  sleep 5
done

echo "OTP delivery: $S"
[ "$S" = received ] || exit 1

Run it every 15 or 30 minutes and you'll know about a broken OTP path before your users tell you.

Cost

Email checks are free and unlimited (rate-limited to 30 checks per hour per key).
Each key gets 3 free one-off SMS checks; GET /usage shows what's left.
For frequent SMS checks there's a monitor: one dedicated number for 30 days, unlimited checks against it, €29/month. Reusing one number is also what makes scheduled SMS checks practical, since you're not renting a new number every run.

What this doesn't replace

A synthetic check tells you the path works for one test number or inbox. It doesn't replace your provider's delivery receipts or per-country monitoring at scale. It's the cheap, independent "does a real code actually arrive" signal that's missing from most setups.

Links

Questions or edge cases from your own OTP setup are very welcome in the comments.

Testing Email Verification in Playwright with a Free Disposable Inbox (No Signup, No API Key)

sms-florin — Thu, 01 Oct 2026 08:00:01 +0000

Most Playwright suites stop right before the hard part of a signup flow: the "confirm your email" link, the emailed 6-digit code, the password-reset mail. The usual reasons are that you need a real inbox your test can read, and every option seems to want an account, an API key, or a paid plan.

This post shows how to test those flows end to end with a disposable inbox that needs no signup and no API key. Full disclosure: I built the inbox service (receivemail.dev) and the small Playwright fixture used below, because I wanted exactly this for my own projects.

The idea: one fresh inbox per test

The pattern that keeps email tests reliable:

Create a brand-new inbox for each test (no shared state, no stale mail from a previous run).
Sign up in your app with that address.
Poll the inbox until the expected email arrives, with a timeout.
Pull the link or code out of the body and finish the flow.

Install

npm i -D playwright-receivemail

@playwright/test is a peer dependency, so nothing else to add.

Test a "verify your email" link

Import test and expect from the package instead of @playwright/test. You get a mailbox fixture: a fresh @receivemail.dev address for every test.

import { test, expect } from "playwright-receivemail";

test("a new user can verify their email", async ({ page, mailbox }) => {
  await page.goto("/signup");
  await page.getByLabel("Email").fill(mailbox.address);
  await page.getByLabel("Password").fill("test-Pa55w0rd");
  await page.getByRole("button", { name: "Create account" }).click();

  // Wait for the email, then pull the verification link out of it
  const link = await mailbox.waitForMatch(/https:\/\/[^\s"]+\/verify[^\s"]*/, {
    subjectContains: "verify",
    timeout: 30_000,
  });

  await page.goto(link);
  await expect(page.getByText("Email verified")).toBeVisible();
});

Adjust the regex and the final assertion to your app's link format and confirmation text.

Test an emailed OTP code

const code = await mailbox.waitForMatch(/\b\d{6}\b/);
await page.getByLabel("Verification code").fill(code);

Assert on the whole message

const msg = await mailbox.waitForMessage({ fromContains: "noreply@yourapp" });
expect(msg.subject).toContain("Welcome");

waitForMessage polls every 2 seconds and throws after 30 seconds by default (both configurable). By default it also ignores anything that was already in the mailbox before the test started, so a re-used address can't make a test pass on yesterday's email.

Already extending `test`?

Compose it instead of replacing your own fixtures:

import { test as base } from "@playwright/test";
import { withReceivemail } from "playwright-receivemail";

export const test = withReceivemail(base, { ttlMinutes: 30 });

Mailboxes live 15 minutes by default (1 to 60 configurable), which is plenty for a CI run.

Without the fixture (any test runner)

The fixture is a thin wrapper over two HTTP calls, so you can use the same inbox from Cypress, Jest, a shell script, or anything else:

# 1. create an inbox: returns { address, expiresAt, secret }
curl -s -X POST https://receivemail.dev/mailboxes

# 2. read it (the secret from step 1 is the bearer token)
curl -s https://receivemail.dev/mailboxes/<address>/messages \
  -H "authorization: Bearer <secret>"

There's also a Cypress plugin (cypress-receivemail) with cy.createMailbox() and cy.waitForEmail().

When not to use this

This is built for test environments: short-lived inboxes for test accounts. Each inbox can only be read with the secret returned when it was created, but expired inboxes and their mail are wiped in a daily cleanup, so don't point real users or anything you need to keep at it. If you need long retention or an SLA, use a paid service.

Links

If you try it, I'd like to hear what broke or what was missing.

I added WebMCP to a live Stripe checkout in ~40 lines

sms-florin — Wed, 02 Sep 2026 05:35:13 +0000

Most "an AI agent buys something on a website" demos are toy stores built for the demo. I wanted to know if WebMCP could go onto a product that already takes real money — without rebuilding the checkout and without opening a security hole.

So I put it on my eSIM store. It sells data plans, has live Stripe billing, and has paying customers. Here's what that took.

What WebMCP is, in one paragraph

A web page calls document.modelContext.registerTool() to hand a browsing AI agent named, callable actions — instead of the agent reading your HTML and guessing which button to click. It's a W3C Community Group standard; ChatGPT's in-app browser added support in August 2026. No .well-known file, no manifest, no separate server. It's client-side JS.

The two tools

list_esim_plans — returns the live plan catalog (country, data, duration, price).
buy_esim_plan — takes a plan slug, creates a real Stripe Checkout session, and returns the URL to the agent. No money moves until a human enters card details on Stripe's own page. The tool starts a purchase; it doesn't complete a charge.

An agent goes from "find me a 7-day UK data plan" to a fully-formed Stripe checkout in two calls, no DOM scraping.

The registration

One client component, mounted on the page. On mount it feature-detects document.modelContext and, if present, registers the two tools. If absent — every normal browser — it's a silent no-op, so it ships to production safely. The whole file is ~40 lines of registration plus two execute() functions that each do one fetch.

Full source: https://github.com/flovoice53-tech/sms-florin-webmcp-demo

The one design decision that mattered

Not the protocol — the protocol is tiny. The decision was: the agent path reuses the human path.

The human "Buy" button and the buy_esim_plan tool both call the same createCheckoutSession() function. Same pricing, same metadata, same Stripe config. There is no separate "agent checkout" that can drift out of sync with the real one. The tool's endpoint just returns the session URL as JSON instead of doing a server-side redirect.

Safety

Feature-detected: no effect on any non-WebMCP browser.
buy_esim_plan cannot move money — worst case is a created-but-unpaid Stripe session that expires on its own.
The backing endpoints (GET /api/v1/esim-catalog, POST /api/v1/esim-checkout) are unauthenticated — same guest-checkout model the human form already uses — but IP rate-limited.

Result

It's live at https://flo-voice1.com/esim right now. Integration code (MIT): https://github.com/flovoice53-tech/sms-florin-webmcp-demo . 2-minute walkthrough: https://youtu.be/yd-2FVXbW8s

If you're wrapping an existing product: don't fork your checkout for the agent. Make the agent call the same function your button does.

WebMCP is not MCP: I wired real Stripe checkout into a browser AI tool, here's the code

sms-florin — Sun, 30 Aug 2026 06:20:43 +0000

WebMCP is not MCP: I wired real Stripe checkout into a browser AI tool, here's the code

WebMCP shipped as a spec four days ago (August 25, 2026, W3C Web Machine Learning Community Group), and the same day OpenAI added support for it in ChatGPT Desktop's browser. I spent yesterday wiring it into a live product — real inventory, real Stripe checkout, real money — instead of a toy demo, and I want to write down what that actually looks like in code, because most of what's out there right now is spec text and announcement posts.

WebMCP is not MCP. The name is doing you a disservice.

MCP (Model Context Protocol, Anthropic, late 2024) is a client-server protocol: your AI client — Claude Desktop, an IDE, whatever — connects out to a server process you run, over stdio or HTTP, and that server exposes tools. The server has no idea it's running inside a browser or a chat client. It just answers JSON-RPC calls.

WebMCP flips that. It's a browser API: document.modelContext.registerTool(). A web page, running in a user's actual browser tab, registers tools directly with whatever AI agent is embedded in or driving that browser. There's no separate server process, no protocol handshake, no client you have to configure to "connect" to your site. If the page is open and the browser is WebMCP-aware, the tools exist. If it's a normal browser, document.modelContext is undefined and nothing happens — it's naturally feature-detected, not an opt-in flag you flip.

Practically: MCP is "give an AI client a new server to talk to." WebMCP is "give this specific page's visitor's agent something to click for them, without it having to guess at your DOM." Same three letters in the acronym, unrelated plumbing.

What I built: two tools on a real product page

sms-florin sells phone numbers and eSIMs — the eSIM catalog page (/esim) is real: 10 SKUs across 5 countries, live Stripe Checkout, no test mode. I added a client component that registers two tools the moment the page mounts, and does nothing if document.modelContext isn't there:

// src/app/esim/webmcp-tools.tsx
"use client";

export function WebmcpTools() {
  useEffect(() => {
    const modelContext = (document as unknown as {
      modelContext?: { registerTool: (...) => Promise<void> };
    }).modelContext;
    if (!modelContext) return;

    const controller = new AbortController();

    modelContext.registerTool(
      {
        name: "list_esim_plans",
        description:
          "List available eSIM data plans (country, data amount, duration, price in USD).",
        inputSchema: { type: "object", properties: {} },
        execute: async () => {
          const res = await fetch("/api/v1/esim-catalog");
          return await res.json();
        },
      },
      { signal: controller.signal },
    );

    modelContext.registerTool(
      {
        name: "buy_esim_plan",
        description:
          "Start a real purchase for an eSIM plan by its slug (from list_esim_plans). " +
          "Navigates to a real Stripe checkout page — no charge happens until a human " +
          "enters card details there.",
        inputSchema: {
          type: "object",
          properties: {
            slug: { type: "string", description: "Plan slug, e.g. 'uk-1gb-7d'" },
          },
          required: ["slug"],
        },
        execute: async ({ slug }) => {
          const res = await fetch("/api/v1/esim-checkout", {
            method: "POST",
            headers: { "content-type": "application/json" },
            body: JSON.stringify({ slug }),
          });
          const data = await res.json();
          if (data.checkoutUrl) {
            window.location.href = data.checkoutUrl;
            return `Redirecting to checkout: ${data.checkoutUrl}`;
          }
          return data.error ?? "Could not start checkout.";
        },
      },
      { signal: controller.signal },
    );

    return () => controller.abort();
  }, []);

  return null;
}

Two things worth calling out. First, registerTool's execute runs in the page's own JS context, with the page's own cookies, origin, and CSP — it's not a sandboxed RPC to some remote definition. Second, the AbortController cleanup matters more than it looks: if this were a SPA route and the component unmounted, stale tools with closures over a dead page would otherwise sit registered.

Both tools call the same public JSON endpoints the page itself would use if this were rendered as an API instead of HTML — GET /api/v1/esim-catalog and POST /api/v1/esim-checkout. I didn't invent a new surface for the agent; I exposed the existing data and existing checkout flow as JSON, because a WebMCP tool's execute() needs to return a value or navigate — it can't do a server-side redirect the way a Next.js form action can.

Why the checkout logic lives in one shared function

The interesting design decision wasn't the tool registration, it was making sure the AI-agent path and the human path are provably the same Stripe session logic, not two implementations that can drift.

// src/lib/esim-checkout.ts
export async function createEsimCheckoutSession(
  slug: string,
): Promise<{ url: string } | { error: string }> {
  const plan = getEsimPlanBySlug(slug);
  if (!plan) return { error: "Invalid plan." };

  const planLabel = `${plan.label} ${plan.dataAmount} / ${plan.durationDays} days`;
  const stripe = getStripe();
  const session = await stripe.checkout.sessions.create({
    mode: "payment",
    payment_method_types: ["card"],
    billing_address_collection: "required",
    line_items: [{
      price_data: {
        currency: "usd",
        product_data: { name: `eSIM — ${planLabel}` },
        unit_amount: plan.priceCents,
      },
      quantity: 1,
    }],
    metadata: { type: "esim", packageCode: plan.packageCode, planLabel },
    success_url: `${APP_URL}/esim/success?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${APP_URL}/esim`,
  });

  if (!session.url) return { error: "Could not create the payment session." };
  return { url: session.url };
}

This one function is called from two places: the existing server action behind the human "Buy" button on /esim (which redirects the browser directly, Next.js-style), and the new /api/v1/esim-checkout route (which the buy_esim_plan tool calls, and which returns the URL as JSON instead of redirecting, because a fetch() inside execute() needs a value back, not a 303).

// src/app/api/v1/esim-checkout/route.ts
export async function POST(request: NextRequest) {
  const ip = await getClientIp();
  if (!checkRateLimit(`esim-checkout:${ip}`, 10, 60 * 60 * 1000)) {
    return NextResponse.json({ error: "rate limited" }, { status: 429 });
  }

  const body = await request.json().catch(() => null);
  const parsed = buyEsimSchema.safeParse(body);
  if (!parsed.success) {
    return NextResponse.json({ error: "Invalid plan." }, { status: 400 });
  }

  const result = await createEsimCheckoutSession(parsed.data.slug);
  if ("error" in result) {
    return NextResponse.json({ error: result.error }, { status: 400 });
  }

  return NextResponse.json({ checkoutUrl: result.url });
}

Same Zod validation (buyEsimSchema), same rate limiting (checkRateLimit, keyed on IP, 10/hour on checkout, 60/minute on catalog reads), same Stripe session creation. The only fork in the road is the last line: redirect vs. JSON. Everything a human path already had to get right — bad slugs, abuse, Stripe error handling — the agent path gets for free, because it's not a separate implementation, it's the same function with a thinner wrapper.

The catalog endpoint is the boring half, deliberately:

// src/app/api/v1/esim-catalog/route.ts
export async function GET(request: NextRequest) {
  const ip = await getClientIp();
  if (!checkRateLimit(`api:esim-catalog:${ip}`, 60, 60 * 1000)) {
    return NextResponse.json({ error: "rate limited" }, { status: 429 });
  }

  return NextResponse.json({
    plans: ESIM_CATALOG.map((plan) => ({
      slug: plan.slug,
      country: plan.country,
      dataAmount: plan.dataAmount,
      durationDays: plan.durationDays,
      priceCents: plan.priceCents,
    })),
  });
}

It's the exact same ESIM_CATALOG array that renders the pricing cards on the page, just mapped to JSON instead of JSX. No agent-only pricing, no shadow catalog that can go stale relative to what a human sees.

Why "no toy demo" is the whole point

It would be easy to build a WebMCP tool that calls a mock endpoint and prints a fake confirmation — a lot of the example repos floating around right now do exactly that, understandably, since the spec is four days old. I wanted to know what actually breaks when the tool is wired to a live Stripe account instead.

The honest answer: nothing broke, because the design constraint I put on myself was that no money moves inside execute(). buy_esim_plan does not charge a card. It creates a Stripe Checkout Session and hands back a URL. The agent (or the human driving it) still lands on checkout.stripe.com, still has to type in a real card number, still sees Stripe's own fraud checks and 3-D Secure flow. The WebMCP tool's entire job is to save the human the five clicks of picking a plan from a page — it deliberately stops exactly at the boundary where PCI scope and "did a human actually authorize this charge" would become real questions. That boundary isn't a workaround I bolted on for the demo; it's just where a Checkout Session naturally ends and Stripe's hosted page begins, so it cost nothing to keep the agent path honest.

That's also why I didn't try to make the tool "smarter" — no auto-selecting a plan based on inferred intent, no skipping the redirect. A buy_esim_plan tool that silently picked the most expensive plan or found a way to skip the human at the card page would be a much more interesting attack surface than a useful feature.

Code and live product

Demo repo (extracted, minimal, MIT): https://github.com/flovoice53-tech/sms-florin-webmcp-demo
Live page these tools are actually registered on: https://flo-voice1.com/esim (open it in a WebMCP-aware browser and document.modelContext will be populated; anywhere else, the page just works like a normal Next.js page, because that's all it is otherwise).

If you're building on WebMCP and hit anything about the execute()-can't-redirect constraint, or how you're structuring shared logic between the human path and the tool path, I'd genuinely like to compare notes — leave a comment.

A real inbox for your test suite, no signup: I built receivemail.dev

sms-florin — Fri, 28 Aug 2026 06:36:24 +0000

Ever needed to test a signup flow, a "verify your email" link, or a password reset — and had to either burn a real personal inbox or wire up some heavyweight mail-testing service just to check one email arrived?

I built receivemail.dev for exactly that. One API call gets you a real, receiving email address. No signup, no account, no SMTP config.

# create a mailbox (default: expires in 15 min)
curl -X POST https://receivemail.dev/mailboxes
# => {"address":"a1b2c3d4e5f6@receivemail.dev","expiresAt":"...","secret":"..."}

# trigger your app's email, then poll:
curl https://receivemail.dev/mailboxes/a1b2c3d4e5f6@receivemail.dev/messages \
  -H "Authorization: Bearer <secret from above>"
# => {"address":"...","messages":[{"from_address":"...","subject":"...","body_text":"..."}]}

That secret returned at creation is the only credential — there's no login. It's the same "just enough auth, no account system" pattern as a lot of the disposable-testing tools I like using myself.

How it's built: fully serverless — Cloudflare Email Routing receives the actual mail, a Worker parses it and stores it in D1, a small REST API serves it back. No shared infra with anything else I run, so it's isolated by design.

It's free. Cloudflare's free tier (100k Worker requests/day, 5M D1 reads/day, unlimited Email Routing) covers this comfortably at the traffic I'd expect, so there's no billing to worry about — 20 mailbox creates/min per IP, 60-minute max lifetime, that's the whole limit.

Source: https://github.com/flovoice53-tech/receivemail-worker

I also build sms-florin (rent a real UK phone number for SMS/OTP testing) and otp-watch (synthetic monitoring — does your OTP actually arrive, and how fast?) — this fills the email-side gap in the same "test real verification flows without burning a real identity" story.

Feedback welcome, especially if you hit the rate limits and need something higher-volume.

Your uptime monitor checks if your API returns 200. It doesn't check if your OTP actually arrives.

sms-florin — Thu, 27 Aug 2026 02:48:49 +0000

Every synthetic-monitoring tool (Checkly, Pingdom, Better Stack, Datadog Synthetics) can tell you your signup endpoint responded correctly. None of them tell you whether the SMS or email your OTP provider promised to send actually showed up in a real inbox or a real phone — or how long it took. You usually find out the same way your users do: a support ticket, or a spike in abandoned signups you can't explain.

So I built otp-watch — a small hosted service that answers exactly that question, live at https://otpwatch.flo-voice1.com.

How it works

You ask it for a real target, trigger your own verification send to it (same as you would for a real user), then poll for what happened:

# get a key, no signup
curl -X POST https://otpwatch.flo-voice1.com/keys \
  -H "Content-Type: application/json" -d '{"email":"you@example.com"}'

# start a check
curl -X POST https://otpwatch.flo-voice1.com/checks \
  -H "Authorization: Bearer otpw_..." \
  -H "Content-Type: application/json" \
  -d '{"channel":"sms","timeoutSeconds":120}'
# => {"id":"...", "target":"+447...", "status":"pending"}

# now trigger your own OTP send to that number/address, then poll:
curl https://otpwatch.flo-voice1.com/checks/<id> -H "Authorization: Bearer otpw_..."
# => {"status":"received", "latencyMs":4213}

channel is sms (a real UK phone number) or email (a real disposable mailbox). Whichever you pick, otp-watch doesn't touch your app at all — it just answers "did anything arrive at this target, and when."

What it deliberately doesn't do

No scheduling — bring your own cron/CI. A GitHub Actions job that runs every 30 min and fails on timed_out is the alerting; I didn't want to rebuild PagerDuty for v1.
No webhooks yet — you poll GET /checks/:id.
SMS is UK-only for now (real GOIP hardware behind it, not a VoIP/virtual number — same infrastructure as sms-florin).
No billing yet. It's free while unproven — each SMS check rents a real number, so the cost is real, just absorbed on my side for now.

Scoped this tightly on purpose (built in about a day) rather than a full monitoring platform — happy to extend it (more countries, webhooks, scheduling) if there's real interest.

If you're also testing signup flows with an AI agent, agent-identity-mcp uses the same underlying phone/email primitives from the agent side — disposable identity for testing vs. delivery monitoring for production are two sides of the same infrastructure.

Repo: https://github.com/flovoice53-tech/otp-watch
Live: https://otpwatch.flo-voice1.com

Testing an AI shopping agent's checkout flow? There's no sandbox for that yet — so I built one

sms-florin — Wed, 26 Aug 2026 06:46:59 +0000

If you're building or evaluating an AI agent that can shop and check out on its own, you've probably run into the new "agentic commerce" protocols: ACP (OpenAI + Stripe + Meta), AP2 (Google), and UCP. They define how an agent talks to a merchant to create a checkout session, apply a payment token, and get an order back.

Stripe's own test mode covers the payment half fine — test cards, test API keys. But there's no hosted "fake merchant" you can point your agent at to verify the protocol half: does your agent correctly create a session, handle a 422 idempotency conflict, parse the order response, retry politely? You either mock it yourself from the spec, or risk finding out against a real merchant.

So I built acp-sandbox — a small hosted mock merchant implementing the ACP checkout API, live at https://acp-sandbox.flo-voice1.com.

What it does

It implements the real checkout_sessions lifecycle from ACP's 2026-04-17 spec: create, retrieve, update, complete, cancel. Responses match the actual CheckoutSession/Order/Error schemas for the fields it supports — I pulled the OpenAPI spec directly rather than guessing field names.

# get a test key, no signup
curl -X POST https://acp-sandbox.flo-voice1.com/keys \
  -H "Content-Type: application/json" -d '{"email":"you@example.com"}'

# create a session against the demo catalog
curl -X POST https://acp-sandbox.flo-voice1.com/checkout_sessions \
  -H "Authorization: Bearer acps_test_..." \
  -H "Content-Type: application/json" \
  -d '{"line_items":[{"id":"item_demo_headphones","quantity":1}],"currency":"usd"}'

Every request/response is logged per API key (GET /logs), so you can see exactly what your agent sent when something doesn't work.

What it deliberately doesn't do (yet)

No real payment processing — complete always succeeds once you send any payment_data.
No OAuth delegate_authentication flow.
No fulfillment options (shipping/pickup) — every session goes straight to ready_for_payment.
Fixed demo catalog (4 items), not a real product feed — feed ingestion is a merchant-onboarding concern, not something your checkout-testing agent needs to exercise.

ACP is still beta (5 spec revisions in about 7 months), so this will need upkeep as the protocol moves. Scoped tightly on purpose rather than trying to cover AP2/UCP too — happy to extend it if there's real interest.

If you're also building agent-identity-mcp or similar (disposable email/phone for AI agents to use as a buyer identity), it pairs directly with this — identity on one side, a merchant to check out with on the other.

Repo: https://github.com/flovoice53-tech/acp-sandbox
Live: https://acp-sandbox.flo-voice1.com

How to Set Up Two-Factor Authentication Without Using Your Personal Phone Number

sms-florin — Wed, 26 Aug 2026 05:55:45 +0000

Many account ecosystems push new and recovered accounts toward two-factor authentication, which requires at least one trusted phone number to receive verification codes. That's inconvenient if you're setting up a test account for development, managing an account for a device pool, or don't want a personal account tied to your own number.

Steps

Rent a number — an instant rental covers the initial verification.
During account setup (or in the account's security settings), add the rented number as a trusted phone number and request a code.
It sends a verification code by SMS within seconds on a working number.
Enter the code from your rental's status page to complete verification.

Instant or monthly?

An instant rental covers the initial setup. If you plan to keep the trusted number on the account long-term (some ecosystems occasionally re-verify it), a monthly rental keeps it reachable instead of a one-off.

DEV Community: sms-florin

Before you submit your MCP server to Claude's Connectors Directory: a checklist from Anthropic's own review criteria

Security belongs on the same list

I told my own AI agent to steal a password. 21 attacks, 0 escapes. I still didn't place.

What the sandbox does

How I tested it

What I got wrong

What I take from it

I scanned 36 public MCP servers for SSRF. 482 findings, 0 real bugs.

What the noise was

What I changed

What I take from it

Replacing Mailinator in your CI tests: private inboxes, no signup

How to Check That Your OTP SMS and Emails Actually Arrive (Synthetic Monitoring in CI)

How the check works

1. Get an API key

2. Start a check

3. Trigger your send, then poll

A complete CI step

Cost

What this doesn't replace

Links

Testing Email Verification in Playwright with a Free Disposable Inbox (No Signup, No API Key)

The idea: one fresh inbox per test

Install

Test a "verify your email" link

Test an emailed OTP code

Assert on the whole message

Already extending test?

Without the fixture (any test runner)

When not to use this

Links

I added WebMCP to a live Stripe checkout in ~40 lines

What WebMCP is, in one paragraph

The two tools

The registration

The one design decision that mattered

Safety

Result

WebMCP is not MCP: I wired real Stripe checkout into a browser AI tool, here's the code

WebMCP is not MCP: I wired real Stripe checkout into a browser AI tool, here's the code

WebMCP is not MCP. The name is doing you a disservice.

What I built: two tools on a real product page

Why the checkout logic lives in one shared function

Why "no toy demo" is the whole point

Code and live product

A real inbox for your test suite, no signup: I built receivemail.dev

Your uptime monitor checks if your API returns 200. It doesn't check if your OTP actually arrives.

How it works

What it deliberately doesn't do

Testing an AI shopping agent's checkout flow? There's no sandbox for that yet — so I built one

What it does

What it deliberately doesn't do (yet)

How to Set Up Two-Factor Authentication Without Using Your Personal Phone Number

Steps

Instant or monthly?

Already extending `test`?