← Back to blog
·10 min read·By

Three new ways to call Prism — CLI, MCP, and SDKs

v1.8 ships a command-line tool, an MCP server for Claude Desktop / Cursor / Zed / Continue / Cline, and first-party Python + Node SDKs. Every operational surface — cache settings, routing policy, budgets, audit, workspaces — now scriptable from outside the web dashboard. Honest reporting on what shipped and what's gated.

aiapiclimcpsdkdeveloper-toolsinfrastructure

For most of v1.x, the only way to operate Prism — change cache settings, set routing policy, cap a budget, audit who did what — was through the web dashboard. That was fine when the product was an OpenAI-compatible chat endpoint plus a small marketing site. It stopped being fine the moment we asked customers to live with Prism in production.

v1.8 closes that gap. Three new surfaces, all backed by the same underlying API:

  • prism CLIpip install ssimplifi-cli, 19 commands, every operational action from the dashboard scriptable.
  • prism-mcp servernpm install -g @ssimplifi/prism-mcp, runs in Claude Desktop / Cursor / Zed / Continue / Cline, exposes Prism's tools to whatever AI is running there.
  • Python + Node SDKspip install ssimplifi / npm install @ssimplifi/prism, drop-in replacements for the OpenAI SDK in each language, with Prism kwargs added.

Plus the API itself — every dashboard route now accepts a regular API key, the OpenAPI spec is publishable at https://api.ssimplifi.com/v1/openapi.json, and Swagger UI is mounted at /v1/docs. The dashboard remains the friendliest surface; it just no longer the only one.

Why three, and why now

The honest reason is friction. I find myself running half my own dev work through CLIs. So do the engineers I've shown Prism to. Telling a developer "log into the web dashboard to update your cache TTL" when they're knee-deep in a deployment is the wrong UX. If the product is built for developers, every operational surface needs to be programmable.

MCP was the harder call. Anthropic launched the protocol in October 2024; by mid-2026 every serious AI-coding client speaks it. That's a distribution channel — when an AI assistant can call your gateway directly as a tool, the question shifts from "should I integrate Prism" to "Prism is already there." Three months ago this would have been speculative. Now it's table-stakes for any developer-facing AI infrastructure product.

SDKs were the lowest-cost win. We've been telling customers "we're OpenAI-compatible — just change the base URL." That's technically correct, but in practice the X-Prism-* headers (mode, session_id, cache) require extra_headers={"X-Prism-Mode": "..."} ceremony on every call. A first-party SDK that exposes them as Python kwargs or TypeScript fields makes the API feel like a real product instead of "OpenAI plus weird headers."

What's new in the API

v1.8 P1 (the API completeness pass) is the prerequisite for everything else. Two real changes:

Dual auth on every dashboard route. Before P1a, account-management endpoints — cache, policy, budget, audit, workspaces — required a Supabase JWT (i.e. a web login). After P1a, they accept either the JWT or a regular prism_sk_* API key. The key path is tier-gated: Pro/Team get programmatic access; Free/PAYG get a clean 402 tier_upgrade_required error with an upgrade URL. This is the dividing line we locked: consumption + your own usage data is universal, operational orchestration is Pro+.

OpenAPI spec + Swagger UI. Every route has a tag, a description, and a response model. Webhooks are explicitly hidden so they don't leak into the public spec. The result is publishable docs at https://api.ssimplifi.com/v1/openapi.json that auto-generated SDK clients can consume directly. The Swagger UI at /v1/docs gives prospects an interactive surface before they sign up.

This is the boring half of v1.8. It's also the half that unlocked everything else — every other piece below is a thin layer over the API surface that P1 made cleanly programmable.

The CLI

pip install ssimplifi-cli
prism configure              # paste your prism_sk_... key
prism chat "What is..."      # one-shot completion, any tier
prism models --provider groq
prism usage --days 7
prism cache stats

