agentic-sdlc-mcp

Governance and evidence controls for AI coding agents working in real GitHub repositories.

Let Claude Code, Cursor, and other Model Context Protocol (MCP) clients work with repository context, review gates, security evidence, and human approval points.

中文 · npm · MCP Registry · Roadmap

agentic-sdlc-mcp is a software development lifecycle (SDLC) governance layer for teams that already let AI coding agents change production repositories. It turns GitHub context, policy, checks, reviews, security alerts, and release signals into 13 workflow-level MCP tools. Twelve tools are read-only. The only GitHub write tool previews changes by default.

What changes with this MCP

AI coding agents can create code and pull requests without understanding every repository rule. This server gives the agent bounded context and gives reviewers explicit evidence gaps instead of another free-form summary.

This server does not write code, merge pull requests, force-push, create releases, deploy software, or replace human security review.

How it fits into a production agent workflow

The MCP sits between an AI coding agent and GitHub evidence. Repository changes still happen through the agent's normal development environment, and high-impact decisions remain with your team.

flowchart LR
    Policy["Engineering policy<br>and repository rules"] --> MCP["agentic-sdlc-mcp"]
    Agent["AI coding agent<br>Claude Code · Cursor · MCP client"] --> MCP
    MCP --> GitHub["GitHub API evidence"]
    GitHub --> MCP
    MCP --> Reports["Briefs · plans · gates<br>reviews · release reports"]
    Reports --> Agent
    Reports --> Human["Human review and approval"]
    Agent -. "Code · commits · pull requests" .-> GitHub
    Human -. "Merge · release · deploy" .-> GitHub

Where it helps

Use the tools as decision support at the points where an autonomous agent would otherwise guess or rely on stale prose.

Install from npm

You need Node.js 22 or newer. Node 22 and 24 are tested in GitHub Actions. Run the published package directly from npm:

npx -y agentic-sdlc-mcp

For a global CLI installation:

npm install -g agentic-sdlc-mcp
agentic-sdlc-mcp

The default transport is stdio. Most MCP clients should start the package for you instead of running it in a separate terminal.

Let a coding agent set it up

Paste this prompt into Codex, Claude Code, or another coding agent:

Use npm install -g agentic-sdlc-mcp to install and configure this MCP globally. Repository: https://github.com/SakuraCianna/agentic-sdlc-mcp
Configure GITHUB_TOKEN and optional repository defaults through the MCP client's secret or environment configuration. On a trusted single-user machine, you may instead run agentic-sdlc-mcp configure or write them to ~/.agentic-sdlc-mcp.json. Never expose the token in chat, logs, or repository files; ask me for missing non-secret details.
Then verify the connection with the read-only repo_context tool and summarize its capabilities, required GitHub permissions, and safety boundaries.

Review every command and configuration change before approving it. Node.js 22 or newer is required.

Connect an MCP client

Add the server to Claude Desktop, Cursor, Windsurf, or another MCP client. Inject the GitHub token through the client's secret or environment configuration.

{
  "mcpServers": {
    "agentic-sdlc": {
      "command": "npx",
      "args": ["-y", "agentic-sdlc-mcp"],
      "env": {
        "GITHUB_TOKEN": "your_github_token_here",
        "GITHUB_OWNER": "your_organization",
        "GITHUB_REPO": "your_repository"
      }
    }
  }
}

Some Windows MCP clients require npx through cmd:

{
  "command": "cmd",
  "args": ["/c", "npx", "-y", "agentic-sdlc-mcp"]
}

GITHUB_OWNER and GITHUB_REPO are optional defaults. Tool calls can provide repository coordinates explicitly. Use the GitHub permission matrix to grant only the capabilities you enable.

npx -y agentic-sdlc-mcp configure

Verify the connection

Start with a read-only call so you can inspect the repository boundary before granting write access:

Use agentic-sdlc-mcp to run repo_context for the configured repository. Include package scripts, workflows, governance, and repository policy. Do not create issues or modify GitHub.

Then validate the write boundary without creating anything:

Generate a feature plan and pass its issue drafts to create_issue_set with dryRun: true. Show the target repository, titles, labels, body summaries, and warnings. Do not write to GitHub.

See the client-neutral smoke test for a five-minute verification path.

Tools

The server registers 13 workflow-level tools. MCP clients receive the full input and output schemas at runtime; this catalog explains when to use each tool and how to interpret its result.

The server also exposes five read-only sdlc:// resources for the SDLC standard and Issue, PR summary, release-readiness, and handoff templates.

Common workflows

These sequences reduce tool-selection ambiguity. Each sequence ends with a human decision.

