What's new in Spec0.

Pointing your coding agent at your API catalog used to start with installing our CLI. It doesn’t any more — Claude Code can add a remote MCP server natively, and that’s now the first thing we offer you.

• One line, no dependency of ours. Copy the claude mcp add command from your home screen and paste it into a terminal. Claude Desktop gets the config block it needs instead, since it has no equivalent command.
• The CLI is still there if you want it. spec0 setup does everything in one step — auth, MCP server, and the Claude skill — and it’s now offered as a choice rather than the only route.
• You can see whether it actually worked. The card shows whether you’re connected, and it only says so once your agent has genuinely made an authenticated call. Adding the server and signing in are two separate steps, and the card tells you that up front instead of leaving you wondering why the tools say you’re unauthenticated.

There’s a “How this works” link that opens the agent docs without navigating you away from what you were doing.

Bringing your own LLM key meant pasting a credential into a form that never explained what would happen to it. That page now leads with the answer.

• Three plain statements up front: the key runs on your account and bills there, we record token counts per feature but never the content of prompts or responses, and you can revoke it whenever you like.
• The features that will use it are listed, so you know what you’re switching on.
• Direct links to the provider console for Anthropic and OpenAI, so you’re not hunting for the page that issues the key. Bedrock and Azure link nowhere rather than somewhere misleading — they have no single equivalent page.
• The explanation opens in place. Reading it doesn’t cost you the half-filled form you were in the middle of.

We also fixed a set of links that pointed at a settings page that doesn’t exist — including the one shown to people who have no key configured yet, which was exactly the wrong moment for a dead end.

If you’ve just signed up, the first screen should tell you what to do — and ours was pointing at a demo. This release rewrites that first run.

• The home screen leads with your own API. Uploading a spec, importing from GitHub, and pushing from the CLI are all offered up front, with the CLI command right there to copy. The sample petstore is still one click away if you’d rather look around first.
• Every step in the getting-started checklist is now a link to the page that completes it, and you can dismiss the checklist once you’re done with it.
• Your inbox opens with a short guide. It reads from the same signals as the checklist, so it knows what you’ve already done and only points at what’s left.
• If you were invited to an organisation but not yet added to a team, creating an API used to present a disabled button with no explanation. It now tells you what’s missing and who can fix it.

We also removed a product tour that had stopped working — several of its steps pointed at parts of the interface that no longer exist, and once dismissed it never came back.

The Agent readiness score on your home page was a stand-in: every API that passed linting showed the same number, so comparing two APIs told you nothing and the score gave no hint about what to improve.

It now reads your published spec and scores three things that decide how usable an API is to an AI agent:

• Descriptions (40%). An agent picks an operation by reading its summary. An unnamed operation is effectively invisible to it.
• Examples (40%). One concrete request or response example does more for payload accuracy than a schema alone.
• Non-deprecated operations (20%). Deprecated operations still in the document are ones an agent can and will call.

The card shows each factor with its score and the counts behind it — “12 of 30 operations” — so “why is it 61” is answerable without leaving the page. The per-team Readiness column in analytics uses the same scorer, so the two views can’t disagree about the same API.

An API with no published spec now shows ”—” rather than a score. We’d rather say unknown than put a low number next to an API nobody has published yet.

If you’ve read our governance docs recently, you’d have come away thinking breaking-change policy was something we planned to build. It has been running on every publish for months. That was our mistake, and it’s fixed.

Governance now documents what actually ships: five policy sections — breaking change, naming, required fields, versioning, and spec sources — each evaluated server-side on every publish, each with its own mode:

• Off — not evaluated.
• Warn — surfaced at publish time, but the publish succeeds.
• Block — the publish is rejected.

The page now also documents what a rejection looks like end to end: the HTTP status, the error payload, and the CLI exit code, so you can wire it into CI without reverse-engineering it. It’s honest about the limits too — the breaking-change check fails open if the diff engine can’t run, so it’s a strong guardrail rather than a proof of compatibility.

