MCP 1.0 Release Notes

Release date: June 2026

MCP 1.0 is the first generally available release of the JupiterOne MCP Server. It turns JupiterOne into something your AI assistant can operate directly: ask a question in plain language and the assistant picks the right tool, writes the J1QL when a query is needed, and works with your graph, alerts, rules, dashboards, and integrations on your behalf.

The 0.x previews proved the idea. 1.0 is the release that makes it safe to hand to a security team — every tool declares what it does and what it returns, failures explain themselves instead of surfacing raw API errors, and the hosted remote server runs a fully hardened OAuth 2.1 flow with a consent screen you see before anything is granted.

What is new in MCP 1.0

Feature	What it means for you
24 tools across six domains	Query execution, alert monitoring, rules management, dashboard management, integration monitoring, and account discovery — all reachable in natural language
Hardened OAuth for the remote server	Per-client registration, enforced PKCE, exact-match redirect validation, and a JupiterOne-branded consent screen that tells you what a connector is asking for before you approve it
Multi-account access	list-accounts shows every JupiterOne account your sign-in can reach, with the connector URL for each one
Structured output	Every tool publishes a schema for what it returns, so assistants read results reliably instead of re-parsing prose
Tool annotations	Read, write, and destructive tools are labelled, so your MCP client can ask for approval before anything changes
Honest failure messages	Permission and authentication problems come back as "access denied, here is what to do" rather than an opaque error, with credentials and internal detail stripped out
Working deep links	Results link back to the right place in the JupiterOne app, so you can open a rule, query, or dashboard the assistant just referenced
Listed in the Claude connector directory	One-click install from claude.ai/directory/jupiterone, plus the protocol-level self-description — name, icon, readable tool titles — that the listing required

24 tools across six domains

MCP 1.0 ships 24 tools. Your assistant chooses among them automatically — you ask a question, it decides whether that means running a query, listing rules, or checking an integration job.

Domain	Tools
Query execution	execute-j1ql-query
Alert monitoring	get-active-alerts
Rules management	list-rules, get-rule-details, create-inline-question-rule, update-inline-question-rule, evaluate-rule, list-rule-evaluations, get-rule-evaluation-details, get-rule-evaluation-query-results, get-raw-data-download-url
Dashboard management	get-dashboards, get-dashboard-details, create-dashboard, create-dashboard-widget, update-dashboard
Integration monitoring	get-integration-definitions, get-integration-instances, get-integration-jobs, get-integration-job, get-integration-events
Account	test-connection, list-accounts, list-entity-types

Query results support cursor-based pagination, and integration listings now return a reliable stop signal, so an assistant paging through a large result set knows when it has reached the end instead of looping.

note

The 1.x line grew this to 28 tools. See The 1.x point releases below.

Hardened OAuth for the remote server

The hosted remote server — the option most customers use, connected from claude.ai, Claude Desktop, Cursor, and other MCP clients — received a full authorization rework for 1.0.

• Per-client registration. Each connector that registers gets its own client identity with its own persisted redirect URIs, rather than sharing one. Registrations expire after 90 days; an active connector re-registers transparently, so you never notice.
• Exact-match redirect validation. A connector can only be sent back to a redirect URI it registered, matched exactly. Prefix and wildcard matches are rejected.
• PKCE enforced. Proof Key for Code Exchange is required at both the authorization and token steps, so an intercepted authorization code is useless on its own.
• Authorization code flow only. /authorize accepts nothing else.
• A consent screen you actually read. Before you are handed to sign-in, a JupiterOne-branded interstitial names the connector requesting access, summarises the permissions it will receive, and links to the relevant policies. Nothing is granted until you approve it there.
• Sanitized errors. OAuth failures return standards-compliant error codes without leaking secrets or internal detail, and secrets are never written to logs.

Your existing permissions still govern everything: the remote server acts as the signed-in user, and the local server acts as the owner of the API key you configure. MCP grants no access your account does not already have.

Session expiry your client can act on

When a token expires, the remote server now returns a standards-compliant 401 with a WWW-Authenticate challenge that distinguishes expired (your client should refresh silently) from invalid (you need to re-authorize), and points at the protected-resource metadata document so the client knows where to go. In practice this means an expiring session refreshes in the background instead of leaving a connector that appears connected but answers nothing.

Requests are also bounded. A connector that disconnects mid-call, or a call that exceeds the server's deadline, is cleanly aborted rather than left hanging — so a stuck request returns an error your assistant can act on instead of stalling the conversation.

Listed in the Claude connector directory

JupiterOne is published in the Claude connector directory at claude.ai/directory/jupiterone. For Claude users this is the shortest path in: click Connect, choose your region, sign in — no JSON to edit and no URL to construct. The directory connector runs on the hosted remote server, so it stays on the current release automatically.

Getting listed was a real part of 1.0. Directory review checks how a server describes itself over the protocol, not just that its tools work, so the release added:

• Server identity. The server advertises the title JupiterOne, its website, and the JupiterOne mark as an icon. The icon travels over the protocol as a data URI rather than a hosted asset, so it resolves identically for the remote and local servers with nothing to fetch.
• Readable tool titles. Every tool carries a human-readable title alongside its machine name, so clients can show Execute J1QL Query rather than execute-j1ql-query.
• Fully typed parameters. Every tool parameter declares a schema type — a directory requirement, and a correctness win for any assistant reasoning about what to pass.
• Behaviour annotations on every tool. readOnlyHint and destructiveHint are required for listing, which is what lets a client tell a read from a write before running it.

Multi-account access

If your sign-in can reach more than one JupiterOne account, list-accounts returns all of them — resolved from your verified token, not guessed — along with the connector URL for each. When a tool call is rejected because it targeted an account you are not a member of, the error names the accounts you can reach and gives you their URLs, so you can repoint the connector instead of retrying a sign-in that will never help.

