MCP verb reference

The developerz.ai MCP server is live at mcp.developerz.ai. Connect it from Claude Code, Claude Desktop, or any MCP-capable client using a personal access token from the dashboard.

Trust model

Every MCP call is bound by the same rules as the rest of the platform:

• The bot always discloses. Every action it takes is labelled as automated, it never impersonates a human.
• Thin orchestrator, BYOK. Coding runs in your own agent; inference uses your own provider key. We never proxy or resell tokens.
• Audit-first. Every tool call is written to the append-only audit log. If it isn't logged, it didn't happen.

Connecting

// .claude/settings.json (Claude Code)
{
  "mcpServers": {
    "developerz": {
      "command": "mcp-remote",
      "args": ["https://mcp.developerz.ai"],
      "env": { "MCP_BEARER_TOKEN": "dev_pat_…" }
    }
  }
}

Or direct HTTP (JSON-RPC 2.0 over POST /v1/mcp):

curl https://api.developerz.ai/v1/mcp \
  -H "Authorization: Bearer dev_pat_…" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"tools/call","id":1,"params":{"name":"whoami","arguments":{}}}'

Scopes are on the wire, not just on this page

Every row tools/list returns carries its own gate, so a client never has to read this page or pattern match a description:

{
  "name": "box",
  "annotations": { "readOnlyHint": false, "destructiveHint": true, "idempotentHint": false },
  "_meta": {
    "developerz.ai/scopes": {
      "kind": "action",
      "actions": { "list": "read:runners", "revoke": "write:runners" }
    }
  }
}

A flat tool publishes {"kind": "tool", "scope": "write:tasks"} instead, with "scope": null when it gates on nothing. Pair it with whoami, which returns the scopes your token actually holds, and you can tell before you call which verbs are open to you and which need a wider token. annotations is the MCP standard triple: readOnlyHint is claimed only when every one of a tool's actions is a read.

The tables below are the same information, rendered for humans. They are generated from the catalog the server enforces, so the two cannot drift.

User-tier tools

Flat, hot-path tools available to every authenticated account. No action field.

Operator-tier tools

Resource tools, one tool name, dispatched by an action field. That collapse is what keeps the catalog readable: one tools/list entry per resource instead of one per action. Each entry is complete, its JSON Schema naming every action and the arguments that action takes, so any MCP client can call any of them straight from the catalog. There is no second call to make and no extension to install.

Consumer-or-absent. A tool only appears in tools/list when its backing service is configured. All tools below are available on platform-managed accounts.

Box

Project

Task

Blocker

Plan

Audit

Session

What the maintainer agent actually did on one repo, and what a different policy would have done. The live SSE tail stays REST-only because holding a connection open is not a JSON-RPC shape: events pages the same audit rows behind an opaque cursor, so an agent polls it until finished is true.

Template

Config

Scoped prompt-var KV, #{{key}} interpolation into agent prompts.

Prompt

The authored prose layers of the system-prompt cascade (platform, then org, repo and your own). A set replaces that layer; a get on an unauthored one answers prompt: null. The personal layer belongs to the caller: no action names a user, and a machine token, which has no human behind it, is refused.

User

Account

Grant

Audited entitlement overrides, free capacity on top of what an account pays for, granted to an account (all four kinds) or to a user (unlimited_fleet / concurrency only, the two the person-level fleet gates read).

Issuing and revoking are operator-only (admin:grants, a scope no role ceiling and no self-minted token can hold); the listing rides the platform-staff read scope, so a radar session can see who holds free capacity without being able to hand any out. Every grant carries a stated reason and an issuing human, and is revoked rather than edited, the row parks so the decision stays legible.

Review

AI code-review runs for a pull request (the PR rows themselves live on pr).

CI

Artifact

Issue

Pull request

Dashboard

Donation

Integration

Digest

Billing

BYOK key purpose

LLM route

Which pool key, provider or model serves which work. A pin names a purpose (a job class, review, gardener, or the default catch-all) plus at least one of key_label / provider / model; a re-pin replaces the row, so axes you leave out are cleared. A repo pin beats the org one at claim time, and within a scope an exact purpose beats the catch-all. Keys themselves live on the billing verb: a route names a key by label, never key material.

Email route

Notification

Your own inbox and delivery preferences, the same ones the dashboard bell and the notification settings page drive. Inbox rows are events rather than deliveries: one escalation fanned out to email and push reads as a single row, and marking it read clears it everywhere. Every action needs a user-bound credential, because an inbox belongs to a person; a machine token is refused. A mandatory cell (an escalation always emails, which is the disclosure contract) refuses prefs_set. Web Push device subscriptions stay browser-only and have no verb.

Token

Webhook

Outbound delivery targets. Urls come back masked (origin kept, path redacted, since a webhook path can itself carry a shared secret) and the HMAC signing secret is returned exactly once, by create. test does not dial out from the control plane: it queues a signed test.ping that the worker delivers on the real path, so the result names the queued delivery and the outcome shows up in deliveries.

Member

The active org's roster. list returns all of it, with no page knob, because the REST collection does too and a truncation nobody is told about is worse than a long answer; list_invitations answers the whole invitation history for the same reason. Every mutation below needs a user-bound credential (invite, set_role, remove and revoke_invitation alike): the gate asks whether your own role outranks the target, and a machine token holds no role at all. Neither read does. Nobody may promote past their own rank, and the last owner can be neither demoted nor removed.

SSO

Your org's own OIDC single sign-on. Owner-only on every action, so a PAT never reaches it. set carries no client_secret field: a credential the platform mints may ride back in a result, but one you supply never crosses this boundary, which is the same rule that leaves integration without a connect. So set updates the non-secret half and reuses the stored sealed secret, and refuses outright until a connection exists. Create that one in the dashboard, or with PUT /v1/org-sso.

Ops

The devops / debugger run: reproduce a failure against the repository's own secrets, read the running system, act on infrastructure, and report. It is the one role that reaches a live system, so the surface here is deliberately one verb wide.

outcome_kind: report is the default and opens no pull request: a devops run's deliverable is findings. ops_action may act on infrastructure, and on a production-tagged box it refuses without a fresh signed approval and escalates to a human; there is no field on this verb that can supply one, by design. A run that needs access it does not have reports a blocker naming the credential rather than working around it, and files a raw task for triage when the fix is bigger than the session.

Scopes

PATs carry only the scopes you select at creation time. Dashboard session cookies grant all scopes. Scope names follow read|write:<resource>.

Verb tables on this page are generated from the MCP catalog (FLAT_TOOL_SCOPES + ARMY_ACTION_SCOPES in @developerz/mcp) by bun run mcp:doc; headings and prose are hand-curated. The same matrix is embedded in docs/idea/api.md + docs/idea/mcp.md.