apiblaze 0.21.79 → 0.21.80

package/dist/index.js

@@ -34,7 +34,7 @@ var __toESM = (mod, isNodeMode, target2) => (target2 = mod != null ? __create(__
 var version;
 var init_package = __esm({
   "package.json"() {
-    version = "0.21.79";
+    version = "0.21.80";
   }
 });
 
@@ -15581,15 +15581,15 @@ brand: mcpblaze
 What is in this folder, the fastest way to an MCP server for it, and what comes after.
 ${olderCopiesSection(copies, brand)}
 ${folder}
-## The MCP server and its two links come first; everything else after
+## Three phases: finish one, then ask before the next
 
-1. **Find the API.** None found above: look where the code keeps it (a frontend's API base URL, \`vercel.json\`,
-   \`render.yaml\`, the README); still none: ask the user for its address, or better, its OpenAPI spec URL, before anything else.
-2. **Ask once, then run it.** ${question} Add \`--compliant\` (\`--compliant all\` for Claude and ChatGPT) to \`create\` when a
-   listing is the goal; run \`dev\` as its own detached process (\`nohup ${run2} dev \u2026 > mcpblaze-dev.log 2>&1 < /dev/null &\`).
-
-Then, with the user: the listing, \`${run2} connector <name>\` (\`--compliant chatgpt\` or \`all\`), whose page link goes
-to the user first; \`${run2} connector <name> --status\` says what is left. The pages below cover the rest.
+1. **The MCP server and its two links.** No API found above: look where the code keeps it (a frontend's API base URL,
+   \`vercel.json\`, \`render.yaml\`, the README); still none: ask the user for its address or its OpenAPI spec URL.
+   ${question} Run \`dev\` as its own detached process (\`nohup ${run2} dev \u2026 > mcpblaze-dev.log 2>&1 < /dev/null &\`).
+   A \`--name\` you pick gets four random characters (\`resiresi7k3x\`): names are global. Give the user both links, then stop.
+2. **Ask: make it more useful?** Tools shaped around what people ask for, sign-in, who can do what: \`${run2} skills ship\`.
+3. **Ask: list it in Claude and ChatGPT?** \`${run2} connector <name>\` (\`--compliant chatgpt\` or \`all\`), whose page
+   link goes to the user first; \`${run2} connector <name> --status\` says what is left.
 
 ## What MCPblaze is
 
@@ -15640,41 +15640,48 @@ function shipMcpMarkdown() {
   const run2 = "npx mcpblaze@latest";
   return withLatest(`# An MCP server for their API, with MCPblaze
 
-**Links first.** Make the MCP server before designing anything. A deployed API (a URL, or its spec's URL) goes straight
-to step 4; steps 1\u20133 then tune what it made (\`mcp ops hide|show|set\`, \`mcp instructions set\`). Only an app on this
-machine, or an API with no spec anyone can fetch, does 1\u20133 first.
+Three phases. Finish one, then ask the user before starting the next.
+
+## Phase 1: the MCP server and its two links
+
+Deployed (a URL, or its spec's URL): \`${run2} create --target <spec or URL>\`. On this machine: \`${run2} dev --port <port>\`
+(\`--openapi <file>\` when there is a spec) as its own detached process (\`nohup ${run2} dev \u2026 > mcpblaze-dev.log 2>&1 < /dev/null &\`);
+the log says "is live on the internet" after about 20 seconds. A \`--name\` you pick gets four random characters
+(\`resiresi7k3x\`): names are global. Either prints the MCP server and Scorecard links and saves the key to \`.env.local\`
+itself; never show a key in the chat. Give the user both links, then ask: "Want to make it more useful?"
+
+## Phase 2: a more useful MCP
 
 1. **Read what is here.** The route files (every path and method, what each handler does, the id each POST returns), an
    existing \`openapi.yaml\` / \`openapi.json\` / spec route, env files, how the app is protected today (a header, a session,
    nothing). The code is the best source there is: it says what each route does better than any spec.
-   A frontend-only folder: find the backend's base URL it calls, then the same against that URL (a spec if it serves one;
-   \`dev\` captures the routes if not). A black box with no code and no spec: \`dev\` captures the routes nobody documented.
+   A frontend-only folder: find the backend's base URL it calls, then the same against that URL.
 2. **Decide the jobs, then the tools \u2014 from the code** (\`${run2} skills mcp\` has the method): what a person would ask an
    agent for; the one or two operations per job; a dozen tools with verb names and descriptions that say what comes back
    and when to use each; the instruction; which writes need confirmation. For a spec URL, the same against the spec.
-   Explain your choices and show the first-pass draft catalogue before anything is written.
-3. **The spec, if there is none.** Write \`./openapi.yaml\` for the operations the design kept, with the descriptions already
-   written (operation \`summary\` = the tool title, \`description\` = the tool description). Nothing else goes in.
-4. **Make it.** Deployed: \`${run2} create --target <spec or URL>\` (add \`--compliant\` now if a listing is the goal,
-   \`--compliant all\` for Claude and ChatGPT).
-   On this machine: \`${run2} dev --port <port> --openapi ./openapi.yaml\` as its own detached process
-   (\`nohup ${run2} dev \u2026 > mcpblaze-dev.log 2>&1 < /dev/null &\`); the log says "is live on the internet" after
-   about 20 seconds. Either prints the MCP address and saves the key to \`.env.local\` itself; never show a key in the chat.
-   Then \`${run2} mcp catalogue show <name>\` and the \`mcp ops hide|show|set\` / \`mcp instructions set\` touches for what
-   the automatic catalogue did not get right (a spec with more operations than the design kept: hide the rest).
-5. **Sign-in.** Ask once: "Should agents sign in as your users, and where?" Their own OAuth app or OIDC issuer \u2192 the matching
-   \`--oauth\` shape printed by \`${run2} create --help\`; nothing of their own \u2192 the default GitHub sign-in. \`--apikey\`
-   alongside keeps a key door. Later changes: \`${run2} tenant\` (providers, app clients).
-6. **Who can do what.** \`${run2} rule <name>\` lists the record families the spec can lock to the person who created them
+   Explain your choices and show the draft catalogue before anything is written.
+3. **Apply it.** \`${run2} mcp catalogue show <name>\`, then \`mcp ops hide|show|set\` / \`mcp instructions set\` (a spec with
+   more operations than the design kept: hide the rest). An app on this machine with no spec: write \`./openapi.yaml\` for
+   the operations kept (\`summary\` = the tool title, \`description\` = the tool description) and restart \`dev\` with
+   \`--openapi ./openapi.yaml\`.
+4. **Sign-in.** Ask once: "Should agents sign in as your users, and where?" Nothing of their own: the GitHub sign-in it
+   already has. Their own OAuth app or OIDC issuer: \`${run2} tenant\` (providers, app clients; \`${run2} create --help\`
+   prints the \`--oauth\` shapes).
+5. **Who can do what.** \`${run2} rule <name>\` lists the record families the spec can lock to the person who created them
    (one question, pre-approved families; \`--enforce\` turns it on, \`--off\` turns it off and keeps the rules). An admin
    who can override: the dashboard, Tenant \u2192 Admins.
-7. **Try it from Claude Code.** \`claude mcp add --transport http <name> <the MCP address it printed>\`, then \`/mcp\` and
+6. **Try it from Claude Code.** \`claude mcp add --transport http <name> <the MCP address it printed>\`, then \`/mcp\` and
    sign in; call one tool. What a reviewer does, before a reviewer does it.
-8. **List it.** \`${run2} connector <name>\` (Claude; \`--compliant chatgpt\` or \`all\` for OpenAI's directory), unless the
-   create already ran with \`--compliant\`. Give the user the page link first, then follow \`${run2} skills connector\`: the MCP address (one CNAME; relay the exact record),
-   sign-in and the test account, the listing and the review-team answers that you write by its rules, the tests (one
-   \`claude -p\` per use case, from \`--status\`), and the packet. It needs the hosted app, not a tunnel. Stop any time;
-   \`${run2} connector <name> --status\` says what is left. The user submits the packet to Anthropic or OpenAI themselves.
+
+Then ask: "Want it listed in Claude and ChatGPT?"
+
+## Phase 3: listed in Claude and ChatGPT
+
+\`${run2} connector <name>\` (Claude; \`--compliant chatgpt\` or \`all\` for OpenAI's directory). Give the user the page link
+first, then follow \`${run2} skills connector\`: the MCP address (one CNAME; relay the exact record), sign-in and the test
+account, the listing and the review-team answers that you write by its rules, the tests (one \`claude -p\` per use case,
+from \`--status\`), and the packet. It needs the hosted app, not a tunnel. Stop any time;
+\`${run2} connector <name> --status\` says what is left. The user submits the packet to Anthropic or OpenAI themselves.
 
 Report what you did in plain words: the MCP address, who can sign in, what is locked, what is left on the scorecard.
 
@@ -23390,10 +23397,17 @@ async function runOpPerf(o = {}) {
 }
 
 // src/commands/op.ts
-var OPERATOR_EMAILS = /* @__PURE__ */ new Set(["julienpmjacquet@gmail.com", "chkev@umich.edu"]);
 function isOperatorLogin() {
-  const email = loadCredentials()?.email?.toLowerCase();
-  return !!email && OPERATOR_EMAILS.has(email);
+  const token = loadCredentials()?.accessToken;
+  if (!token) return false;
+  const part = token.split(".")[1];
+  if (!part) return false;
+  try {
+    const claims = JSON.parse(Buffer.from(part, "base64url").toString("utf8"));
+    return claims.isOperator === true;
+  } catch {
+    return false;
+  }
 }
 var OP_COMMANDS = [
   { cmd: "cli-policy", blurb: 'Minimum CLI version the platform accepts (--min x.y.z --reason "\u2026" [--force], --reject-unversioned)' },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "apiblaze",
-  "version": "0.21.79",
+  "version": "0.21.80",
   "description": "APIblaze CLI — Chat with your APIs, Manage your API keys, users and groups with the APIblaze serverless proxy",
   "keywords": [
     "apiblaze",