Skip to main content
Glama
DungNV512

ai-sdlc-harness-mcp

by DungNV512
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

ai-sdlc-harness-mcp

Integration + distribution layer for an AI-assisted SDLC harness built around the Stockbook app project.

This repo holds two halves:

  • mcp-server/ — an MCP (Model Context Protocol) server exposing Confluence, Jira, GitHub, GitLab, Microsoft Teams and a Claude Code trigger tool — 28 tools. Usable from any MCP client (Claude Code, Claude Desktop, Cowork, or any other MCP-speaking agent), not just from inside one repo.

  • plugin/ — an installable Claude Code plugin marketplace packaging the AI-SDLC harness itself (agents, commands, skills, hooks) that already runs in the stockbookapp repo, split into a framework-agnostic vnd-ai-sdlc layer and a vnd-ai-sdlc-stockbook. vnd-ai-sdlc ships the MCP server inside itself as a self-contained bundle, so installing the plugin — no clone, no npm install, no build — is enough to get the whole AI-SDLC (rules, skills, commands, sub-agents, and the MCP tools) working in a fresh repo; only credentials come from your environment. It also carries a governed skill lifecycle (/skill-new → /skill-submit → /skill-approve → /skill-sync) so a skill one person writes reaches everyone else through Jira + PR review. Real-installed and verified with a live Claude Code CLI — see plugin/README.md for install steps, the bugs that real install caught, and the known limitations it surfaced.

Start here

You want to

Read

Install it and run it on real work

plugin/README.md, then docs/ai-sdlc/cookbook.md

Know what each phase produces and when it is done

stage-a-discovery.md · stage-b-definition.md · stage-c-design.md

Write one of the documents

the matching file in docs/ai-sdlc/templates/, plus document-conventions.md

Know the MCP tools and their env vars

mcp-server/README.md

Related MCP server: confluence-mcp-server

The document standard

Every phase output follows one set of conventions (C-0…C-10) in docs/ai-sdlc/document-conventions.md, derived by reading the organisation's own shipped documents rather than from first principles — two real SRSs, two Product Listing pages, a PRD, and two completed IPAM Way boards.

The rule that settles arguments: where two of those documents do the same thing differently, the Stockbook project's form wins (C-0). A silence is not a conflict — where only one document does something at all, it is an addition, kept and labelled with its source.

python3 docs/ai-sdlc/check-conventions.py enforces the conventions mechanically and exits non-zero on failure. It is scaffolded into consuming repos by /harness-init, and it exists because this framework insists on machine-checkable DoDs and, for a while, had none of its own.

Status

Phase

What

Status

1

Jira MCP tools (12)

✅ done

1

Confluence: create_confluence_page

✅ done

3

GitHub tools (3, read+create surface, live-tested)

✅ done

5

Claude Code trigger tool (run_claude_code_command)

✅ done — verified against a mock CLI, not a real install

6

Plugin extraction (plugin/, marketplace.json, Standard/overlay split)

✅ done — real-installed + verified with a live Claude Code CLI (see plugin/README.md)

7

Self-contained plugin: MCP server bundled inside vnd-ai-sdlc + dev-override launcher

✅ done

7

Skill lifecycle commands (/skill-new, /skill-submit, /skill-approve, /skill-sync) with Jira + PR approval gate

✅ done

4

Microsoft Teams (send_teams_message via a Workflows webhook)

✅ built — not live-tested: the org egress allowlist blocks powerplatform.com, so the POST must be verified from a machine that can reach Microsoft

2

Confluence full parity (get/update/search/list_spaces)

✅ built — not live-tested: ipas-tech.atlassian.net is egress-blocked. Logic covered by unit tests

3

GitLab tools (5, read+create surface)

✅ built — not live-tested: both gitlab.com and gitlab-new.vndirect.com.vn are egress-blocked. Logic covered by unit tests

A

Stage A discovery A0–A5 + G1, with /idea-card, /problem-canvas, /market-scan, /discovery-report, /ipam-way

✅ built — not yet run on a real feature

B

Stage B definition B0–B2 + G2/G3, with /context-doc, /brd, /prd

✅ built — not yet run on a real feature

C

Stage C design C1–C5 + G4, with /sa-view, /srs, /ui-spec, /test-strategy, /security-review

✅ built — not yet run on a real feature

—

Document conventions C-0…C-10 + check-conventions.py

✅ done — the checker passes on this repo

—

23 versioned artefact templates, incl. IPAM Way and OMVP

✅ done

—

traceability.yaml schema (vnd.ai-sdlc.traceability/v3) + generation in /plan-feature

✅ done

—

Publishing artefacts to Confluence automatically

❌ not built — only /gate calls create_confluence_page. Stage A/B/C artefacts reach the manifest, not the wiki

