sdlc-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_work_categoriesA | List the work categories of the SDLC standard, with their purpose and the artifacts each one must produce before it is complete. |
| get_work_categoryA | Describe one work category in full: purpose, exit artifacts, and the tasks with their default owning role. Accepts an id such as '02' or a key such as 'requirements'. |
| list_artifact_typesA | List every artifact type in the standard: owning category, default owner role, id convention and what the artifact is for. |
| get_artifact_templateA | Return the Markdown template for an artifact type, together with the sections its readiness rules require. Use this before writing the artifact. |
| validate_artifactA | Validate artifact content against the Definition of Ready or Definition of Done for its type. Returns a pass/fail verdict with blockers and warnings. Blockers must be fixed before the artifact moves on. Pass known_ids (the ids of artifacts that exist in your project) to have outbound references checked; omit it and reference checking is skipped. |
| lookup_glossary_termA | Look up a domain term in the project glossary. Matches the term, its aliases, and finally the definition text. Use this instead of guessing what a domain word means. |
| next_tasksA | Given a work category and the artifact types that already exist, return the tasks still outstanding and who owns them. Pass staffed_roles to have owners reassigned through the fallback chain when a role is not on the project. |
| list_examplesA | List the bundled example artifacts. Examples are filled-in reference documents in a fictional demo domain; read one before writing your own. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| draft_artifact | Draft an artifact of the given type the way this standard expects: read the template, check the glossary, write, then validate. |
| review_artifact | Review an existing artifact against the standard: run the validator, then review the substance the validator cannot see. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| SDLC standard overview | Work categories and artifact types of the standard, as a Markdown table. |
| Domain glossary | Every agreed domain term with its definition and aliases. |
TDQS
Scored across 8 tools
Each tool targets a distinct operation: category lookup, artifact type/template retrieval, validation, glossary lookup, task planning, and example listing. The list/get pairs are clearly separated by singular detail vs. plural overview.
Most tools follow a clear verb_noun pattern such as get_work_category, list_artifact_types, validate_artifact, and lookup_glossary_term. The outlier is next_tasks, which is not verb-led and breaks the otherwise consistent naming convention.
Eight tools is a well-scoped size for an SDLC standard assistant. Each tool covers a meaningful part of the workflow without redundancy or bloat.
The core standard, template, validation, glossary, and task-planning capabilities are present. However, the set tells agents to read example artifacts before writing their own, yet only offers list_examples with no way to retrieve a specific example, leaving an obvious gap in that workflow.