MCP Endpoint

DAIV exposes a Model Context Protocol (MCP) server endpoint, allowing AI coding assistants to delegate tasks to the DAIV agent — directly from your editor or terminal.

The DAIV agent can read and modify code, run commands in a sandbox, create commits and branches, open merge requests or pull requests, and debug CI/CD pipelines. Through the MCP endpoint, your local assistant can offload these tasks to DAIV and get the results back.

Authentication

The endpoint accepts two authentication methods:

OAuth 2.0 (default for interactive clients) — on first use a browser window opens for you to log in with your existing DAIV account. Your client manages tokens and refreshes them automatically. This is what the editor integrations below use out of the box.
API key — pass an Authorization: Bearer <api-key> header. This is aimed at headless or non-interactive clients (CI jobs, scripts) that can't complete the browser flow. Create a key self-service in the dashboard at /accounts/api-keys/ (see Creating an API key); the same key also works against the HTTP Jobs API.

Note

API keys are scoped to your user, not to a specific surface — a key that authenticates against the MCP endpoint has the same access as it does on the REST Jobs/Chat API. Revoke a key from the dashboard to cut off both at once.

Authenticating with an API key

Any MCP client that lets you set request headers can pass the key. For example, with Claude Code:

Bash
claude mcp add daiv --transport http https://daiv.example.com/mcp/ \
  --header "Authorization: Bearer <prefix.secret>"

Or in Cursor's mcp.json:

JSON
{
  "mcpServers": {
    "daiv": {
      "type": "streamable-http",
      "url": "https://daiv.example.com/mcp/",
      "headers": { "Authorization": "Bearer <prefix.secret>" }
    }
  }
}

Getting started

Claude Code

Bash
claude mcp add daiv --transport http https://daiv.example.com/mcp/

Cursor

Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

JSON
{
  "mcpServers": {
    "daiv": {
      "type": "streamable-http",
      "url": "https://daiv.example.com/mcp/"
    }
  }
}

Codex CLI

Add to .codex/config.toml (project) or ~/.codex/config.toml (global):

TOML
[mcp_servers.daiv]
url = "https://daiv.example.com/mcp/"

Tip

Any MCP client that supports Streamable HTTP transport can connect to DAIV using the same /mcp/ URL.

Available tools

