MCP Tasks Conformance

The tasks conformance command validates the MCP Tasks wire your server exposes: which wire the connection resolves to, whether declaration hygiene holds for that wire, and whether the server honours the observable parts of the contract (result-type discipline, -32003 on undeclared requests, TTL shapes, inline results, and Mcp-Name routing for HTTP transports).

Tasks conformance provokes and then polls a real task, so it requires a persistent connection. It is not available in hosted mode.

Quick start

mcpjam tasks conformance --url https://your-server.com/mcp

For a local stdio server:

mcpjam tasks conformance --command node --args server.js --cwd /path/to/project

On the extension wire you must name the probe tool. Auto-selection reads execution.taskSupport, which the 2026-07-28 ToolSchema strips, so a tasks-extension server cannot advertise which tool creates a task. Without --tool-name the six task-dependent checks cannot run and the command reports "outcome": "incomplete" (exit code 3) rather than a green run:

mcpjam tasks conformance \
  --url https://your-server.com/mcp \
  --tool-name long_job

A --tool-name the server does not list is treated the same way: the run is incomplete, and the message names both the tool you asked for and the tools the server actually lists. Emit CI-friendly JUnit XML:

mcpjam tasks conformance \
  --url https://your-server.com/mcp \
  --reporter junit-xml > tasks-report.xml

What it checks

Check id	Category	What it asserts
`tasks-wire-resolvable`	`dispatch`	The negotiated protocol version and capabilities resolve to exactly one tasks wire.
`tasks-declaration-hygiene`	`dispatch`	Outbound requests carry `params.task` only on the legacy wire and the extension declaration only on the extension wire.
`tasks-result-type-discipline`	`creation`	A task-eligible `tools/call` returns either a normal tool result or a flat `CreateTaskResult` with `resultType: "task"` and a non-empty `taskId`. The discriminator is required whether absent or wrong — it is the only signal that separates a task from a standard result.
`tasks-undeclared-creation-refused`	`creation`	On the extension wire, a `tools/call` that did not carry the extension declaration must not come back as a `CreateTaskResult`; the server must answer normally or reject with `-32003`.
`tasks-ttl-shape`	`lifecycle`	TTL and poll interval use the era-native shapes: `ttlMs`/`pollIntervalMs` on the extension, `ttl`/`pollInterval` on the legacy wire.
`tasks-inline-result`	`lifecycle`	A completed extension task carries its result inline on `tasks/get`; a legacy task exposes it via `tasks/result`.
`tasks-mcp-name-routing`	`lifecycle`	Over HTTP, `tasks/get` is sent with `Mcp-Name` set to the task id.
`tasks-undeclared-capability-rejected`	`lifecycle`	`tasks/get`, `tasks/update`, `tasks/cancel` and a task-filtered `subscriptions/listen` sent WITHOUT the extension declaration must each be rejected with `-32003`.

Categories and check ids

Three categories are available:

dispatch
creation
lifecycle

Use --category to run a subset by category, or --check-id to run specific checks:

# Dispatch checks only
mcpjam tasks conformance \
  --url https://your-server.com/mcp \
  --category dispatch

# Specific checks
mcpjam tasks conformance \
  --url https://your-server.com/mcp \
  --check-id tasks-ttl-shape \
  --check-id tasks-inline-result

If you pass both --category and --check-id, the explicit --check-id selection wins.

Options

Flag	Description
`--category <category>`	Check category to run. Repeat for multiple. Default: all.
`--check-id <id>`	Specific check id to run. Repeat for multiple. Default: all.
`--tool-name <tool>`	Tool used to provoke a task. Required for servers whose tools carry no task metadata (the extension wire).
`--tool-args <json>`	Tool arguments as a JSON object.
`--poll-timeout <ms>`	How long to poll a created task for a terminal status. Default: `30000`.
`--reporter <reporter>`	Structured reporter output: `json-summary` or `junit-xml`.

Example output

mcpjam tasks conformance \
  --url https://your-server.com/mcp \
  --tool-name long_job \
  --format json

Typical success summary:

