npx mcpblaze · no signup · takes a minuteThe instantly more secure MCP
Regular MCP generators don't secure anything: every user of the agent can take any action your backend allows. MCPblaze turns your OpenAPI spec into an MCP where users sign in and each one can only do what they should be able to do. All in one command.
This is the real transcript. The rules come from the shape of your spec — no AI guessing — and you read each one as a plain sentence before it turns on.
Regular MCP generators don't secure anything
They make it possible for an agent to act on your API. They do nothing about who is allowed to do what. Here is why that is worse than it sounds.
One shared key for everyone
A generated MCP server connects to your backend with a single credential. Every tool call — from every user of the agent — arrives as that one key.
Your backend can't tell users apart
It sees "the MCP", never the person. It has no way to know that this request is Alice asking about her own reservation and that one is Bob asking about hers.
So every user can do everything
Anything your backend allows the key to do, any user of the agent can do — to any record. The agent working for Alice can cancel Bob's reservation, and nothing stops it.
Fixing it yourself is three projects: a sign-in flow for the MCP, a way to carry the signed-in person to your backend on every call, and per-record rules that check it. Most teams ship the MCP and never get to the other two.
One command. Three things that normally take three projects.
MCPblaze is powered by the APIblaze serverless proxy, which already knows how to sign users in and enforce who may touch which record. Point it at your spec and all three come out together.
Your API becomes an MCP
Every route in your OpenAPI spec becomes a tool at a URL any MCP client can connect to — Claude, ChatGPT, or your own agent.
https://nino.mcp.abz.run/1.0.0/devUsers sign in
The client runs the standard MCP sign-in flow (GitHub by default). Every tool call now carries a real, verified person — not a shared key.
this call is Alice — verifiedEach user can only touch what is theirs
Rules read from your spec: whoever created a reservation is the only one who can see, change or cancel it. Admins can act on anything. You see the rules and approve them before they turn on.
reservation 42 → owner: Alice · admins: yes · everyone else: noConnect Claude or ChatGPT and try it
The client opens nino.mcp.abz.run, asks Alice to sign in with GitHub, and from then on every tool call is Alice — not “the MCP”.
When she is not allowed, the agent gets a clear “not allowed” it can explain — not an empty answer it has to guess about.
| The agent, working for Alice, tries to… | Result |
|---|---|
| Book a table | Allowedreservation 42 is recorded as Alice's |
| Read reservation 42 | Allowedit is hers |
| Change or cancel reservation 42 | Allowed |
| Read or cancel Bob's reservation 43 | Not allowedthe agent is told plainly it is not allowed |
| The same, once Alice is made an admin | Allowedadmins can act on anything |
Your spec, read literally
- A route that creates something (
POST /reservations) tells us who the owner is. - Routes that touch one thing by id (
GET, PUT, DELETE /reservations/{id}) get the rule: owner or admin only. - No AI decides your security. The same spec always produces the same rules, and each is shown as a sentence you approve first.
- Nothing changes in your backend. The rules are enforced in front of it.
Rules protect one record at a time
These stay reachable by any signed-in user, and the command tells you:
GET /reservationsthe list. Add a rule for it with npx apiblaze rule nino if a list of everything is too much.POST /reservationscreating is how we learn who owns what.POST /searchaction-style routes that do not touch one record by id.older recordsanything created before the rules went on has no known owner — only admins can touch it.
Try it on your own spec
No account needed. It takes about a minute, and you approve every rule before it turns on.