Start work
repo_context → plan_from_context → create_issue_set (dryRun: true)
→ human confirms the work items → create_issue_set (dryRun: false)
→ prepare_work_item

Review a pull request
create_pr_summary → quality_gate_status → review_pr_against_standard
→ human reviews findings and decides whether to merge

Review governance
branch_protection_status → workflow_permissions_audit → security_triage
→ repository owners decide which settings or workflows to change

Prepare a release
security_triage → release_readiness_check → sdlc_evidence_packet
→ human approves the tag, release, and deployment

Transfer work
relevant evidence tools → sdlc_evidence_packet → agent_handoff_packet
→ the next agent validates stale or caller-asserted state before continuing

GitHub permissions

Do not grant every permission by default. Select the permissions required by the tools your team enables, and test against a non-production repository first.

GitHub permissions and endpoint requirements can change. Confirm failures against the GitHub REST API permission documentation. Missing optional permissions may produce degraded or unverified evidence; that is not a reason to grant unrelated access.

Safety and trust boundaries

The server constrains its own tools. It cannot control every action available to the surrounding AI agent or MCP client.

• One preview-first write tool: create_issue_set is the only GitHub write tool and defaults to dryRun: true
• No privileged repository mutations: no merge, approval, force-push, branch deletion, branch-rule mutation, release creation, or deployment tools
• Human gates remain external: the server reports CODEOWNERS, review, policy, CI, security, and release evidence; GitHub and your team enforce the final decision
• Evidence stays qualified: missing, stale, truncated, malformed, or permission-limited sources remain visible as gaps
• Repository policy is base-bound: PR policy is read from the base SHA when available so a pull request cannot silently weaken its own gate
• External text is untrusted: repository and caller text is bounded and escaped; any detected instruction override, secret/data exfiltration, encoded-command, or tool-coercion pattern is omitted from agent-facing Markdown while raw structured evidence remains available for inspection
• Secret detection has limits: trusted scanner provenance and patch heuristics reduce risk, but cross-file or runtime data flow still needs CodeQL or other static application security testing (SAST), secret scanners, tests, and human review
• Credentials remain your responsibility: prefer client secret injection or environment variables; never commit tokens or paste them into Issue, PR, or log content
• Local-only transport boundary: stdio and loopback HTTP are for a trusted local workstation. Remote OAuth and multi-tenant hosting are not on the current product roadmap

See Repository policy for .agentic-sdlc.yml schema, provenance, limits, and base-SHA self-modification behavior. See Testing strategy for the adversarial matrix and coverage rules.

Repository policy and resources

Add .agentic-sdlc.yml when repository-specific checks should affect plans, protected paths, PR gates, reviewers, blocking labels, changelog requirements, and rollback requirements. Policy output includes its source ref, blob SHA, digest, stable rule IDs, and warnings.

Static resources are available under the sdlc:// scheme:

Local HTTP profile

Stdio is the default and recommended local transport. Both local entries use the official SDK v2 era router: 2025 clients continue through initialize, while clients that explicitly negotiate 2026-07-28 use server/discover. Both eras expose the same 13 tools and 5 resources.

A local client that requires Streamable HTTP can opt in after building from source:

$env:TRANSPORT = "http"
$env:PORT = "3000"
node dist/index.js

The endpoint is http://127.0.0.1:3000/mcp. It binds only to loopback, validates Host and supplied Origin before parsing a bounded request body, creates an isolated stateless server and transport for each POST, rejects unsupported GET/DELETE session operations, bounds error details, and aborts in-flight exchanges during shutdown.

The 2025 stateless HTTP profile has no session or client identity with which to correlate a separate notifications/cancelled POST to an earlier request. The client still observes its local cancellation, but the original server operation may run to natural completion. Both stdio eras and 2026 HTTP propagate cancellation to the server request. Prefer stdio when server-side cancellation of legacy calls is required.

Do not expose or reverse-proxy this endpoint to another machine. Remote OAuth and multi-tenant hosting are not planned. If that scope is reconsidered, the project must first satisfy the separate remote deployment re-entry criteria; the current local server is not a safe remote deployment base.

Development and project links

Clone the repository only when you want to contribute or inspect the implementation:

git clone https://github.com/SakuraCianna/agentic-sdlc-mcp.git
Set-Location agentic-sdlc-mcp
npm install
npm run build
npm run test

The integration gate calls all 13 public tools through a real SDK Client.callTool in both eras: legacy through the project stdio wrapper and modern through the production direct-fetch HTTP handler pinned to 2026-07-28. It validates registered output schemas, key Markdown/structured results, trust boundaries, error/degradation semantics, modern wire headers, and the default create_issue_set dry-run behavior. The fixture fails immediately on any live issue write and blocks external fetch/socket access.

