Skip to main content
Glama
Tingsum26

sdlc-workflow-mcp

by Tingsum26
README.md
# sdlc-workflow-mcp

A standalone stdio [Model Context Protocol](https://modelcontextprotocol.io) server that exposes a
bounded, fictional-data slice of the SDLC workflow tools for local Copilot use.

> **Provenance:** extracted from [`Tingsum26/sdlc-agent-platform`](https://github.com/Tingsum26/sdlc-agent-platform)
> at the `seven-repo-split-baseline` tag (commit `bf48e15`), source path `apps/workflow-mcp`.
> This repository is one slice of the seven-repository split described in the platform BOM
> ([`docs/platform-bom.yaml`](docs/platform-bom.yaml)).

## What this is

- A TypeScript MCP server (`stdio` transport) that proxies a bounded set of workflow tools to a
  local Workflow Service over HTTP.
- All fixtures are fictional (`example.invalid`, `REPO_A`, `DEMO-123`, `EPIC-DEMO-1`, fictional
  identities). There is no model client, no credentials, and no real company data in this slice.

## What this is not (registered gap)

The full approved tool catalog in the platform BOM is larger than this slice. This repository
registers only the subset implemented in the `apps/workflow-mcp` vertical slice at split time
(workflow tasks, internal-readiness, epic/ticket/repo-task, change-request, and journey tools).
Remaining catalog tools are tracked in the originating platform BOM and its migration map, not here.

## Tool catalog

42 tools are registered, grouped below. Per-tool source endpoints and local-derivation fallbacks
are documented in [`docs/tool-catalog.md`](docs/tool-catalog.md).

**workflow** (task, ticket, epic, decision, artifact, and Jira-projection operations):

`workflow_list_my_tasks`, `workflow_get_task_context`, `workflow_get_task_audit`,
`workflow_claim_task`, `workflow_submit_artifact`, `workflow_request_approval`,
`workflow_complete_task`, `workflow_get_identity`, `workflow_validate_pod_roster`,
`workflow_import_pod_roster`, `workflow_get_integration_diagnostics`, `workflow_analyze_journey`,
`workflow_get_next_internal_validation`, `workflow_epic_create`, `workflow_epic_activate`,
`workflow_epic_attach_ticket`, `workflow_ticket_advance`, `workflow_ticket_add_repo_task`,
`advance_repo_task`, `workflow_epic_add_dependency`, `workflow_epic_create_change_request`,
`workflow_epic_approve_change_request`, `workflow_task_skip`, `workflow_epic_resume`,
`workflow_epic_join`, `workflow_get_related_artifacts`, `workflow_submit_decision`,
`workflow_assign_work`, `workflow_report_blocker`, `workflow_record_manual_e2e`,
`workflow_record_accessibility_result`, `workflow_record_tagging_result`,
`workflow_prepare_jira_projection`.

**onboarding-context** (repository/journey onboarding, context scan, graphs, freshness, staleness):

`workflow_get_freshness`, `workflow_onboard_repository`, `workflow_onboard_journey`,
`workflow_sync_onboarding_artifact`, `workflow_scan_repository_context`,
`workflow_analyze_http_dependencies`, `workflow_get_repository_graph`,
`workflow_get_journey_graph`, `workflow_mark_context_stale`.

## Prerequisites

- Node.js >= 20.19.0
- pnpm

## Build and test

```sh
pnpm install
pnpm build
pnpm test
```

## Starting the stdio server

The server requires a Workflow Service URL and speaks MCP over stdio:

```sh
pnpm install
pnpm build
WORKFLOW_SERVICE_URL=http://127.0.0.1:8080 node dist/index.js
```

Environment variables:

| Variable                 | Required | Description                                                             |
| ------------------------ | -------- | ----------------------------------------------------------------------- |
| `WORKFLOW_SERVICE_URL`   | yes      | Base URL of the local Workflow Service (e.g. `http://127.0.0.1:8080`).  |
| `WORKFLOW_DEMO_USER`     | no       | Demo identity; allowed only when the service host is loopback.          |

On startup failure or missing configuration, the server writes a structured JSON diagnostic to
`stderr` and exits with code `2`.

## Layout

- `src/` — MCP server, API client, diagnostics, and tool registration.
- `test/` — vitest suite covering tool discovery, correlation IDs, audit visibility, safe error
  mapping, cancellation, and stderr redaction.

TDQS

C2.7/5.0

Scored across 42 tools

Disambiguation3/5

While most tools have distinct verbs and resources, there is overlap among the many graph/onboarding/analysis tools (e.g., workflow_get_repository_graph, workflow_get_journey_graph, workflow_analyze_journey, workflow_analyze_http_dependencies) and between workflow_ticket_advance and advance_repo_task. Descriptions help clarify, but the sheer number of similar read/analysis operations could still lead to misselection.

Naming Consistency3/5

All names use snake_case, but the ordering is inconsistent: some follow workflow_<entity>_<action> (workflow_epic_create) while others follow workflow_<action>_<object> (workflow_get_task_context). One tool (advance_repo_task) also lacks the workflow_ prefix, making the convention mixed though still readable.

Tool Count2/5

42 tools far exceeds the 3-15 sweet spot and the rubric's 25+ threshold for 'too many,' making the surface heavy even for a complex SDLC domain. While each tool may have a distinct purpose, the volume increases cognitive load and selection risk.

Completeness4/5

The set covers a broad SDLC workflow lifecycle: epic/ticket/task creation, advancement, approvals, artifacts, decisions, blockers, onboarding, graphs, diagnostics, and identity. Some gaps exist (e.g., no explicit list/get for epics or tickets beyond task context), but core workflows are well-supported.

Maintenance

ActivityMaintained
ResponsivenessNo issues