Nineteen commands, ~40 sub-commands. Some are universal (chat, models, whoami, balance, usage, keys list). Most are Pro+ (cache, policy, budget, audit, orgs, projects, members, invites, subscription, provider-health).

The tier check happens cleanly. If you try prism cache stats on a Free account, the CLI prints:

Tier upgrade required.
  Current tier: free
  Programmatic access to this endpoint requires Pro ($19/mo) or Team ($49/mo).
  Upgrade: https://ssimplifi.com/pricing

Not a 401 with a JSON dump. Not a half-broken state. A clean, actionable message telling you exactly what to do.

The CLI also has a soft-gate posture: prism chat and prism models work on every tier. You can install the CLI on Free, use chat from your terminal, discover that admin commands exist, and upgrade when you actually need them. That feels right — gating the tool entry point would push curious developers away before they've tried the product.

The MCP server

This is the piece I'm most excited about. Once you've got Claude Desktop (or Cursor, or Zed, or Continue, or Cline) configured with Prism's MCP server, the AI can call Prism's catalog, estimate costs, check your usage, submit feedback, and — with the optional write-scope key — change cache settings, revoke API keys, set routing policy. All from inside the conversation.

// ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "prism": {
      "command": "prism-mcp",
      "env": {
        "PRISM_API_KEY": "prism_sk_..."
      }
    }
  }
}

22 tools total — 12 read-only, 10 write. The write tools are gated by two coordinated layers:

Layer 1 — Per-tool confirmation. Every write tool takes a confirmed: boolean argument that defaults to false. Without it, the tool returns a structured confirmation_required response describing the action + its specific consequences. The AI client surfaces the consequences to you in natural language ("This will revoke the API key created on March 14 that's currently in production. Are you sure?"). You agree; the AI re-calls with confirmed: true; the action executes. Standard MCP destructive-tool shape — Anthropic's reference servers use the same pattern for file deletion and git operations.

Layer 2 — Separate write-scope key. Your regular prism_sk_* API key cannot mutate state via MCP. Period. To enable writes, you run prism mcp enable-writes in the CLI, receive a confirmation email, click the link, get a separate prism_msk_* key, and add it to your MCP config as PRISM_MCP_WRITE_KEY. Two-step opt-in. Without it, write tools return a clean write_disabled response with a link to enable.

