sdlc-workflow-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WORKFLOW_DEMO_USER | No | Demo identity; allowed only when the service host is loopback. | |
| WORKFLOW_SERVICE_URL | Yes | Base URL of the local Workflow Service (e.g. http://127.0.0.1:8080). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| workflow_list_my_tasksB | List persisted workflow tasks visible to the current user. |
| workflow_get_task_contextB | Read the persisted task state before starting or resuming local Copilot work. |
| workflow_get_task_auditB | Read the valid task audit stream. Compensated and invalidated events are excluded by Workflow Service. |
| workflow_claim_taskB | Claim a task with a bounded lease before local Copilot reasoning begins. |
| workflow_submit_artifactC | Persist a structured, human-readable workflow artifact produced by local Copilot. |
| workflow_request_approvalC | Record a human approval for an exact artifact and task version. |
| workflow_complete_taskC | Confirm the current local result and advance it to its next persisted gate. |
| workflow_get_identityB | Read the bound enterprise identity. GitHub membership is not required for non-coding Scrum Masters. |
| workflow_validate_pod_rosterC | Validate a bounded Pod roster without persisting it. |
| workflow_import_pod_rosterB | Persist a validated Pod roster only after explicit human confirmation. |
| workflow_get_integration_diagnosticsB | Read evidence-labelled Jira, Confluence, GHES, Jenkins, and Splunk diagnostics with observation time. |
| workflow_analyze_journeyC | Run deterministic cross-repository Journey contract and evidence-gap analysis. |
| workflow_get_next_internal_validationC | Read the next company-network validation action; it never claims simulated evidence is real. |
| workflow_epic_createC | Create a fictional Epic workflow aggregate. |
| workflow_epic_activateC | Activate a CREATED epic before attaching tickets. |
| workflow_epic_attach_ticketC | Attach a channel ticket (API/WEB/IOS/ANDROID) to an active epic. |
| workflow_ticket_advanceC | Advance a ticket along its delivery status machine with an exact version. |
| workflow_ticket_add_repo_taskC | Create a repo-level implementation task under a ticket. |
| advance_repo_taskC | Advance a repo task through planning, pull request, and merge with an exact version. |
| workflow_epic_add_dependencyC | Record a REQUIRES_BEFORE dependency between two tickets of one epic. |
| workflow_epic_create_change_requestC | Create an emergency change request against an epic. |
| workflow_epic_approve_change_requestC | Approve a change request as BUSINESS_OWNER or TECHNICAL_OWNER; both roles are required. |
| workflow_task_skipC | Skip a stage with a persisted attestation (reason, discussed-with, actor role). |
| workflow_epic_resumeA | Read persisted epic state, open tasks, next actions, and the audit trail after a shutdown. |
| workflow_epic_joinC | Join an epic as an active participant with a declared role. |
| workflow_get_related_artifactsB | Read artifacts related to a task through the persisted artifact graph, bounded by depth. |
| workflow_submit_decisionC | Persist a bounded architectural or product decision (ADR-style) for a journey. |
| workflow_assign_workC | Assign a task to a bound identity with a declared actor role. |
| workflow_report_blockerC | Report a blocker against a ticket with a typed reason and bounded description. |
| workflow_record_manual_e2eC | Record a manual end-to-end verification result without fabricating automation evidence. |
| workflow_record_accessibility_resultC | Record a manual or automated WCAG accessibility check result for a task. |
| workflow_record_tagging_resultC | Record a bounded content-tagging or taxonomy classification result for a task. |
| workflow_prepare_jira_projectionB | Prepare a local Jira projection from persisted tickets without calling Jira. |
| workflow_get_freshnessC | Read the freshness (staleness) of journey and repository context. |
| workflow_onboard_repositoryC | Onboard a repository into the local workflow context. |
| workflow_onboard_journeyC | Onboard a journey into the local workflow context from its manifest. |
| workflow_sync_onboarding_artifactC | Sync an onboarding artifact (e.g. CONTEXT.md) to the workflow service. |
| workflow_scan_repository_contextC | Scan and summarize repository context for onboarding or graph building. |
| workflow_analyze_http_dependenciesC | Analyze cross-service HTTP dependencies from a journey manifest. |
| workflow_get_repository_graphC | Build a deterministic repository dependency graph from a journey manifest. |
| workflow_get_journey_graphB | Build a deterministic journey graph (repositories, screens, http edges) from a manifest. |
| workflow_mark_context_staleA | Mark journey or repository context as stale to force re-onboarding. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 42 tools
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.
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.
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.
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.