MCP server

@saaspro/mcp puts SaaS Pro Max inside Claude Code, Claude Desktop, Cursor or any other Model Context Protocol host. The agent can then read your analytics, triage your errors, roll out a flag, and install the SDK into a codebase — with the same permissions the person holding the token has in the console.

It is a thin shell over the Management API: no state, no cache, no stored credential. Every authorization decision is made by the platform, so nothing about your security posture depends on the agent.

Install

claude mcp add saaspro --env SPM_TOKEN=spm_pat_xxxxxxxx -- npx -y @saaspro/mcp

Or write the configuration yourself. Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "saaspromax": {
      "command": "npx",
      "args": ["-y", "@saaspro/mcp"],
      "env": {
        "SPM_TOKEN": "spm_pat_xxxxxxxx",
        "SPM_HOST": "https://saaspro.dev"
      }
    }
  }
}

Cursor takes the same object in .cursor/mcp.json (per project) or ~/.cursor/mcp.json (global). VS Code uses .vscode/mcp.json with "type": "stdio".

Get a token from Organization → Access tokens (belongs to the team) or Account → Personal access tokens (acts as you).

Tools

Every app-scoped tool takes app, which accepts an application id or the orgSlug/appSlug form list_apps returns.

ask_saaspromax is the escape hatch: it runs the platform's own tool loop and returns a written answer with the tools it used. Prefer a specific tool when you know what you need — it is cheaper, and the raw data is easier to reason about.

When the assistant wants to change something

The platform assistant can act, not only read, so ask_saaspromax has two kinds of outcome. A question that only needs reads comes back as an answer. A question that would change something comes back as an answer plus one or more proposed actions, each with an id, the tool it would call, its arguments, its effect (write, destructive or external) and a human-readable preview of the change. Nothing has been written at that point.

Approving is a separate call, against the assistant endpoints:

curl -X POST -H "Authorization: Bearer $SPM_TOKEN" -H 'content-type: application/json' \
  -d '{"reason":"Agreed in the release channel"}' \
  "$SPM_HOST/api/v1/apps/acme/site/ai/actions/act_1/approve"

GET /apps/{app}/ai/actions lists what is waiting, and /reject declines one with a reason. Approving executes the action, writes the audit row and resumes the conversation, so a later ask_saaspromax in the same conversation can report the outcome.

Two limits apply to an MCP host in particular:

• A token that could not perform the action itself cannot approve it. read scope can ask, and can watch proposals appear, but not approve them.
• A destructive action — a deletion, a revocation, a production write, minting a key — cannot be approved through the API at all. It needs a fresh passkey, which only a console session has, so the endpoint answers 403 with passkey_required and a person finishes it in the console.

The design is deliberate: an agent may propose, a person disposes. If your host wants direct writes instead, use the specific tool (upsert_flag, update_error_status, update_person) with a write-scoped token — those act as the token's owner and need no approval.

Resources

saaspro://docs/{slug} serves the deployment's own documentation as markdown: SDK guides, module references, integration setup, the API reference. The list comes from GET /api/v1/docs, so it always matches the platform the token points at rather than a snapshot bundled with the server.

Prompts

The agent skills go further: they carry per-framework reference snippets and an output template, and they trigger on what you ask for rather than needing to be picked from a menu.

Security

• Scope the token to the job. A read-only token is enough for reporting and error triage. write adds module data. admin adds ingest keys — give it only when the agent is genuinely installing an SDK.
• Tokens are organization-scoped. An organization token reaches exactly one organization with the developer role. A personal token acts as its owner and reaches that owner's organizations, each with its own role permissions. Neither can delete an organization or an application, change members, or mint further tokens: those need a console session with a fresh passkey.
• Nothing is stored on your machine. The token is read from the environment and forwarded as a bearer credential. It is never written to disk, never logged, and never included in a tool result. The server logs to stderr only — stdout carries JSON-RPC.
• Personal data stays gated. Emails and names are masked unless the token's bearer holds people.pii.read.
• Ingest keys are shown once. create_api_key returns the value in that one response; only a hash is stored. Put it in an environment file, never in source and never in a chat transcript.
• Every write is audited as an action by the person the token belongs to, tagged via: management-api with the token's id — so a leaked token's blast radius is always answerable.
• Revocation is immediate. Revoke in the console and the next tool call fails; a personal token also dies the moment its owner leaves the organization.

Troubleshooting

Debug against a real deployment with the inspector:

SPM_TOKEN=spm_pat_xxxxxxxx npx @modelcontextprotocol/inspector npx -y @saaspro/mcp