What "built but not live-tested" means here

Three integrations are complete, build clean, and pass unit and stdio JSON-RPC tests, but have never made a real call — every one of their hosts (gitlab.com, gitlab-new.vndirect.com.vn, ipas-tech.atlassian.net, powerplatform.com) is refused by this environment's egress allowlist, which permits github.com. That is why GitHub is the one platform with a genuine end-to-end verification behind it.

So the request/response shapes are exercised against stubs, not against the real APIs. The places where those APIs differ in ways a naive port gets wrong — GitLab addressing projects by URL-encoded path, having no draft flag, replacing rather than appending reviewer lists, taking numeric user ids instead of usernames; Confluence requiring version current + 1 on every update — are handled explicitly and covered by mcp-server/unit-test.mjs. What is not covered is whether the endpoints behave as documented. Run npm test in mcp-server/, then make one real call per platform from a machine with network access before trusting them.

See mcp-server/README.md for the tool reference and setup instructions.

What "built but not yet run" means for the upstream stages

Stages A, B and C are complete specifications with working commands, a template per artefact, and DoDs the commands enforce. What has not happened is a single real feature going A → G4 through them. Until that run exists, treat the upstream half as a well-specified system that has never met a deadline, a stakeholder who will not answer, or a document someone refuses to sign.

Why this exists

The Confluence create_confluence_page tool was built first, specifically because Atlassian's own hosted Rovo MCP server's createConfluencePage route returns a persistent 404 (see mcp-server/README.md for the full diagnosis). Jira, GitLab, GitHub and Teams tools extend the same server into a general integration layer for the harness, and the planned plugin/ half makes the whole harness — not just the integrations — installable in one step in any frontend repo.

License

MIT

Available Tools

1 tool
create_confluence_pageA

Create a new Confluence Cloud page via the REST API v2 (storage-format body). Built as a working alternative to the hosted Rovo MCP createConfluencePage tool, which returns a persistent 404. Requires CONFLUENCE_SITE, ATLASSIAN_EMAIL and ATLASSIAN_API_TOKEN to be set in the environment.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesTitle of the new page.
statusNoPage status. Defaults to 'current' (published).
spaceIdYesNumeric Confluence space ID, or a space key (e.g. 'DAS') to resolve automatically.
bodyHtmlYesPage body in Confluence 'storage format' HTML (not Markdown, not the visual editor's format).
parentIdNoOptional numeric ID of the parent page.

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool uses REST API v2, requires specific credentials, and creates a page in storage format. However, it does not describe failure modes, response behavior, or side effects beyond creation, and it does not explicitly warn that a page is immediately published by default. There is no annotation contradiction.

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

Conciseness5/5

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

The description is two sentences with no filler. The purpose is front-loaded, and the alternative-tool context and environment requirements each earn their place. It is concise but information-dense.

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

Completeness4/5

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

For a create tool with no annotations and no output schema, the description supplies the essential context: why this tool exists, how it is invoked, the body format, and required credentials. The schema covers parameter details. It does not describe the return value or edge cases like parent page resolution, but these are minor gaps given the strong schema coverage.

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

Parameters3/5

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

The input schema already describes all 5 parameters with 100% coverage, including the storage-format constraint on bodyHtml and the spaceId resolution behavior. The description reinforces the storage-format point but does not add meaningful new parameter semantics beyond what the schema provides, so a baseline 3 is appropriate.

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?

The description opens with a specific verb and resource: 'Create a new Confluence Cloud page via the REST API v2 (storage-format body).' It also distinguishes itself from the hosted Rovo MCP createConfluencePage tool by stating it is a working alternative, so the agent can understand exactly what this tool does and how it is different.

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

Usage Guidelines4/5

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

The description explicitly frames when to use this tool: as a replacement for the hosted Rovo MCP createConfluencePage tool that returns a persistent 404. It also lists the required environment variables (CONFLUENCE_SITE, ATLASSIAN_EMAIL, ATLASSIAN_API_TOKEN), giving clear prerequisites. It does not enumerate other alternatives, but there are no sibling tools provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedcreate_confluence_page
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no possibility of confusing it with another tool. The purpose is clearly described as creating a Confluence page.

Naming Consistency5/5

The tool name follows a clear verb_noun pattern (create_confluence_page), which is consistent and readable. As a single tool, there are no naming inconsistencies.

Tool Count2/5

The server name suggests a broad SDLC harness, but only one narrow Confluence creation tool is provided. This is far too few tools for the implied scope, making it feel like an extreme under-delivery.

Completeness1/5

The domain implied by 'ai-sdlc-harness-mcp' would require far more operations such as issue tracking, code review, CI/CD integration, and documentation management. With only a single page-creation tool, the vast majority of expected functionality is missing.

Maintenance

ActivityMaintained
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers