← Resources

Point Claude at your plan in 10 minutes: the DevStride MCP, end to end

Most project-tool MCP servers do one thing: an agent asks for a ticket, the server hands back a ticket. Useful, shallow.

The DevStride MCP is different in kind. It lets an agent read your live plan, reason over real delivery metrics, and propose real changes to the work, while a human keeps the final say. Same protocol, a very different amount of leverage.

This guide takes you from nothing to an agent working your plan. It uses the real tool names, shows the shape of what comes back, and is honest about the edges. If you would rather read the reference first, the full setup and tool catalog live in the DevStride MCP Server docs; this piece shows the tools in use.

A note on the examples. The responses below are representative. Yours will differ, because they come from your workspace. The point of the walkthrough is the sequence and the tool names, both of which are real.

What you need

  • A DevStride workspace (the Connect AI page is where you generate the connection).
  • An AI client that speaks MCP: Claude, ChatGPT, Cursor, Copilot, Codex, or Gemini CLI. Your client's own subscription is separate from DevStride.

Step 1: connect (about 2 minutes)

Add the DevStride MCP server to your client and authorize it. Connection uses OAuth, scoped to your permissions in DevStride, so the agent can only see and touch what you can. There is no long-lived API key to paste around.

Once connected, confirm the agent is talking to the right workspace. Ask it to run whoami.

> whoami
{
  "username": "you",
  "name": "Your Name",
  "teams": [ "Platform", "Growth", ... ]
}

If the name and teams are yours, you are in. If you manage more than one organization, get_workspace_context returns the active org's configuration: its work types, statuses, priorities, and the IDs the other tools take as input.

Step 2: read your plan

Start read-only. Here is where the difference from a ticket lookup shows up: the agent is not fetching one item, it is querying a live model.

Ask a plain-language question and let the agent pick the tool.

> How is throughput trending this quarter?
# calling get_throughput
Up quarter over quarter. Three teams are ahead of plan;
Checkout can pull work forward.

get_throughput returns completed work per period with a trailing average, and it nets out reopened items so the totals stay honest. Its siblings answer the other questions leaders actually ask:

  • get_velocity for what a team completes per cycle.
  • get_cycle_metrics for how long work takes from start to finish.
  • get_current_progress for done versus in progress versus not started, at any level.
  • search_items and get_item_hierarchy to pull the actual work behind any number.

Because the plan and the work share one model, the figure the agent reports is the same figure on your board. Verify it: pull the number from get_cycle_metrics, then open the board. They match, because there is one source, not a copy.

Step 3: propose a real change (with a human gate)

Reading is table stakes. The reason the DevStride MCP is worth connecting is that the agent can move real work, and the guardrail is that it does so as a proposal, not a fait accompli.

> Pull the next two Checkout items into this cycle.
# drafting proposal · nothing applied yet
Proposed: move 2 items (I6825, I6746) into the current cycle,
update affected dates. Waiting on your go-ahead.

When you approve, the change is applied through the real tools, for example move_to_cycle for the reschedule and bulk_update_items for a batch, and it lands on the shared record attributed to both the agent that proposed it and you, the person who approved it. The record shows who did what, and in what order.

Here is the part that matters, and the part most "AI in your PM tool" pitches skip. The oversight is not a sentence in the docs asking you to review before you accept. Propose-then-approve is how the loop runs: the agent prepares the decision, you make it, the system records and executes it.

The honest edges

A technical reader will test exactly one of these, so here is the truth up front:

  • The MCP writes live data. There is no separate sandbox. A create_item or update_item you approve is immediate. Read first, approve deliberately.
  • The gate is in the workflow, not a fake modal. The propose-then-approve pattern is enforced by how DevStride's plan-and-build loop runs, and code changes land in staging with a human sign-off before they reach production. It is not a claim that an app dialog blocks every write.
  • Scopes are real. The agent inherits your permissions. It cannot see or change what you cannot.
  • Numbers need history. Velocity and cycle-time reports are only as meaningful as the data behind them; a two-week-old workspace will not have a trend yet.

Where to go next

  • The MCP Server docs carry the full tool reference, parameters, and auth setup. Keep this guide for the why, keep the docs for the exact signatures.
  • Want to see the same loop run against a real roadmap, end to end? Get a guided walkthrough and we will point an agent at a plan with you on the call.