ScrumDo MCPDeveloper Preview

Let your AI assistant work from the card.

Connect the AI tool you already use to permitted ScrumDo context and actions. Keep specifications, tasks, comments, commits, pull requests, decisions, and proof attached to the work.

Checking the current PyPI release...
  • Codex
  • Claude Code
  • Cursor
  • Windsurf
  • Other MCP clients
AI assistantConnected to ScrumDo
You

What does ACME-142 require, and what is still unresolved?

Assistant · using ScrumDo

The accepted specification requires a confirmation message after submission. Two accessibility checks still need owners.

ACME-142Request confirmationIn review
Accepted specCustomer evidence2 open questions
+
2 QA tasks proposedvia MCP · Codex
Review
✓
Specification accepted by MayaHuman decision · recorded
PR #482QA evidenceTimeline
MCP without the jargon

A controlled doorway between your AI tool and ScrumDo.

MCP is a standard way for an AI assistant to ask another product for information or an action. ScrumDo MCP gives a compatible assistant a controlled way to use the ScrumDo work your token and permissions allow.

01

Work from the record

The assistant can read permitted cards, accepted specifications, tasks, comments, and related work instead of relying on a summary copied into chat.

02

Return work to the team

Permitted changes, specification proposals, tasks, comments, commits, pull requests, and proof can return to the same ScrumDo record.

03

Keep decisions human

MCP carries requests. It does not replace ScrumDo permissions or human decision gates. Important approvals remain explicit and attributable.

One record, different responsibilities

Everyone can see the part that matters to them.

The developer may operate the assistant, but the value is shared across the people who define, design, build, verify, and experience the work.

Customer

The need stays visible

Where customer evidence is permitted card context, the original experience remains available instead of dissolving into technical shorthand.

Product and design

Intent remains reviewable

The accepted specification and open questions show what the team agreed to build, what is still uncertain, and what requires another decision.

Developer

Less prompt reconstruction

The assistant can retrieve permitted work context, propose tasks, update the card, and connect implementation artifacts without repeated copying.

QA and reviewer

Proof returns with limits

Tests and other evidence can return to the card. A separate verifier can report what passed, failed, or remained inconclusive before a person accepts the result.

A request you can follow

From an AI conversation to an inspectable team action.

This is not a one-way automation pipeline. People and agents can revisit context, proposals, proof, and decisions as the work changes.

  1. 1
    Ask

    A person asks the assistant about a known ScrumDo card.

  2. 2
    Check

    ScrumDo evaluates the token, organization, project, permissions, and work policy.

  3. 3
    Use

    The assistant receives permitted context or performs a permitted action.

  4. 4
    Confirm

    A person reviews consequential decisions such as accepting a specification or proof.

  5. 5
    Record

    The source, client, action, and returned evidence stay visible on the work record.

What teams can do

Capabilities organized around the work, not a tool count.

⌕
Understand

Ask about the work without rebuilding the prompt.

Find cards, read accepted specifications, inspect tasks and comments, review blockers, search the board, and check permitted governance context.

✎
Shape

Propose before making something official.

Draft a specification proposal, request changes, revise it, create tasks, and add comments while accepted work remains distinct.

↗
Connect

Keep implementation attached.

Link commits, pull requests, and issues. Record progress and return execution results to the card timeline.

✓
Verify

Return evidence, not just confidence.

Run a separate verifier, attach test results and other proof, check specification drift, and keep human acceptance distinct from agent evaluation.

Need the exact surface for your connection? Ask the client to call get_mcp_capabilities; ScrumDo returns the active profile and permitted tool names.

The control boundary

MCP connects the tools. ScrumDo still controls the work.

A protocol connection is not permission to do everything. The token establishes identity and scope. ScrumDo applies server-side controls. Human-only decisions remain human-only.

  • The token is restricted to its ScrumDo organization.
  • It cannot access billing, account settings, or another organization.
  • Tokens can be revoked from ScrumDo at any time.
  • MCP writes identify their source and client in the work timeline.
  • Your selected AI provider's data and billing terms still apply.
Who controls common MCP actions
ActionAssistantPerson
Read permitted card contextCan requestSets token and scope
Add a permitted task or commentCan requestDefines policy
Draft a specification proposalProvides draft workInitiates review
Accept or reject a specificationCannot self-acceptPreview and confirm
Approve an agent planCannot approveRequired
Accept final proofCan return evidenceRequired
Choose the right path

MCP and Runner solve different interaction problems.

Work starts in your AI tool

Use ScrumDo MCP

You are already working interactively in Codex, Claude Code, Cursor, or another compatible client and want the assistant to use permitted ScrumDo work.

  • Best for developer-led interactive work
  • Your selected client starts the request
  • ScrumDo remains the shared work record
