Sobmit as an MCP server

Sobmit is not just an MCP client — it can be consumed as an MCP server. An external agent (Claude Desktop, Cursor, or any MCP 2026-07-28 client) can discover Sobmit as a protected resource, authenticate with OAuth 2.1, and then build, read and validate flows on your behalf.

Endpoint

The MCP server is served over a stateless JSON-RPC POST endpoint:

POST /api/mcp

It implements the MCP 2026-07-28 protocol (createMcpHandler from the official SDK v2), constructing a fresh server per request so tool definitions are always backed by the current authenticated user.

Discovery (RFC 9728)

An MCP client discovers the server through its protected-resource metadata, served at the well-known root:

GET /.well-known/oauth-protected-resource

This document is what the 401 WWW-Authenticate challenge points to via its resource_metadata field, so a standards-compliant client finds the authorization server and token endpoint without manual configuration.

Authentication — OAuth 2.1 authorization-code flow + PKCE

Access is granted with the standard OAuth 2.1 authorization-code flow with PKCE (RFC 7636). The flow:

Authorization request — the client redirects the user to /oauth2/authorize with client_id, scope, redirect_uri and the PKCE code_challenge.
Consent — if the user has not already consented, Sobmit shows a consent screen at /consent naming the requesting client and the scopes it asks for. The user approves or denies.
Authorization code — on approval, the browser is redirected back to the client’s redirect_uri with a one-time code.
Token exchange — the client exchanges the code (plus its PKCE code_verifier) for an access token at the token endpoint.
Access — the client calls POST /api/mcp with the bearer access token. requireMcpAuth verifies the token (issuer, audience, expiry) against the authorization server’s JWKS and maps it to the authenticated user.

The signing key is published at:

GET /jwks

Access tokens are audience-bound to the /api/mcp resource and scoped to the specific user who consented — a client can only act on that user’s flows.

Available tools

The server exposes these tools, all scoped to the authenticated user:

Tool	Purpose
`list_node_kinds`	Every addable node kind and its default data shape
`list_flows`	The user’s flows (id, name, updated)
`get_flow`	A flow’s full project graph by id
`create_flow`	Create a new flow from a name
`add_node`	Add a node to a flow
`update_node`	Update a node’s data in a flow
`remove_node`	Remove a node from a flow
`add_edge`	Connect two nodes
`remove_edge`	Disconnect two nodes
`validate_flow`	Validate a flow and return any problems

Each tool re-uses the same permission checks, header-sanitization and version snapshotting as the web app, so an agent gets exactly the behaviour (and the same safety) as a signed-in user in the browser.

Example — connect Claude Desktop

Add Sobmit as a remote MCP server in Claude Desktop, authenticating with OAuth. After consent, Claude can list your flows and build new ones:

"sobm.it" is an MCP server over OAuth — ask it to list_node_kinds first,
then create_flow + add_node to sketch a new automation.

MCP servers — the reverse direction: calling external MCP tools from a Sobmit flow.
Core concepts — flows, nodes and edges.