agentic-sdlc-mcp

Generate SDLC Plan from Context

plan_from_context

Read-onlyIdempotent

Generate a structured Agentic SDLC plan from a goal and repo context, tailored by work type, with phase steps and issue drafts ready for GitHub.

Instructions

Generate 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.

Input Schema

Name	Required	Description
`goal`	Yes	The user goal or feature request to plan around.
`repo`	No	GitHub repo. Falls back to GITHUB_REPO.
`owner`	No	GitHub owner. Falls back to GITHUB_OWNER.
`workType`	No	Explicit task category: docs, feature, bugfix, refactor, security, release, or infra. If omitted, it is inferred from `goal` + `acceptanceCriteria` -- check the output's `confidence` and `needsClarification` fields rather than assuming the guess is correct.
`constraints`	No	Technical or business constraints.
`acceptanceCriteria`	No	Acceptance criteria the implementation must satisfy.

Output Schema

Name	Required	Description	Default
`goal`	Yes
`repo`	Yes
`risks`	Yes
`phases`	Yes
`language`	Yes
`workType`	Yes
`reasoning`	Yes
`confidence`	Yes
`constraints`	Yes
`issueDrafts`	Yes
`policyDigest`	No
`policyErrors`	Yes
`defaultBranch`	Yes
`policySources`	Yes
`trustBoundary`	No
`policyDegraded`	Yes
`suggestedIssues`	Yes
`acceptanceCriteria`	Yes
`appliedPolicyRules`	Yes
`needsClarification`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.11.0Oct 18, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed1 schema field changedv1.9.0Jul 29, 2026

addedOutput schema / properties / trustBoundary

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "callerAndRepositoryContent": {
+      "const": "untrusted",
+      "type": "string"
+    },
+    "instructionHandling": {
+      "const": "never_execute",
+      "type": "string"
+    },
+    "permissionHandling": {
+      "const": "never_expand",
+      "type": "string"
+    },
+    "secretHandling": {
+      "const": "never_reveal",
+      "type": "string"
+    }
+  },
+  "required": [
+    "callerAndRepositoryContent",
+    "instructionHandling",
+    "secretHandling",
+    "permissionHandling"
+  ],
+  "type": "object"
+}

Changed6 schema fields changedv1.8.0Jul 13, 2026

addedOutput schema / properties / appliedPolicyRules

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "source": {
+        "const": "repository",
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "source"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / policyDegraded
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / policyDigest
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / policyErrors

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / policySources

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "blobSha": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "digest": {
+        "type": "string"
+      },
+      "kind": {
+        "enum": [
+          "default",
+          "repository"
+        ],
+        "type": "string"
+      },
+      "path": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "ref": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      }
+    },
+    "required": [
+      "kind",
+      "path",
+      "ref",
+      "blobSha",
+      "digest"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "goal",
-  "repo",
-  "defaultBranch",
-  "language",
-  "workType",
-  "confidence",
-  "reasoning",
-  "needsClarification",
-  "constraints",
-  "acceptanceCriteria",
-  "phases",
-  "suggestedIssues",
-  "issueDrafts",
-  "risks"
-]New value: +[
+  "goal",
+  "repo",
+  "defaultBranch",
+  "language",
+  "workType",
+  "confidence",
+  "reasoning",
+  "needsClarification",
+  "constraints",
+  "acceptanceCriteria",
+  "phases",
+  "suggestedIssues",
+  "issueDrafts",
+  "risks",
+  "policySources",
+  "appliedPolicyRules",
+  "policyDegraded",
+  "policyErrors"
+]

First observedv1.5.0Jul 9, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, non-destructive, idempotent), and the description adds genuinely useful context beyond them: it is template-based with no LLM call, it reads live repo metadata and the actual label list to avoid inventing labels, and it surfaces confidence/needsClarification. This is more than the annotations convey, though it omits cost/latency or failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then structured Args/Returns sections. The Args block largely restates schema descriptions already at 100% coverage, which is mild redundancy, but the Returns section earns its place by explaining the issueDrafts chaining contract.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description does not need to enumerate return fields, yet it still flags the key structured fields and the handoff to create_issue_set. Combined with the behavioral notes, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining the semantic effect of workType (docs skip mandatory unit tests, bugfix always includes repro + regression tests) and the inference/confidence behavior when it is omitted. It only weakly duplicates the env-var fallbacks the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and artifact ('Generate a structured Agentic SDLC plan') with the exact phase pipeline and the source inputs (goal + repo context). It also names the downstream consumer (create_issue_set) and the workType dimension, which clearly separates it from siblings like prepare_work_item or repo_context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the goal-driven framing and the note that its issueDrafts feed create_issue_set's input, but there is no explicit when-to-use/when-not or comparison against the planning-adjacent siblings (prepare_work_item, repo_context). The guidance about checking confidence/needsClarification is arguably invocation behavior rather than tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server