MCP 2.0 Release Notes

Release date: July 2026

MCP 2.0 brings the JupiterOne MCP Server onto the 2026-07-28 revision of the Model Context Protocol — and onto version 2 of the official MCP TypeScript SDK — without breaking a single existing client.

This is a compatibility and correctness release, not a feature release. The tool surface was unchanged from 1.4.0: the same 28 tools, the same names, the same parameters. (2.1.0 later added a 29th — see The 2.x point releases.) What changes is how well the server describes itself to the client on the other side, and which clients can talk to it at all. Newer clients get the current protocol with cache hints and honest result schemas. Older clients get exactly the wire they got before.

Do I need to do anything?

Remote server users: no. The hosted server always runs the current release, and both protocol eras are served from the same URL.

Local server users: check your Node version. MCP 2.0 requires Node.js 20 or later, up from 18. This is the only breaking change in the release. See Upgrading the local server.

What is new in MCP 2.0

Feature	What it means for you
2026-07-28 protocol support	The server speaks the current MCP revision to clients that ask for it, so newer assistants get the newer capabilities
Both protocol eras, one endpoint	Older clients are served exactly as before on the same URL — nothing to reconfigure, nothing to migrate
Cacheable tool list	Clients can cache the tool list for an hour instead of re-fetching it on every connection, cutting startup overhead
Accurate query result schema	execute-j1ql-query and get-query-results now advertise their real two-shape contract — completed results or an in-progress handle — instead of a lowest-common-denominator approximation
RFC 9207 authorization responses	The remote server returns its issuer identifier on authorization responses, so clients can verify which server answered — a defence against mix-up attacks
Client identity in diagnostics	Support can see which client and version made a call, which makes client-specific problems far faster to diagnose
Node.js 20 floor (breaking, local only)	The local server now requires Node 20 or later
Open output schemas (2.0.2)	Strict-validating MCP clients no longer reject responses from get-rule-details, get-dashboard-details, and 22 other tools

Both protocol eras from one endpoint

MCP is a versioned protocol, and the 2026-07-28 revision changed how a connection is opened. Rather than force every client to move at once — or run a second endpoint — the server decides per connection:

• A client opening with the 2026-07-28 handshake gets the modern protocol, including the cache hints and schema improvements below.
• A client opening with the legacy handshake gets byte-for-byte the wire it got from MCP 1.x.

This holds for both deployment modes: the hosted remote server and the local stdio server. There is no configuration, no separate URL, and no migration step. If your assistant worked against MCP 1.x, it works against 2.0 unchanged.

This is not a theoretical concern. Claude — including the connector directory listing — and ChatGPT both still open connections on the 2025-era handshake. Serving both eras is what let us adopt the new protocol revision without waiting on those clients or breaking the directory connector that most customers install through.

Cacheable tool list

The server now tells 2026-era clients that its tool list is cacheable for an hour, so a client does not need to re-enumerate 28 tools on every connection. The hint is marked private to the connection, because the list genuinely differs between a multi-tenant connection and one pinned to a single account — a shared cache would serve the wrong list.

Legacy clients are unaffected: the hint is only emitted on 2026-era responses.

An accurate schema for query results

Since MCP 1.3.0, execute-j1ql-query can return one of two genuinely different things: a completed result envelope, or an in-progress handle with a resultsUrl to resume from. The older protocol could only describe a single object shape, so the server advertised every field as optional — technically permissive, but it told clients almost nothing.

2.0 advertises the real contract: a union of the two shapes, with the in-progress handle strictly typed so status and resultsUrl are required and a malformed handle cannot pass as a result set. Assistants get an accurate picture of what to expect, and can branch on it properly rather than guessing.

Clients that only understand a single object shape at the root keep working — the schema still presents as an object there.

RFC 9207 authorization responses

The remote server now includes its issuer identifier (iss) on authorization responses, per RFC 9207. This lets a client confirm that the response it received came from the authorization server it actually started the flow with, closing off a class of mix-up attack in which a malicious server tries to have a code redeemed at the wrong place.

This is transparent — no connector reconfiguration, no change to how you sign in. It layers on top of the per-client registration, PKCE enforcement, and exact-match redirect validation delivered in MCP 1.0.

Client identity in diagnostics

Operational telemetry now records the client name, client version, user agent, and protocol version that made each call, alongside the tool name and outcome already captured. Query content stays redacted, and results, parameters, and action payloads are still never stored.

The practical benefit is support turnaround. Client-specific problems — a particular IDE mishandling a response, one client version failing where another succeeds — used to be invisible; they are now identifiable from the first report.

Upgrading the local server

MCP 2.0 requires Node.js 20 or later. This comes from the MCP SDK v2 requirement and is the release's only breaking change. It applies only to the local (stdio) server — remote server users are unaffected, since the runtime is ours.

Check your version in the same shell your AI client uses:

node --version

If it reports v18 or lower, install Node 20 or later, then restart your AI client. Note that on macOS, GUI applications do not always inherit your shell's PATH — if your client still fails after upgrading, point it at an absolute path to npx (find it with which npx).

If you run the local server with npx @jupiterone/jupiterone-mcp, you pick up the latest version automatically on each run. For a global install, update it with:

npm install -g @jupiterone/jupiterone-mcp

The 2.x point releases

Version	Released	Highlights
2.0.1	August 2026	Updated the bundled J1QL parser, so local syntax validation matches the current query service grammar
2.0.2	August 2026	Opened tool output schemas so strict-validating clients accept real responses
2.1.0	August 2026	Added delete-rule, taking the tool count to 29

Opened output schemas (2.0.2)

Most tools return more data than their published schema documents — get-rule-details documents 8 fields and returns 28; get-dashboard-details documents 5 and returns 19. The published schemas nevertheless declared themselves closed, meaning no additional fields allowed. The two statements contradicted each other.

Clients that ignore the advertised schema never noticed. Clients that validate structured output against it — including Amazon Kiro and anything built on the official MCP client SDK — rejected the response outright with an "additional properties" error, making those tools unusable on those clients.

2.0.2 opens the schemas across all 24 affected tools, so the documented fields remain the contract while the full payload passes validation. Nothing about the data returned changed; only the schema that describes it. A regression test now asserts that no tool advertises a closed shape anywhere in its output schema.

This was never a 2.0 regression — the schemas had been closed since structured output shipped in MCP 1.0. If a strict-validating client rejected JupiterOne tool responses for you before August 2026, 2.0.2 fixes it.

Rule deletion (2.1.0)

delete-rule closes the last gap in rule management. Until 2.1.0 an assistant could create and update rules but never remove one, so a rule created with a name or tag that collided with an existing one left no way to clean up — by far the most common failure in rule creation.

The tool is annotated as destructive, so your MCP client prompts before it runs. Two things to know:

• It is irreversible. The rule's configuration cannot be recovered.
• It does not dismiss alerts the rule already raised. Those stay active. If you want a rule to stop firing but keep its configuration and evaluation history, ask for its polling interval to be set to DISABLED instead — that is a reversible change, and deletion is not.

Getting started

Remote server: nothing to do. Your connector already runs 2.0 — including the connector installed from claude.ai/directory/jupiterone.

Local server: confirm Node 20 or later, then restart your AI client. npx picks up the new version automatically.

Verify the upgrade. Ask your assistant:

"Test my JupiterOne connection"

test-connection reports the package version alongside your identity and permissions, so you can confirm which release you are on.

For the full setup guide, tool reference, and FAQ, see JupiterOne AI Integration (MCP Server). For the 1.x line, see What's new in MCP 1.0.