Almost every MCP server in the wild is a developer talking to their own machine. Read files. Query the database. Restart the process that died. The person on the other end knows what a port is, and if a tool returns a stack trace they can do something with it.
Ours isn't that. PostPop makes social posts for small businesses, and the people who connected it to Claude are a bakery, a slimming studio in Taiwan and a performing arts centre in upstate New York. None of them have a terminal open. That turned out to change more than we expected.
The tool has to refuse to guess
A developer-facing tool can ask a follow-up question and get a useful answer. Ask a shop owner "which brand kit?" and the honest reply is often "the one I made, obviously" — because they only have one, and the question reads as the software being slow.
So our tools resolve what they can and refuse what they can't, rather than splitting the difference. One brand kit means no question. Three means we name all three and stop. What we do not do is pick the most recent one and carry on, which is the version that produces a finished post in the wrong client's colours and nobody notices until it's published.
Errors are read by the person, not the model
When a dev tool fails, the message is for the agent, or for the human who will go and read the logs. When ours fails, the text goes straight to somebody standing behind a counter.
We rewrote every error in our MCP surface twice. "Rate limit exceeded" became a sentence that says how many posts are left this month and when the number resets. A render failure says the post is safe and the picture isn't, because the thing they actually fear is having lost the work.
That sounds like copywriting. It's really about what an error is for: a dev error exists so you can debug it; ours exists so somebody knows whether to wait or to worry.
A post costs something, so nothing is silent
The clarifying constraint: generating a post spends one of a monthly allowance. An agent that calls a tool speculatively is spending the customer's money.
So nothing in our MCP server generates as a side effect. Tools that cost something say so before they run. It also means we can't be clever — no "generate three and pick the best," which is exactly what you'd do if the call were free.
The bit we got wrong
Our first version exposed our internals: a tool per endpoint, named after the endpoint. It was faithful to the code and useless in a conversation. The model would call the listing tool, then the detail tool, then the render tool, and three round trips later produce something the person could have got by saying "make me a post about Saturday's class."
Four tools now, named after what someone wants rather than what our API has. The rule we landed on: a tool is named for the sentence a customer would say, not for the route it hits.
Two ends of the same idea
MCP is usually described as giving an AI access to your tools. In practice there are two quite different things being built with it.
One is giving the model the machine. Rig is a good example — a Mac app that runs your local development stack and exposes it over MCP, so Claude or Cursor can see which processes are up, read the merged logs and restart the one that crashed. The audience is developers, the surface is their own environment, and the value is not having to describe the state of your machine before you can ask a question about it.
The other is giving the model a capability the person doesn't have themselves. That's ours. Nobody connects PostPop to Claude to inspect PostPop. They connect it because they want a finished carousel in their brand colours and they'd rather ask for it in a sentence than learn a design tool.
Both are MCP. They pull in opposite directions on almost every design decision — verbosity, error style, whether a tool may run twice. It's worth knowing which of the two you're building before you name your first tool, because we named ours as if we were building the first kind, and we weren't.
If you're shipping one
Three things we'd tell ourselves in August:
Name tools after the request, not the route. If a tool's name only makes sense to someone who has read your API docs, it will cost you a round trip every time.
Write the errors for the least technical person who can reach them. Then have someone who isn't you read them cold.
Decide early whether a tool may be called speculatively, and make the ones that cost something announce it. An agent will absolutely call your tool three times to compare results, and if that's three posts out of someone's monthly allowance you have built a bill, not a feature.
PostPop's MCP server is on every plan, including free, and uses the same monthly allowance as the app — here's how to connect it.