Structured output and tool annotations

Every tool declares an output schema and returns structured content alongside its human-readable text. Assistants read the structured form directly rather than re-parsing prose, which makes chained work — query, then build a widget from the result — far more reliable.

Tools are also annotated with their behaviour. Read-only tools are marked read-only; tools that create, change, or delete are marked accordingly. MCP clients use these hints to decide when to pause and ask you for approval, so a dashboard is never modified without your say-so.

Honest failures

Two changes make failures useful rather than alarming:

• Access denied means access denied. Upstream 401 and 403 responses are reframed as an access-denied result explaining which permission is missing and what to do about it. Previously these surfaced as raw errors that assistants tended to answer by looping on re-authentication. (1.1.0 extended this to the authorization failures JupiterOne's API delivers inside a 200 response, which had been slipping through as apparent success.)
• Errors are sanitized. Error text never carries credentials, tokens, or internal request detail.

Recovery guidance stays inside the assistant's reach: narrow the query, aggregate, paginate, or re-check permissions. You are never told to go do it in the UI instead.

Privacy and telemetry

The remote server records sanitized operational telemetry — which tool ran, whether it succeeded, how long it took — with query content redacted. Query results, query parameters, and action payloads are never stored. The local server sends nothing to JupiterOne; its telemetry stays on your own machine.

For the full data-handling position, see the FAQ on the MCP Server overview page.

The 1.x point releases

Six point releases followed 1.0 through July 2026, adding four tools and closing the gaps that showed up in real use.

Version	Released	Highlights
1.0.1	July 2026	Dashboard tool hardening, tolerant query output schema with an explicit hasMore signal, corrected layout and pagination guidance
1.1.0	July 2026	Dashboard CRUD completed — update-dashboard-widget, delete-dashboard, delete-dashboard-widget — plus automatic dashboard layout and access-denied framing for authorization failures returned as HTTP 200
1.1.1	July 2026	Rewritten J1QL error messages for the mistakes assistants actually make
1.2.0	July 2026	Instant J1QL syntax validation using the platform's own parser
1.3.0	July 2026	Resumable long-running queries via get-query-results
1.4.0	July 2026	test-connection reports who you are and what you can do

Dashboard CRUD (1.1.0)

1.0 could create dashboards and widgets but not fully manage them. 1.1.0 closed the loop with update-dashboard-widget, delete-dashboard, and delete-dashboard-widget, taking the tool count to 27. update-dashboard also gained automatic layout: ask for a dashboard and the widgets are placed sensibly instead of stacking on top of each other.

Delete operations are annotated as destructive, so your client prompts before running them.

Instant J1QL validation (1.2.0)

The MCP Server now bundles the same query-language parser the JupiterOne query service runs, and validates every query locally before sending it. A syntax error comes back immediately with the specific problem and a suggested fix — no round-trip, no waiting on a query that was never going to run. Because it is the platform's own grammar, what the server accepts locally matches what the backend accepts.

LIMIT is pre-checked against its real 1–250 range, with the corrected approach (page with the cursor, or use count() for totals) supplied in the error.

Escape hatch

The bundled grammar is frozen when the package is published, so a much older local install could in principle reject syntax a newer query service accepts. Setting JUPITERONE_SKIP_QUERY_VALIDATION=1 in your MCP client config bypasses the local check entirely; the backend still validates every query. Upgrading the package is the better fix.

Query timeout guidance was rewritten in the same release to preserve what you were actually asking for — suggesting indexed filters and tighter traversals rather than telling the assistant to ask a smaller question.

Resumable long-running queries (1.3.0)

Heavy graph traversals can outlive a single tool call. Instead of failing, execute-j1ql-query now returns status: "IN_PROGRESS" with a resultsUrl handle, and the new get-query-results tool picks the query back up.

• The query keeps running server-side, and its results stay retrievable for about an hour.
• Each get-query-results call waits up to 40 seconds, and reports elapsed time so the assistant can judge whether to keep waiting.
• Most queries that succeed finish within about four minutes; past roughly 13 minutes a query will not complete, and the guidance says so plainly rather than leaving the assistant to poll forever.

Your assistant does not have to sit and wait — it can do other work between checks. This brought the tool count to 28.

Connection and permission visibility (1.4.0)

test-connection now answers three questions instead of one:

• Am I connected? As before.
• Who am I? The email your token resolves to — decisive when it is not clear which sign-in a connector is using.
• What am I allowed to do? A per-area create/read/update/delete summary covering dashboards, rules, and integrations, plus a hasBroadAccess flag for full account admins.

Assistants use this to check before acting: if you lack dashboard-create permission, you get told that, instead of watching a create attempt fail. When a connection is pinned to one account and that account is inaccessible, the guidance names the binding and lists the accounts you can reach — so you fix the connector rather than re-authenticating in a loop.

Getting started

If you already use the MCP Server:

• Remote server — nothing to do. The hosted server always runs the current release.
• Local server — npx @jupiterone/jupiterone-mcp picks up the latest version on each run. If you installed globally, run npm install -g @jupiterone/jupiterone-mcp to update.

If you are new to the MCP Server:

1. Using Claude? Install straight from claude.ai/directory/jupiterone. For any other assistant, follow the setup on the MCP Server overview page — the remote server is recommended and requires no local install.
2. Ask your assistant "test my JupiterOne connection" to confirm it is connected and see what your sign-in can do.
3. Try "List my JupiterOne integrations" or one of the prompt templates to see the tools in action.

For the full setup guide, tool reference, and FAQ, see JupiterOne AI Integration (MCP Server). For what came next, see What's new in MCP 2.0.