npx mcpblaze skills

Ship your app to people and their agents. Safely.

Your tenants get their own API keys. Agents get an MCP and sign in with your OAuth provider. Neither can reach another tenant’s data or your admin routes — and none of it goes into your code.

nino — backend/src/reservations.ts

reservations.tsbackend/src/untouched

import { db } from './db';

export async function createReservation(b: NewBooking) {

const table = await findFreeTable(b);

if (!table) throw new NoTableError(b.at);

return db.reservations.insert({ ...b, table });

}

export async function cancelReservation(id: string) {

return db.reservations.update(id, CANCELLED);

}

0 lines changed — cancelReservation still has no owner check. It does not need one: the gateway refuses the call before it reaches this file.

Agent

I wrote this multi-tenant restaurant reservation app. I want to ship it to both humans and agents, safely. Use the apiblaze npm package (npx mcpblaze skills) to give each tenant their own API keys, publish it as an MCP for agents, and make sure agents sign in with my OAuth provider and can’t take admin actions or touch another tenant’s reservations.

Installing the skill first, so I follow the supported path rather than guess at it.

$npx mcpblaze skills --install

Read backend/openapi.yaml. Your tenants create three things: restaurants, tables and reservations. Putting the gateway in front of them:

$npx mcpblaze create --target ./backend/openapi.yaml \

--oauth '{"provider":"auth0", …}'

Prevent unauthorized users from taking unauthorized actions?: Yes
Lock these to the person who created them, or an admin: restaurants, tables, reservations
Who is the admin?: julien@ninopizzas.com

API: https://nino.abz.run/1.0.0/prod
MCP: https://nino-ninopizzas.mcpblaze.com
Sign-in: your Auth0agents sign in where your users already do
Rules: restaurants, tables, reservationscreator or an admin, nobody else
Keys: each tenant mints their ownadmin: julien@ninopizzas.com

Wiring your app. Three files, none of them in backend/:

frontend/app/account/page.tsxtenants mint their own keys
frontend-server/app/api/reservations/route.tssends the key and who is calling
frontend-server/.envboth keys, server-side only

“book a table for 2 tonight” allowed — signed in, and it is theirs
“cancel reservation 41” refused — another tenant booked it
“delete restaurant Gino’s” refused — admin-only, and they are not an admin

main · TypeScript · 0 problems3 files changed in frontend/ and frontend-server/ · backend/ — 0 lines changed

A real session. The rules come from the shape of your OpenAPI spec, so nothing is guessed, and you approve each one before it turns on. Click any file to see exactly what changed.

How it works

Three steps, and none of them is “write an auth layer”

Claude learns one procedure: run npx mcpblaze dev in front of your service, answer its questions with you, and drop the key and the sign-in widget into your frontend.

Name the package

Tell your agent which tool to use: "use the apiblaze npm package (npx mcpblaze skills) to ship this safely." It installs the skill and follows the supported path instead of inventing one.

One command, three questions

It reads your OpenAPI spec, proposes what to lock down as plain sentences, and you pick which ones. Then it names an admin. Your backend is never edited.

Ship to both

Your tenants mint their own API keys from inside your app. Agents connect to an MCP URL and sign in with your OAuth provider, under the same rules.

What it does

One gateway, two doors

APIblaze shares your code with users. MCPblaze shares it with agents. Same gateway, same rules.

1/3

Users: sign-in, API keys, a self-serve portal

Your users sign in with GitHub or use an API key they mint themselves in a portal you did not build. Every request that reaches your backend carries one header saying who is calling.

X-End-User-Id: alice ← your backend reads this, nothing else

2/3

Agents: an MCP with the same rules

Every route in your spec becomes a tool at a URL any MCP client can connect to. The agent acts as a signed-in person, so what that person may not do, the agent may not do either.

https://nino-ninodefaulttenant.mcpblaze.com

3/3

Your code: untouched

The rules are enforced in front of your backend, not inside it. Two files land in your frontend (the key, the sign-in widget). Turning enforcement off is one setting, not a revert.

backend/ — 0 lines changed

Where the rules come from

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 the command shows each one before it turns on.
Nothing changes in your backend. The rules are enforced in front of it.

What stays open — we say so

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 mcpblaze 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.

Name the package. Your agent does the rest.

One line in your terminal teaches Claude Code or Codex the procedure. No account, nothing to sign up for.

$ npx mcpblaze skills --install  ← then ask your agent

Or run it yourself, no agent needed:

$ npx mcpblaze create --target ./openapi.yaml

No shell (Claude Desktop, ChatGPT, a web agent)? Add the control-plane MCP instead:

$ claude mcp add --transport http mcpblaze https://mcp.mcpblaze.com

How the rules are built mcpblaze on npm