The separate Inspector stdio gate pins Inspector 2.0.0 behind its own lockfile and invokes the real dist/index.js from outside the process. It verifies legacy initialize, all 13 tool declarations, all five resource reads, one explicit zero-write create_issue_set preview, and stable JSON/exit contracts for invalid input and an unknown resource URI. Every tools/call targets create_issue_set with dryRun:true. Inspector passes a fixed environment allowlist to the target with its official -e option, and the run fails unless the real server writes a temporary harness-loaded marker. The harness preserves the user's HOME value but blocks the product's global config-file probe, replaces inherited GitHub credentials with a non-secret test placeholder, isolates Inspector storage/OAuth state, and disables every fetch/TCP connection for this stdio-only check. This is black-box compatibility evidence, not MCP certification and not evidence for modern server/discover.

The HTTP gate starts the production adapter on 127.0.0.1:0, targets its canonical /mcp URL with Inspector's non-interactive --stored-auth-only mode, compares complete tool/resource JSON with an independent Inspector stdio discovery, and closes every child after success or failure. A separate empty-store 401 loopback fixture forces auto-open eligibility but still requires immediate 3/auth_required; a browser-spawn marker makes any interactive OAuth attempt fail the gate. The harness allows only exact IPv4 loopback fetch/socket targets; DNS aliases, deceptive hostnames, external network access, and inherited credentials remain unavailable. On Windows, Inspector 2.0.0 can emit the correct JSON error and then hit one upstream libuv closing assertion. The runner accepts only that exact platform/status/two-line signature and reports the raw exit class; Linux and every other failure remain fail-closed.

The Conformance pilot pins official 0.1.16 and its legacy 2025-11-25 active suite. It currently records 30 scenarios: five direct passes and 25 governed expected failures, primarily because the upstream everything-server prompts, fixture URIs, fixture tools, subscriptions, media/callback capabilities, and stateful SSE assumptions are not this product's public contract. Every expected failure has a reason, owner, and removal condition; a new failure or stale entry fails the run. The uploaded checks.json excludes raw response details and credentials. This is a non-blocking compatibility pilot, not certification and not a reason to add test-only production capabilities.

CI runs the full product suite and current-contract comparison on Node 22 and Node 24. Separate Node 24 jobs replay the immutable baseline and run the Inspector stdio/HTTP and Conformance contracts. Node 20 is not a supported runtime because it is end-of-life; local contributors only need one supported Node version, while the compatibility matrix is enforced by GitHub Actions.

Ordinary tests, contracts:check, and contracts:verify-baseline never rewrite the baseline. The replay command and the maintainer-only contracts:generate command verify the pinned tag/commit, install the historical lockfile with lifecycle scripts, audit, and funding output disabled, build it in the system temporary directory, and use real tools/list and resources/list calls in a bounded child process whose cwd stays outside the checkout. That child receives only an allowlist of OS path, temporary-directory, locale, and dynamic-library environment variables; credentials, business configuration, NODE_OPTIONS, and local state paths are not inherited. Windows cleanup uses bounded retries after historical handles are released. The commands require npm registry access but do not call GitHub APIs or model services. Only contracts:generate writes the tracked JSON, leaving its diff visible for review.

Contribute through issues and pull requests

Issues and pull requests are welcome. Check the open issues and roadmap before starting. Open an Issue first when a change affects public behavior, security boundaries, tool schemas, or architecture.

1. Fork the repository and create a focused branch from the latest main.
2. Run npm ci, then make only the changes required for the contribution.
3. Add or update tests and documentation when behavior changes.
4. Run the checks relevant to your change. The Node 22/24 matrix runs npm run check:line-endings, npm run typecheck, npm run build, the built form of npm run contracts:check, npm run test, npm run smoke, and npm run test:coverage; separate Node 24 jobs run the immutable baseline replay and the pinned Inspector stdio/HTTP and Conformance contracts.
5. Open a pull request against main. Describe the problem, solution, risks, validation results, and linked Issues.

Keep tokens, credentials, private repository content, and generated local configuration out of commits, Issues, pull requests, and logs. A passing CI run supports review but does not replace maintainer approval.

• Roadmap
• Repository policy guide
• Testing strategy
• Remote deployment re-entry criteria
• v1.9.0 release notes
• AI coding agent smoke test
• Changelog
• Releases
• Open issues

The npm and MCP Registry workflows use GitHub OpenID Connect (OIDC) trusted publishing. Publishing a GitHub Release triggers both workflows. The Registry workflow waits for that exact npm package version before it publishes matching immutable stdio metadata.

License

MIT