{
  "passed": true,
  "outcome": "passed",
  "summary": "8/8 checks passed, 0 failed, 0 could not run, 0 not applicable",
  "discovery": {
    "protocolVersion": "2026-07-28",
    "wire": "extension",
    "toolCount": 3,
    "taskCapableToolCount": 1,
    "probedTool": "long_job",
    "createdTaskId": "task-abc123"
  }
}

Outcomes: passed, failed, incomplete

A run reports one of three outcomes, and passed is true only for the first:

`outcome`	Exit code	Meaning
`passed`	`0`	Every selected check either ran and passed, or does not apply to this server.
`failed`	`1`	At least one check found a violation.
`incomplete`	`3`	Nothing failed, but at least one selected check could not be run, so the run does not establish conformance.

Every skipped check says which kind of skip it is in skipReason:

not-applicable — the check cannot apply here (an extension-only check on a legacy connection, Mcp-Name routing over stdio, any task check on a connection with no tasks wire). These never hold a run back.
could-not-run — the check applies but was never exercised (no probe tool resolved, the named tool is not listed, the tool produced no task, the task never became readable). These make the run incomplete.

An incomplete run carries a root incompleteReason naming the checks that did not run and what to change; non-quiet runs also print it to stderr. A skipped check can never add up to a passing verdict.

Shared connection flags

tasks conformance uses the same shared target flags as the rest of the CLI:

Flag	Description
`--transport <transport>`	Explicit transport type (`http` or `stdio`)
`--url <url>`	HTTP MCP server URL
`--access-token <token>`	Bearer access token
`--oauth-access-token <token>`	OAuth bearer access token
`--refresh-token <token>`	OAuth refresh token
`--client-id <id>`	OAuth client ID (with `--refresh-token`)
`--client-secret <secret>`	OAuth client secret (with `--refresh-token`)
`--header <header>`	HTTP header in `Key: Value` format (repeatable)
`--client-capabilities <json>`	Client capabilities as inline JSON, `@path`, or `-` for stdin
`--command <command>`	Command for a stdio server
`--args <arg...>`	Preferred stdio command arguments
`--command-args <arg>`	Legacy stdio command argument (repeatable)
`-e, --env <env...>`	Stdio environment `KEY=VALUE` values
`--cwd <path>`	Working directory for the stdio child process

--transport is optional; without it, --url implies HTTP and --command implies stdio.

Notes

Exit codes are CI-friendly: 0 when all selected checks pass, 1 when any check fails, 2 for invalid command usage, and 3 when the run is incomplete because a selected check could not be run.
Declaration hygiene is asserted against captured outbound JSON-RPC bytes, not re-derived from intent.
The undeclared-request checks (tasks-undeclared-creation-refused, tasks-undeclared-capability-rejected) apply to the extension wire only and are skipped on the legacy wire.
tasks-undeclared-capability-rejected needs a live task to probe with, so it is reported as could-not-run (and the run as incomplete) when no task could be provoked. Its probes run last, after every check that reads the task, because a server that wrongly accepts an undeclared tasks/update or tasks/cancel would otherwise mutate the very task the other checks inspect. If the server does not implement subscriptions/listen at all (-32601), that sub-probe is reported as a warning instead of a failure.
The tasks-mcp-name-routing check applies to HTTP transports only and is skipped for stdio servers.
Checks that require a created task cannot run when no probe tool resolves. That is a could-not-run skip, so the command exits 3 instead of reporting a pass — pass --tool-name to fix it.

Apps conformance for MCP Apps surface validation
Server inspection for breadth-first connectivity and capability triage
Command reference for the full flag list

Guides

Reference

Quick start

What it checks

Categories and check ids

Options

Example output

Outcomes: passed, failed, incomplete

Shared connection flags

Notes

​Quick start

​What it checks

​Categories and check ids

​Options

​Example output

​Outcomes: passed, failed, incomplete

​Shared connection flags

​Notes

​Related commands

Quick start

What it checks

Categories and check ids

Options

Example output

Outcomes: passed, failed, incomplete

Shared connection flags

Notes

Related commands