Work starts from the ScrumDo card

Use ScrumDo Runner

You want ScrumDo to assign work to an agent and manage the specification, plan, execution, QA, proof, and human acceptance from the card.

  • Best for managed card-level runs
  • ScrumDo starts and tracks execution
  • The governed run lifecycle is visible in-product

Use both when developers need an interactive assistant while ScrumDo remains the shared record for specifications, agent runs, verification, and team decisions.

Five-minute setup

Connect, verify read access, then make one visible test update.

  1. 1
    Install the package

    ScrumDo MCP requires Python 3.11 or newer.

  2. 2
    Create a personal MCP token

    Open organization Settings → AI Connections (MCP Tokens), create a named connection, and copy its smcp_ secret once. Do not use API Tokens for human collaboration.

  3. 3
    Configure your AI client

    Use one of the verified examples shown here. Keep the token out of source control.

  4. 4
    Test read-only first

    Ask the assistant to find a known card and summarize it without making a change.

  5. 5
    Make one attributable update

    Add a clearly labeled test comment, then confirm that ScrumDo shows the MCP client as its source.

⚡ Fastest · let your assistant do it
Set up the ScrumDo MCP server ("scrumdo") in this tool for me.

1) Install it:  pip install scrumdo-mcp
2) In ScrumDo organization Settings → AI Connections (MCP Tokens), create a personal connection and copy its smcp_ secret once.
3) Register an MCP server named "scrumdo" in THIS tool's own MCP config, with command "scrumdo-mcp" and env:
     SCRUMDO_TOKEN=<smcp-personal-token>   SCRUMDO_ORG=<your-org-slug>   SCRUMDO_PROJECT=<your-project-slug>
     SCRUMDO_BASE_URL=https://app.spryng.io   SCRUMDO_MCP_PROFILE=collaborate   SCRUMDO_CLIENT_NAME=<this-tool>
   • Codex       → run: codex mcp add scrumdo --env SCRUMDO_TOKEN=… --env SCRUMDO_ORG=… --env SCRUMDO_PROJECT=… -- scrumdo-mcp
   • Claude Code → run: claude mcp add --scope user -e SCRUMDO_TOKEN=… -e SCRUMDO_ORG=… -e SCRUMDO_PROJECT=… scrumdo -- scrumdo-mcp
   • Cursor      → edit ~/.cursor/mcp.json (mcpServers.scrumdo)
   • Any other tool → edit its own MCP config file.
4) Then tell me to restart the tool. After I restart, verify by finding one card and summarizing it read-only.

Paste into Codex, Claude Code, or Cursor — it installs the package and wires the server into that tool. Or follow the manual steps below.

1 · Install
pip install scrumdo-mcp
3 · Configure Codex
codex mcp add scrumdo \
  --env SCRUMDO_TOKEN=smcp_YOUR_PERSONAL_TOKEN \
  --env SCRUMDO_ORG=your-org-slug \
  --env SCRUMDO_PROJECT=your-project-slug \
  --env SCRUMDO_BASE_URL=https://app.spryng.io \
  --env SCRUMDO_MCP_PROFILE=collaborate \
  --env SCRUMDO_CLIENT_NAME=codex \
  -- scrumdo-mcp

Verified with the Codex CLI MCP command.

Read-only testUse ScrumDo to find ACME-142 and summarize its current state. Do not change anything.
Visible write testAdd a comment to ACME-142: "MCP connection verified."

Questions before connecting

Understand the boundary before sharing a token.

What is MCP in ordinary language?

MCP is a standard way for an AI assistant to ask another product for information or an action. ScrumDo MCP is the controlled connector between a compatible AI tool and the ScrumDo work your token is allowed to use.

Does the assistant receive every piece of ScrumDo data?

No. Access is limited by the organization, project, token, server-side permissions, and the policy around the work. The token does not provide access to billing, account settings, or another organization.

Can an assistant accept its own specification or proof?

No. Consequential decisions such as accepting a specification, approving an agent plan, or accepting proof remain human actions. Specification decisions use an explicit preview and a short-lived confirmation token.

How is ScrumDo MCP different from ScrumDo Runner?

Use Runner when ScrumDo should start and manage an agent run from the card. Use MCP when a person is already working in Codex, Claude Code, Cursor, or another compatible tool and wants that assistant to interact with ScrumDo.

Who pays for the AI model?

You use your own AI tool, provider relationship, and credentials. Your provider bills its model usage. ScrumDo does not resell model tokens through ScrumDo MCP.

Your assistant, one accountable record

Stop rebuilding work context in private chats.

Connect your AI tool to ScrumDo, begin with a read-only test, and keep the next permitted action visible to the team.