Tool	Description
`submit_job`	Submit a prompt to the DAIV agent as a batch of jobs — one independent job per repository. Returns a `batch_id` and a `jobs` list, or set `wait=True` to block until every job in the batch completes (up to 10 minutes total); each finished job's status then includes its `artifacts`.
`get_job_status`	Get the status and result of a previously submitted job, plus the `artifacts` it published (reports and other files, with viewer and download URLs — see Artifacts). A `WAITING_INPUT` status means the agent stopped to ask a question: `question` holds it and `result` its rendered text — answer with `submit_job` using the same `thread_id`. Also supports `wait=True` to block until completion (a `WAITING_INPUT` result also ends the wait, since it's terminal).
`list_repositories`	Discover repositories accessible to DAIV, optionally filtered by `search` (partial name match) or `topics`. Served from DAIV's local repository catalog — a periodically synced mirror — not a live platform call. Supports `limit` (default 20, max 50) and `cursor`, ordered by slug — a `search` matching more repositories than `limit` is still fully reachable by paging.
`list_environments`	List the sandbox environments visible to you (your own `USER` environments plus all `GLOBAL` ones), ordered by scope then name. Supports `limit` (default 20, max 50) and `cursor`; use a returned `name` or `id` as `submit_job`'s `environment` argument.
`get_environment`	Look up a single sandbox environment by name or UUID. Returns full details with secret env-var values masked, or nothing if it is not in your visible scopes.
`list_jobs`	List your recent agent runs (newest first), optionally filtered by `repo_id` and `status`. Supports `limit` (default 20, max 50) and `cursor`. Returns a lean summary per run plus `next_cursor` — use `get_job_status` for a single run's full result text.
`schedule_job`	Create a recurring or one-off scheduled run owned by you. Takes `name`, `prompt`, a 1–20 entry `repos` list, and a `frequency` (`hourly`/`daily`/`weekdays`/`weekly`/`custom`/`once`) with its companion field (`time` for daily/weekdays/weekly, `cron_expression` for custom, `run_at` for once). Optional `agent_model`, `agent_thinking_level`, `environment`, and `muted` mirror `submit_job`.
`list_scheduled_jobs`	List your scheduled jobs (newest first), optionally filtered by `enabled_only` or `repo_id`. Supports `limit` (default 20, max 50) and `cursor`.

The paginated listing tools (list_jobs, list_scheduled_jobs, list_environments, list_repositories) share one pagination contract: pass an optional limit and cursor, and read back { "<items>": [...], "next_cursor": <token or null> }. To page, call again with cursor set to the previous response's next_cursor until it comes back null; a cursor encodes only sort position, so reuse it with the same filters.

submit_job takes a repos list (1–20 entries) and a single prompt that runs as an independent job against each repository. Each entry is {repo_id, ref}, where ref is the starting branch the agent reads from — it is optional and defaults to the repository's default branch, and must be a branch that exists on the remote (a commit SHA fails the clone). A merge/pull request the job opens targets that branch and is assigned to the token's owner when their DAIV account is OAuth-linked to the git platform. The response includes a batch_id, a jobs list (one entry per submitted job, each with its job_id, repo_id, ref, thread_id, and status), and a failed list for repositories that could not be enqueued.

submit_job also accepts these optional parameters:

agent_model — override the default model as a provider_slug:model_name string (e.g. openrouter:anthropic/claude-sonnet-4.6); the provider slug must match an enabled provider. Omit to use the system default.
agent_thinking_level — control reasoning effort: one of minimal, low, medium, high, or xhigh. Omit to inherit the system default.
muted — mute this run's notifications; default false. notify_on is no longer accepted (removed); sending it returns an unknown-argument error.
environment — the sandbox environment to run every job in, given as its name or UUID (discover names via list_environments). Omit to auto-resolve a runtime per repository.
thread_id — continue an existing thread by passing the UUID from a prior submit_job or get_job_status response. Continuation requires exactly one repository, whose latest activity must belong to you. This is also how you answer a WAITING_INPUT job: submit a new job with the same thread_id and the answer as prompt.
references — a list of up to 20 external work-item references to link into the MR/PR DAIV creates. Each entry is an object with these fields:
- key (required) — the issue or ticket identifier, 1–64 characters, matching [A-Za-z0-9][A-Za-z0-9._/#-]* (e.g. "PROJ-123", "42", "DAIV-1V"). When relation is "closes" the key must additionally be a bare identifier — no / and no # — because DAIV emits it next to a closing keyword, where namespace/project#7 would be a valid cross-project reference and would close an issue in someone else's project.
- url (optional) — an http(s) URL for the work item, up to 500 characters. Used as the link target when DAIV renders the reference. Anything outside the URL character set (RFC 3986), parentheses included, must be percent-encoded: DAIV renders the value into a markdown link destination in the MR/PR description, so a space, a newline or a ) would end the link and let the rest of the value become body text the git platform parses.
- provider (optional) — identifies the ticketing system. Accepted values: gitlab-issue, github-issue, sentry, jira, or any lowercase alphanumeric-and-hyphen string up to 32 characters for other systems. Defaults to generic. The named providers get platform-specific output: gitlab-issue/github-issue render the platform's own closing/relating line in the MR description, sentry with relation: "closes" renders a Fixes <short-id> description line and commit trailer, and jira gets a Refs: <key> commit trailer for dev-panel linking — a link, never a workflow transition (its description entry is the plain reference link). Any other provider value is accepted and renders as a plain reference link — no DAIV change is needed to add a new ticketing system.
- relation (optional) — either "relates" (default) or "closes". "closes" opts into auto-close on merge where the provider supports it: GitLab and GitHub close an issue when a merged MR description contains a closing keyword referencing it; Sentry resolves an issue whose short ID appears in a Fixes … commit line reaching the tracked branch (which also requires the Sentry–repository integration to be configured on Sentry's side — DAIV only emits the syntax). Auto-closing is always an explicit opt-in; the default "relates" only links.

On thread continuation (when thread_id is set), newly supplied references are merged into the session's existing set, deduped by (provider, key) — the first-seen entry wins. A session accumulates at most 50 references in total across all turns.

Note (v1 limitation): DAIV writes the MR description only when the MR is first created. References declared on a later turn reach that turn's commit trailers but do not rewrite an existing MR's description body.

For the full request/response schema, the batch repos contract, and the job lifecycle, see the Jobs API.

schedule_job creates a scheduled run. Pick a frequency and supply its companion field: time ("HH:MM", 24-hour) for daily, weekdays, and weekly (which fires on Mondays); a five-field cron_expression for custom; or an ISO-8601 run_at for a one-off once schedule. A run_at without a timezone offset is interpreted in the server timezone and must be in the future (a ~60-second grace into the past is tolerated). New schedules are always enabled. The response includes the schedule id and the computed next_run_at. Manage existing schedules (edit, disable, delete) from the DAIV dashboard.

Usage examples

Once connected, you can interact with DAIV naturally from your AI coding assistant:

"Ask DAIV to refactor the authentication module in mygroup/myproject to use JWT tokens"
"Submit a job to mygroup/myproject on the develop branch: fix the broken CI pipeline"
"Check the status of my last DAIV job"

Tip

Be specific in your prompts — include file paths, function names, error messages, or branch names. The more context you give, the better the result.