We’ve also added a check to our own build that fails when a “coming soon” claim in the docs passes its review date. Our docs are served directly to coding agents through Spec0’s MCP tools, so a stale page doesn’t just misinform a reader — it misinforms the assistant sitting in your editor.

“Subscription” was doing two jobs at once — I depend on this API and notify me when it changes — and neither reading was obvious from the word. Now they’re separate ideas with separate names.

• A grant is the approved permission for one team to call specific operations on another team’s API. It’s what a producer team’s admin reviews and approves.
• A consumer is the team holding that grant.
• Subscribing now means only one thing: opting in to notifications.

You’ll see the new wording across the dashboard, and the Subscribers page is now Consumers. Nothing about your existing access changed — the same teams have the same permissions on the same operations, under clearer names. Roles and permission settings are unchanged.

This also sets up work we’re building next: because a grant records exactly which operations a team was approved for, it can drive things like scoped tooling and precise blast-radius answers when an API changes.

Connecting a repository used to work only if your API document was named openapi.yaml. A repo with swagger.json, api.yml, or docs/api.yaml came back as “no specs found” — and your first real interaction with Spec0 was typing a file path by hand.

• We now recognise the conventions projects actually use. swagger.*, api.*, spec.*, orders-api.yaml, openapi.v1.yaml and the rest are found, while package.json, tsconfig.json, generator configs, and anything inside node_modules, vendor, dist or test fixtures stay out of your way.
• The list is ordered by how likely each file is to be the one you meant — an exact openapi.yaml at the repository root comes before a candidate buried four directories down.
• You can browse the repository. If your spec is somewhere we didn’t guess, or the repo holds several and you know which one you want, open the file browser and pick it. It filters to YAML and JSON by default, has a search box, and can show every file when you need it.
• The branch you choose is now the branch we read. The source-branch field was previously ignored when scanning for files — if you pointed Spec0 at a branch other than the default, it quietly looked at the default anyway. It doesn’t any more.

Whatever you pick is validated as a real OpenAPI document before the wizard moves on, so a wrong file tells you immediately instead of failing at the end.

Strict validation used to check the JSON request body and nothing else, so a request that omitted a required query or header parameter still got a normal response. That made the mock more forgiving than the real API it stands in for — the opposite of what you want from a contract test.

If a mock is set to Strict, it now also rejects requests missing a required query, path, or header parameter.

This is a behaviour change worth knowing about: a caller that was quietly omitting a required parameter will start getting rejections. That is usually the bug the mock exists to catch — but if you’d rather not enforce it yet, the mock’s Request Validation Mode setting has Lenient and Disabled options.

Mocks on the default Lenient mode are unaffected.

An OpenAPI spec describes one API in isolation — it can’t tell you who owns it, who depends on it, or what breaks if it changes. Spec0’s MCP server, and the Ask Spec0 chat, can now answer those by reading your organisation graph:

• Who consumes this API? The owning team, the subscribers, and each consumer’s team and status — so an agent can reason about the blast radius of a change before you make it.
• What does a team own and depend on? A team’s APIs, the APIs it consumes, and its members — in one call.
• A lay of the land. Team, API, and service totals with per-team ownership and consumption counts, to orient before drilling in.

These join the existing ownership lookups — who you are, who owns a given API, and which teams you’re on — so an agent has both the “who owns what” and the “who depends on what” directions of the graph.

See the Agents & MCP docs for the full tool list.

This release cleans up several things you told us about:

• Environments show their APIs. Opening an environment’s page now lists every API configured for it and the URL it serves at, instead of always reading “0 APIs configured.”
• Notifications persist. Alerts stay in the notification bell until you’ve read them.
• Generating a changelog keeps your draft. The AI changelog generator no longer wipes text you’d already written in the body.
• Correct team dates. Teams show their real creation date, not January 1970.
• Commit links go to GitHub. Clicking a commit opens it on GitHub, not a dead in-app route.

