MCP server¶

Dezycro exposes a Model Context Protocol (MCP) server at https://mcp.dezycro.ai. The MCP server is what the Dezycro CLI talks to — but you can also use it directly from any MCP-compatible client: Claude Code, Cursor, Claude.ai custom connectors, ChatGPT, Continue, custom IDE plugins.

Moved from /mcp

The server used to live at https://mcp.dezycro.ai/mcp. That path still works as an alias, so existing setups keep running — but new setups should use the root URL.

Authentication¶

Log in with your Dezycro account. The MCP server supports OAuth, so any MCP client that can open a browser signs in the same way you sign in to the web app — no token to create, copy, or rotate:

Add the server to your client (examples below) and start the authentication flow — in Claude Code that's /mcp → Authenticate.
Your browser opens the Dezycro sign-in page, then a consent screen: "\<App> wants to access your Dezycro account" — Approve or Deny.
After you approve, the page says "\<App> is connected to Dezycro. You can close this tab." and the client is signed in.

The connection inherits your user, tenant, and per-workspace roles on every call — there's no separate workspace selection step. Connected apps are listed under Account settings → Devices, labelled (MCP app), and can be revoked there at any time.

Or use a Personal Access Token for headless and CI use — scripts, automation, anywhere a browser sign-in isn't practical. Create one under Account settings → API Tokens (details) and pass it on every request:

Authorization: Bearer dzy_<your-token>

A PAT resolves to the same user, tenant, and workspace permissions as an OAuth login.

Wiring up a client¶

Claude Code¶

claude mcp add --transport http dezycro https://mcp.dezycro.ai

Then, inside Claude Code, run /mcp, pick dezycro, and choose Authenticate. Your browser handles the rest.

With a PAT instead:

claude mcp add --transport http dezycro https://mcp.dezycro.ai \
  --header "Authorization: Bearer dzy_..."

Or place this in ~/.claude/settings.json:

{
  "mcpServers": {
    "dezycro": {
      "type": "http",
      "url": "https://mcp.dezycro.ai",
      "headers": {
        "Authorization": "Bearer dzy_..."
      }
    }
  }
}

Cursor, Claude.ai, ChatGPT, and other clients¶

Add a remote MCP server with the URL https://mcp.dezycro.ai. Clients that support OAuth (Cursor, Claude.ai custom connectors, ChatGPT) prompt you to sign in on first use and take you through the same browser consent flow; clients that only take a static header can pass the PAT bearer header instead. The transport is Streamable HTTP (the modern MCP transport — initialize handshake, session ID, JSON-RPC over POST).

Using the Dezycro CLI?

dezycro login then dezycro setup wires the MCP connection into Claude Code and Cursor for you. In Claude Code the Dezycro entry signs itself in from your CLI session, so there's no second browser login, and it connects with every toolset pre-enabled — see Connect to Dezycro. The steps above are for connecting an MCP client on its own.

Available tools¶

The MCP server exposes the same tools the Dezycro CLI uses, covering discovery and search, feature and document management, the workbook, verification and coverage, test generation, notebooks, workspace skills, and workspace metrics.

We deliberately don't enumerate them here: MCP tools are self-describing. Every tool ships its name, description, and full parameter schema over the protocol, and every MCP client fetches that list on connect (a standard tools/list call — Claude Code, Cursor, and friends do it automatically and show it in their tool browser). Since the consumers are agents, the in-protocol descriptions are the canonical, always-current reference — a hand-maintained copy here would only drift.

To eyeball the current set yourself, connect any MCP client, or:

npx @modelcontextprotocol/inspector \
  --transport http \
  --url https://mcp.dezycro.ai \
  --header "Authorization: Bearer dzy_..."

Toolsets¶

The catalog is large, and most sessions need a small slice of it, so tools are grouped into toolsets and a session starts with only the core set — the toolset meta-tools plus the tight coding loop (reading the workbook, updating tasks, and list_notebooks / search_notebook / read_page). Everything else is enabled on demand:

Toolset	What it adds
`workbook`	Workbook writes beyond tasks: issues, decisions, assumptions, journey confirmation, artifact links; PRD alignment findings (`list_prd_drift_findings`)
`kb`	Notebook writing and browsing: `write_page`, `update_page`, `write_runbook_page`, `read_notebook_toc`
`docs`	Feature and document lookup: search/list features, read PRDs and TRDs
`authoring`	Create and organize features and directories; author PRD/TRD documents
`verification`	Publish API specs, generate tests, inspect coverage, manage verifier binaries and journeys; list long-running activity (`list_activity_items`)
`insights`	Workspace metrics and semantic search across the project knowledge base
`admin`	List workspaces; list and create projects

Four meta-tools manage this from inside a session:

list_toolsets                       → names, descriptions, enabled state
enable_toolset("verification")      → tools become callable; the server announces the change
describe_tools("verification")      → name + description + input schema for each tool
invoke_tool(tool="publish_feature_spec", argumentsJson="{...}")   → call a tool by name

describe_tools and invoke_tool exist for clients that don't refresh their tool list after enable_toolset — an agent can discover a toolset's tools and call them without ever seeing them in its own tool browser.

To skip the dance for a client that wants everything, append ?toolsets=all to the server URL; a comma-separated list (?toolsets=docs,verification) pre-enables just those at connect time.

Quirks¶

Streamable HTTP transport — the first POST must be an initialize JSON-RPC call; the server returns a Mcp-Session-Id header. Subsequent calls must echo that header back. Standard MCP clients handle this automatically.
Per-workspace permission inheritance — your login (or PAT) inherits your workspace role on every call. A Viewer can call get_* / list_* tools but not create_* / update_* ones.
Idempotency — update_document overwrites; add_* always creates a new entity. There's no append semantics on documents.
Long-running operations — generate_tests and publish_feature_spec return immediately; generation and verifier-binary compilation continue in the background. Poll list_test_cases / pull_verifier, or use the Dezycro CLI's dezycro await-event command to block until the build event lands.