Agentic SDLC MCP vs CD MCP Server
A side-by-side look at the Agentic SDLC MCP and CD MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Agentic SDLC MCP for version control work as a local process; choose CD MCP Server for version control as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Agentic SDLC MCP when
- You need dedicated capabilities in the Version Control domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
GITHUB_TOKEN, GITHUB_OWNER, GITHUB_REPO. - You want tools like
repo_context, plan_from_context, create_issue_set.
Choose CD MCP Server when
- You need dedicated capabilities in the Version Control domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
GITHUB_TOKEN, GH_TOKEN. - You want tools like
github_get_authenticated_user, github_get_rate_limit, github_create_repository.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Version Control | Version Control |
| Quality signal | 61/100 · Good | 60/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | GITHUB_TOKENGITHUB_OWNERGITHUB_REPO | GITHUB_TOKENGH_TOKEN |
| Verified owner | Community listing | Community listing |
| GitHub stars | 1 | 2 |
| Directory activity | 1 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 13 | 70 |
| Full listing | View Agentic SDLC MCP | View CD MCP Server |
Tools & capabilities
Agentic SDLC MCP tools 13
repo_contextRead baseline context for a GitHub repository, including metadata, README summary, package.json summary, tech stack, common scripts, workflow file names, governance signals, agent instruction file summaries, open issues, and open PRs. Use this tool at the start of any SDLC workflow to understand the codebase before planning or creating work items. Args: - owner (string?): GitHub org or user. Defaults to GITHUB_OWNER env var. - repo (string?): Repository name. Defaults to GITHUB_REPO env var. - includeReadme (boolean): Include truncated README. Default: true. - includePackageJson (boolean): Include package.json summary, detected package manager, tech stack, and common scripts. Default: false. - includeWorkflows (boolean): Include .github/workflows/*.yml file names. Default: false. - includeAgentInstructions (boolean): Include summaries of AGENTS.md/CLAUDE.md if present. Default: false. - includeGovernance (boolean): Include whether a CODEOWNERS file exists. Default: false. - includePolicy (boolean): Include validated repository policy and provenance. Default: false. - includeOpenIssues (boolean): Include recent open issues. Default: false. - includeOpenPRs (boolean): Include open pull requests. Default: false. - issueLimit (number): Max open issues to fetch. Default: 20, max: 100. - prLimit (number): Max open PRs to fetch. Default: 20, max: 100. - maxReadmeChars (number): Max README characters before truncation. Default: 3000. - maxInstructionChars (number): Max characters per agent instruction file summary. Default: 1000. Returns: Markdown summary of the repository context, plus structured content. Missing files (README, package.json, agent instructions) degrade gracefully rather than failing the whole call.plan_from_contextGenerate a structured Agentic SDLC plan (Plan->Create->Test->Review->Optimize->Secure) from a goal and repo context. The plan is tailored to a `workType` (docs/feature/bugfix/refactor/security/release/infra) -- e.g. docs tasks do not default to requiring code unit tests, while bugfix tasks always include repro + regression tests. Template-based -- no LLM call needed. Reads basic repo metadata (and the repo's actual label list, to avoid inventing labels that don't exist) to enrich the plan. Args: - goal (string): The user's goal or feature description (required). - owner, repo: Repo coordinates (fall back to env vars). - workType (string?): Explicit task category. If omitted, inferred from goal + acceptanceCriteria -- check the output's `confidence`/`needsClarification` rather than assuming the guess is correct. - constraints (string[]?): Technical or business constraints. - acceptanceCriteria (string[]?): Explicit acceptance criteria. Returns: Phase-by-phase SDLC plan tailored to the (inferred or explicit) work type, plus structured output including workType/confidence/reasoning/needsClarification, and `issueDrafts` -- structured issue drafts (title/body/labels/phase/acceptanceCriteria/riskLevel) directly usable as `create_issue_set`'s `issues` input.create_issue_setSplit an SDLC plan into GitHub issues. Supports dryRun (default TRUE) - preview mode. SAFETY: dryRun defaults to true. You MUST explicitly pass dryRun:false to create issues. Dry-run output is designed to work as a human pre-write confirmation page: it includes a per-issue preview (title/labels/truncated body), warnings for issues missing labels, missing/short bodies, or titles exceeding GitHub's 256-character limit, and the exact repo coordinates that would be written to. Args: - owner, repo: Repository coordinates. - titlePrefix (string?): Prefix for every issue title. - issues (array): 1-50 issues, each with title, body, labels?, assignees?. Accepts plan_from_context's issueDrafts directly. - dryRun (boolean): Default true - preview mode only. Optional recovery controls belong in request params._meta["io.github.SakuraCianna/agentic-sdlc-mcp/issue-recovery"], never tool arguments: - idempotencyKey: 1-128 ASCII characters matching [A-Za-z0-9._:-]+. Use the same key in preview and live metadata and reuse the complete payload when resuming. - previewDigest: The 64-character lowercase hex digest from the reviewed preview. Mismatches cause zero writes. The metadata value is a strict object with only those optional fields. Invalid recovery metadata is rejected before GitHub access. Other tool arguments retain their legacy ignored-extra-field behavior. Returns: Confirmed created/reused issue numbers, per-input created/reused/failed/unknown/pending status and recovery guidance, or a preview + digest. Cancellation stops new writes but cannot establish whether an in-flight write committed. Idempotency recovery checks at most 300 issues including closed ones and fails closed for missing inputs when evidence is incomplete. Markers are correlation data, not authorization; concurrent processes and restarts cannot guarantee exactly-once writes. SDLC_READ_ONLY=true rejects live writes.prepare_work_itemGenerate a risk-aware implementation brief for a GitHub issue. The brief combines bounded Issue/comment evidence, repository policy, confirmed package scripts, related paths, and recent PR history to produce explainable risk, defensive requirements, negative scenarios, rollback, observability, and a safe handoff prompt. Args: - owner, repo: Repository coordinates. - issueNumber (number): The issue to prepare. - includeRelatedFiles (boolean): Heuristically list related file paths. Default: false. Explicit paths are checked on the default branch, actual adjacent tests are discovered with bounded naming conventions, and CODEOWNERS are attached when available. - includeRecentPRs (boolean): Scan recent merged PRs (up to 20) for ones that touched the related file hints and return up to 5 matches. Requires includeRelatedFiles to find hints to match against — if no hints exist, returns an empty list. Default: false. This opt-in deep scan is bounded but can use up to 61 additional sequential GitHub requests (one PR candidate page plus up to three file pages for each of 20 candidates). - includeDependencies (boolean): Read official blocked-by, blocking, sub-issue, and timeline cross-reference endpoints, capped at 20 items per source. Default: false. - workType (string?): Explicit docs/feature/bugfix/refactor/security/release/infra type. - riskLevel (string?): Explicit minimum low/medium/high/critical risk. Repository policy can raise it. Returns: Structured risk profile and source evidence, issue/derived acceptance criteria, defensive requirements, negative scenarios, verified repository commands, rollback/observability plans, bounded history metadata, and Markdown safe for agent consumption. Issue and comment text remain untrusted evidence.quality_gate_statusEvaluate real merge-gate evidence for a pull request or CI evidence for a git ref. Args: - owner, repo: Repository coordinates. - pullNumber (number?): PR number (preferred); evaluates CI, reviews, policy, labels, and mergeability. - ref (string?): Branch name or commit SHA; evaluates CI only. - blockingLabels (string[]): Exact case-insensitive PR labels that block merging. Pass [] to disable. Returns: A structured evidence packet, blockers, warnings, next actions, and a conservative conclusion.create_pr_summaryGenerate a structured PR summary from the pull request diff and metadata. The summary includes: change overview, affected files, test coverage signals, risks, review checklist, and release notes draft. Args: - owner, repo: Repository coordinates. - pullNumber (number): The PR to summarise. Returns: Markdown PR summary + structured metadata.review_pr_against_standardReview a pull request against Agentic SDLC standards. Standards: - basic: Core checks (tests, description, draft status, commit count) - strict: basic + large diff detection, missing docs - security-focused: strict + mature secret-scanner CI evidence + supplemental patch heuristics, .env files, lockfile changes, dist files Ownership check (independent of standard, runs when checkOwnership is true and a CODEOWNERS file exists): Matches changed files against .github/CODEOWNERS (or CODEOWNERS / docs/CODEOWNERS), and flags any matched owner who is neither the PR author, a requested reviewer, nor an actual reviewer. Args: - owner, repo: Repository coordinates. - pullNumber (number): The PR to review. - standard: "basic" | "strict" | "security-focused". Default: "basic". - checkOwnership (boolean, default: true): Enable the CODEOWNERS ownership check. Returns: Sorted findings by severity, test coverage signal, ownership routing gaps, release risk, and conclusion.security_triageRead GitHub security alerts (code scanning, Dependabot, secret scanning) and produce a triage report. Required token scopes: - security_events, or public_repo for public-only repos (Code Scanning) - security_events, or public_repo for public-only repos (Dependabot) - repo or security_events (Secret Scanning) Args: - owner, repo: Repository coordinates. - includeCodeScanning / includeDependabot / includeSecretScanning: Default true. Returns: Alert summary, severity breakdown, recommended fix order, suggested issues.release_readiness_checkPre-release assessment: CI status, open bugs, CHANGELOG, release checklist, rollback template. Required token scopes: - repo, or public_repo for public-only repos (checks, issues, and file contents access) Args: - owner, repo: Repository coordinates. - baseRef (string?): Deprecated compatibility field; ignored. - headRef (string?): Branch, tag, or commit SHA to release (defaults to default branch). - pullNumber (number?): Uses the PR head commit for CI status. Returns: isReady flag, blocking issues, CI status, docs check, release checklist, rollback template.agent_handoff_packetGenerate a compact handoff packet so another AI agent can continue SDLC work. Use when wrapping up a session, before handing off to a specialised agent, or when context is nearing its limit. Args: - owner, repo: Repository coordinates. - issueNumber (number?): Issue being worked on. - pullNumber (number?): PR being worked on. - releaseRef (string?): Release ref being worked on. - currentStatus (string?): Optional caller-authored status; system evidence is used when omitted. - goal / nonGoals / completedActions / decisions: Optional caller-authored handoff context. - nextSteps (string[]?): Ordered tasks for the next agent. Returns: Compact handoff prompt, repo context snapshot, and remaining tasks.branch_protection_statusRead classic branch protection AND repository rulesets for a branch (defaults to the repo's default branch). Required token scope: `repo` (or `public_repo` for public-only repos) with admin/read access to branch protection. Args: - owner, repo: Repository coordinates. - branch: Optional. Falls back to the repository's default branch. Returns: Required reviews / status checks / force-push / deletion settings from both classic protection and rulesets, findings by severity, verification gaps, and a protected/partially_protected/unprotected/unknown conclusion.workflow_permissions_auditScan `.github/workflows/*.yml` for `permissions` declarations (top-level and per-job) and flag least-privilege gaps. Required token scope: `repo` (or `public_repo` for public-only repos) with read access to repository contents. Args: - owner, repo: Repository coordinates. - ref: Optional. Branch, tag, or SHA to read workflow files from. Falls back to the repository's default branch. Flags: - No `permissions` declared anywhere in the file (workflow or job level) -- relies on the repo/org default token scope instead of an explicit declaration. - `permissions: write-all` (top-level or per-job) -- grants write access to every scope. - Any scope granted `write` on a workflow triggered by `pull_request_target` -- a known injection/exfiltration risk since that trigger runs with the base repo's token against untrusted PR content. Returns: per-file findings by severity and a least_privilege/needs_review/over_permissioned conclusion.- +1 more on the listing page
CD MCP Server tools 70
github_get_authenticated_userGet the authenticated GitHub user (validates token and shows login).github_get_rate_limitCheck REST API rate limit status for the current token.github_create_repositoryCreate a new repository for the authenticated user or an organization.github_get_repositoryGet repository metadata.github_list_repositoriesList repositories for a user or organization.github_create_branchCreate a branch from an existing ref (e.g. main).github_fork_repositoryFork a repository to the authenticated user or an organization.github_list_commitsList commits on a branch or for the whole repo.github_get_commitGet a single commit with files changed.github_compare_commitsCompare two commits (base...head) — useful for release notes and PR scope.github_create_commitCreate a commit on a branch by updating one or more files (GitHub Git API — no local clone required).github_get_combined_statusGet combined commit status (legacy statuses + check runs summary) for CI/CD gates.- +58 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Agentic SDLC MCP
{
"mcpServers": {
"agentic-sdlc-mcp": {
"command": "npx",
"args": [
"-y",
"agentic-sdlc-mcp"
],
"env": {
"GITHUB_TOKEN": "YOUR_GITHUB_TOKEN_HERE",
"GITHUB_OWNER": "YOUR_GITHUB_OWNER_HERE",
"GITHUB_REPO": "YOUR_GITHUB_REPO_HERE"
}
}
}
}
CD MCP Server
{
"mcpServers": {
"github-ci-cd-mcp-server": {
"command": "npx",
"args": [
"-y",
"@kinus/github-cicd-mcp"
],
"env": {
"GITHUB_TOKEN": "YOUR_GITHUB_TOKEN_HERE",
"GH_TOKEN": "YOUR_GH_TOKEN_HERE"
}
}
}
}
Frequently asked questions
Agentic SDLC MCP is categorized under Version Control and uses a local stdio subprocess. CD MCP Server belongs to Version Control and uses a local stdio subprocess. Pick Agentic SDLC MCP for version control work and CD MCP Server for version control.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Agentic SDLC MCP has no declared pricing — check the project's own site. CD MCP Server has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add agentic-sdlc-mcp and github-ci-cd-mcp-server as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Agentic SDLC MCP has a quality signal of 61/100 (Good) with 1 views, 0 installs and 1 GitHub stars. CD MCP Server has 60/100 (Good) with 2 views, 0 installs and 2 GitHub stars.