The home used to withhold the operational dashboard until you personally had connected both the CLI and the MCP server — so an admin with a fully set-up organisation could still be stuck on a “connect your CLI” nudge. That’s fixed. If your organisation has APIs, you land on the operational home; connecting your own tools now personalises it rather than blocking it.

• A “needs attention” worklist. The specs and APIs that need a look — gathered in one place, scoped to your team’s APIs, most important first.
• An agent-readiness signal. An at-a-glance score for how ready each of your APIs is for agents to consume, with a per-API breakdown.
• Honest status chips. The header shows your real MCP, CLI, and GitHub connection state — each unconnected one links straight to its setup page — instead of pretending everything is wired up.
• For org leads. Holders of the analytics role get a new organisation-wide view at /analytics, rolling up API coverage and per-team governance across the whole org.

Everything reads in plain language, and anything we can’t compute yet says so plainly rather than showing a hollow zero.

Inviting someone to your organisation now sends them a Spec0 email with an accept link. It works whether they’re brand new to Spec0 or already have an account in another organisation — accepting simply adds your organisation to the ones they belong to, and they keep the one they already had.

Pending invitations are now manageable, too. If an invite expired or got lost, resend it; if you invited the wrong address, cancel it to free that email up to be invited again. Both live on Settings → Members, next to each pending invite.

Spec0 used to tie every account to a single organisation. Now you can belong to several — your own, your company’s, a client’s — and switch between them from the organisation switcher next to the Spec0 wordmark. Everything you work with — APIs, teams, mocks, members — follows the organisation you’re currently in.

Your role is per-organisation, too. You can be an admin in one and a regular member in another, with permissions scoped to wherever you’re working at the time.

This is the groundwork that also makes cross-company invitations work cleanly: being invited somewhere new no longer means giving up the organisation you already have.

The first time you sign in, Spec0 now asks you to name your organisation instead of dropping you into a placeholder “My Organization”. You can invite teammates right there in the same step, or skip it and do it later.

From there, a getting-started checklist walks you through the core path — publish your first API, connect an AI agent over MCP, spin up a mock, and invite your team — so there’s always an obvious next step rather than a blank dashboard.

The docs now have a guided walkthrough that sits alongside the fast-path quickstart. Where the quickstart is just the commands, the walkthrough explains the why behind each step and the decisions you’ll face.

It covers the whole journey in order: creating a team and what teams are for, installing the CLI, publishing your first API, connecting an AI agent over MCP (with example prompts), setting org-wide governance rules, adding Spectral lint quality gates in CI, spinning up a mock, and finally opening an API to the public registry.

We’ve also dropped recommendations in as you go — the biggest one: let Git drive publishing rather than pushing specs by hand. Your registry stays correct by construction, and breaking changes get caught in the PR that introduces them.

The post-login home used to show every panel to everyone, whether you’d published nothing or run the platform for months. It now detects where you are and shows one focused layout with a single primary action:

• Just starting? You get a short getting-started checklist and a sample Pet Store API to explore — no blank account, ever.
• Have APIs but no agent connected? You get copy-paste snippets to wire up the MCP server and CLI, plus a look at what your org has already published.
• Fully set up? You get the part that matters day to day: changes in the APIs you depend on, your governance quality score, and a quiet summary of recent activity.

Everything reads in plain developer language — “+2 endpoints, 1 breaking” rather than “version published” — so the feed tells you what actually changed.

We expanded what your coding agent can do over the API Registry MCP:

• Ownership & identity. Agents can find out who owns an API and which team is responsible, and confirm the identity of the org they’re connected to. “Who owns the payments API and what’s its quality score?” now has a real answer.
• Operation & component search. Instead of pulling a whole spec, agents can search for the exact operation or schema component they need and read just that.
• Bounded spec reads. Fetching a full spec is now size-bounded, so a large API doesn’t flood the agent’s context. Most questions resolve in a few hundred tokens instead of tens of thousands.

The net effect: agents answer more questions, more precisely, while using a fraction of the context they used to.