Threat-model-wise: prompt injection convincing the AI to revoke your key gets blocked at Layer 2 (no write key in scope). A malicious actor stealing your MCP config file leaks only read access. The AI accidentally calling a write tool mid-conversation gets caught at Layer 1 (consequence text surfaces; you don't blindly agree). Together they're belt + suspenders.

I went back and forth on whether MCP should be read-only-only. The argument for restriction: AI clients are inherently noisy environments — a bad prompt-injection or a misread instruction shouldn't be able to mutate production state. The argument against: limiting MCP to read tools means the AI can answer "what's my cache hit rate" but not "lower it to 50% TTL" — half a product. The two-layer design splits the difference: the capability exists, but you have to opt in explicitly, and even after opting in, every destructive call asks first.

For the read half, no opt-in needed beyond PRISM_API_KEY. The MCP server checks /v1/whoami on startup, refuses to register any tools if your account isn't on Pro+ (Free/PAYG see "0 tools available" + an explicit upgrade message), and otherwise lights up all 12 read tools immediately.

The SDKs

ssimplifi (PyPI) and @ssimplifi/prism (npm). Both are thin wrappers over the official openai SDK in their respective languages — the canonical client for OpenAI-compatible APIs. We extend rather than re-implement, so you get the OpenAI SDK's streaming, retries, type safety, and response shape for free.

from ssimplifi import Prism

client = Prism(api_key="prism_sk_...")

response = client.chat.completions.create(
    messages=[{"role": "user", "content": "Hello"}],
    mode="balanced",            # Prism kwarg → X-Prism-Mode header
    session_id="user-abc",      # Prism kwarg → X-Prism-Session header
)

That's the entire diff from plain openai.OpenAI. Change two import lines, get auto-routing + multi-turn memory + caching + multi-provider failover. The mode, session_id, model_prefer, cache, and request_tags kwargs translate to X-Prism-* headers; you never have to remember the header names.

Plus the admin surface: client.models.list(), client.usage.summary(days=7), client.cache.stats(days=7), client.keys.create(name="staging"), client.whoami(). These hit the dashboard endpoints directly — the same ones the CLI talks to — through an httpx side-channel.

Node SDK is structurally identical. import { Prism } from "@ssimplifi/prism", new Prism({ apiKey }), same kwargs.

This closes the third item from our competitive-gaps doc — every dev-tool comparison checks for first-party SDKs. "Works with the OpenAI SDK" is technically correct but reads as a gap on a matrix; "Has prism-python + prism-node" doesn't.

Tier strategy, again, for the people in the back

It would be tempting to gate the CLI behind Pro. Stripe-style: pay $19/mo and you unlock the developer experience. We deliberately don't. Free and PAYG tier accounts can install the CLI and use it for chat. They just can't run the admin commands programmatically. That feels right — gating tools is a way to push curious developers away before they've actually used the product. We'd rather have Free customers writing prism chat "..." from their terminal and discovering Prism that way than gate them at the install step.

MCP is more restrictive — the server registers zero tools on non-Pro accounts. The reasoning is different: MCP is operational by nature, not a casual try-it surface. Free customers playing with MCP would mostly hit dead ends. Pro/Team is where the value materializes.

SDKs are universal — they're libraries, not products. The chat endpoint they wrap is universal; the admin endpoints they expose error cleanly for non-Pro callers. There's no point in restricting library installation.

What we shipped and what we didn't

Shipped, in production, today: P1 API completeness, P2 CLI (local-ready, awaiting publish), P3 MCP server with write-protection (local-ready), P4 Python + Node SDKs (local-ready).

What's left: the actual pip / npm publishes. Each requires my credentials sitting on the publishing machine — ~/.pypirc for PyPI, npm login for the @ssimplifi scope on npm. I keep those tokens off CI deliberately; deploys stay manual on this project. Once I sit down for thirty minutes with the four publish commands and eight defensive name claims, the install snippets above start working from pip install / npm install instead of from a local checkout.

What we deliberately deferred: the original v1.8 plan had two more sub-phases — P1d (renaming /v1/dashboard/* to /v1/account/* as the canonical path) and P2d (browser OAuth flow for the CLI). P1d turned out to be cosmetic — Swagger UI groups by tag, not URL prefix, so the rename adds churn without much customer-visible improvement; we kept /dashboard/* and will revisit at v2.0 with a proper deprecation window. P2d was scoped against routes that were JWT-only; P1a's dual-auth eliminated that category, so OAuth-from-CLI no longer has a use case. Two sub-phases gone, no functionality lost.

The bigger pattern

v1.7 was about adding providers. v1.8 was about adding ways to access the providers — same surface, more ways in. The pattern that matters: every operational action on Prism is now reachable from at least three independent surfaces (web, API, CLI), with MCP and SDKs as layered access patterns on top of those. None of them are second-class. None of them are missing features the others have. The dashboard is no longer the canonical surface — the API is, and the dashboard is just one of four clients.

That shift matters because it's how serious infrastructure products age. Cloudflare's dashboard is great; their CLI (wrangler) is what most developers actually use. Stripe's dashboard is great; their SDKs are what production runs through. Prism is now in that shape. The dashboard ships features first, but it doesn't gate features — anything you can click, you can also script.

Try it:

pip install ssimplifi-cli
prism configure
prism chat "what just shipped in v1.8?"

For the MCP install — drop the config snippet from our MCP install guide into Claude Desktop or Cursor, restart, and the tools appear.

The live spec, with every endpoint documented: https://api.ssimplifi.com/v1/docs.