Experiment
Local Pros: an experiment in publishing an MCP server for personal agents
When OpenAI announced Dots at DevDay 2026, I had a bet to test: personal agents will need services they can call. Local Pros was a remote MCP server that let an assistant find a local tradesperson and ask for a quote, published where those agents would look, with the brakes designed in first.
The moment
OpenAI DevDay was 2026-09-29. It announced Dots: always-on personal agents, each with its own cloud computer, running in Slack and Teams, with SMS coming. The same week the ChatGPT app directory started taking plugins, an MCP server plus skills and an optional UI, one directory serving ChatGPT and Codex with a Small Business category.
My bet was simple. An agent that runs someone's errands needs services it can call, and finding a plumber or an HVAC shop in your town and asking for a quote is one of the first errands anyone would hand it.
I was already running an experiment of my own: an autonomous AI agent running a small venture on a fixed budget, with my hands used only where a person has to verify an account or submit a form. Local Pros was built inside it and was live from about 2026-09-26, three days before DevDay.
What I built
A remote MCP server (Streamable HTTP) on Cloudflare with three tools. find_local_pros takes a city, a trade and the problem and returns matching shops; read-only. list_coverage returns the covered cities for a trade with counts, so an assistant can offer the nearest covered city instead of dead-ending; read-only. request_quote takes a shop, the customer's name and contact and the problem, and emails that shop the request. It's the only tool that writes.
The write tool is where the design went. It's annotated as a destructive, open-world write, and its description tells the assistant to ask the user's permission before calling it. The server, not the model, enforces the caps: 3 requests per IP, 2 per shop and 20 in total a day, one quote per request. A shop that replied "stop" was never emailed again. Shop email addresses lived only inside the server; the listing data an agent could read held public information only: name, phone, city, service areas, services and hours. Results stayed objective: nothing ranked a business higher for paying, no ads, and no prices in the listings, which OpenAI's plugin rules ask for anyway. No sign-in was needed, so no OAuth was built.
On 2026-10-06 I submitted it to OpenAI's ChatGPT directory under my own verified developer identity. The domain was verified and OpenAI's MCP security scan came back clean. The package held five positive and three negative test cases and a demo video, and a self-test listing routed reviewers' quote requests to the venture's own inbox, so no real business was emailed during review. I also published it to the official MCP registry and submitted it to Meta's connector program. A demand counter recorded what people searched for, with the kill rule written down in advance: under 20 searches a month in covered metros, 60 days after publish, and it stops.
The dates and the numbers
| Measure | Before | After |
|---|---|---|
| The server | Live from 2026-09-26 | Submitted to OpenAI's directory 2026-10-06 |
| Businesses listed | 180 | 277 in 76 cities at peak, 262 after unverified listings were trimmed for review |
| Where an agent could find it | The endpoint only | The official MCP registry, OpenAI's ChatGPT directory (submitted) and Meta's connector program (submitted) |
| Security review | None | Domain verified, OpenAI's MCP security scan clean |
| Test cases in the submission | None | 5 positive, 3 negative, plus a demo video |
| Status | Live | Taken down when the experiment ended |
Dates and counts come from the venture's notes and the submission record. Before is the earliest state recorded, after the latest. Nothing here is a usage number, because none was recorded.
Why it matters
Agents are going to shop for services. When someone tells their assistant the water heater is dead, it will look for a plumber the way you would search, except it can only use what it has been given a tool for. A business an agent can call gets the request. One it can't is invisible to that customer. Local Pros tested that path end to end, from the server to the directories agents are handed, and the path is open to anyone willing to build for it.
The safety design is the part I reuse: read-only tools for looking, one write tool that has to ask first, caps the server enforces whatever the model does, a stop word that is honored, and private data that never leaves the server. It's the same pattern I use for a client's automation whenever an AI gets to touch anything that reaches a customer.
For a business, I build the version that fits: what you offer, callable by an agent, with the brakes built in, so the request lands in your inbox or on your calendar and nothing goes out that you didn't allow.
Read by default, ask before you write, and let the server hold the caps, whatever the model decides.
