I’ll admit up front that I haven’t built anything with MCP, which makes me about as qualified to write this as you’d expect. Until recently, all I knew was that it had something to do with tool calls. After the course material and a conversation with CLaude, I now have a picture in my head. It involves a TV set.
The runner#
Picture a runner on a TV set. Someone says “find the director and get me a coffee”, and the runner works out how. As far as I can tell, that’s roughly how an AI assistant uses MCP. MCP doesn’t give it new abilities, and I don’t think it makes the decisions either. That part seems to come from the model, which is the runner. MCP is more like the list of what’s on set and the keys to get into it: it tells him what’s available and how to ask for it, in the same format everywhere.
The pieces#
As I understand it, a server can offer tools (actions, like sending an email), resources (things to read, like a record) and prompts (reusable templates). So our confirmation email would be a tool, and a list of applications could be a resource.
The selling point seems to be reuse: write the integration once, and any assistant that speaks MCP can use it. Someone still has to write the server, so it’s less “half the code” and more “stop rebuilding it for every assistant”.
Does it belong in the market app?#
Probably not. Everything we’ve built is fixed code: the form, the emails, the prefilled link, the warnings about similar stalls. My rule of thumb, which I’m happy to have corrected, is that if it can be written as code, it should be. MCP seems to matter when an AI gets to choose between tools, so I’d have to invent a feature for it.
I did come up with two. One is an assistant for the admins (“which accepted applications don’t have a stand yet?”). The other is a thought experiment where, after five years of ticket statistics, stallholders could ask how much stock to bring. Nobody asked for either, so take them as homework, not a roadmap.
Who gets a key#
I used to work in construction, where you quickly learn that you decide who gets keys to what, and you don’t count on people not wandering. A runner with a key to every room will walk into every room.
So I’d have an assistant only fetch data and never confirm or deny anything, since nothing in our system decides on its own. I’d enforce that with a read-only database user, because I wrote a whole post about instructions not being guardrails. What someone sees should depend on who they are, and for the statistics I’d stick to totals, since small numbers can still point at individuals. The server would also hold the credentials, so I’d guess that becomes the place to protect.
Where it fits today#
For now, I think MCP suits the tooling around my project better than the project itself. My coding agent already reads and creates GitHub issues through a login I gave it. That’s similar in spirit, though I don’t know whether MCP is behind it. The same rule as in my security post applies: give each one the least access it needs.
So my current take, subject to change once I actually build something: MCP isn’t a feature to put in the app. It’s a layer that lets an assistant reuse integrations, as long as someone sensible decides which doors it can open.