This MCP server provides programmatic access to a catalog of build-time SDLC agent roles and skill checklists for AI-assisted software development, along with project manifest integration and review launching.
List agents: list_agents returns all agent role definitions (e.g., product-analyst, code-reviewer) with metadata, including permissions and optional manifest-resolved write_paths for CI/CD enforcement.
Get agent: get_agent fetches a fully resolved markdown definition for a specific agent, substituting {{project.*}} placeholders using an optional project manifest.
List skills: list_skills returns all SDLC skill checklists (e.g., pr-code-review, architecture-review) with applies_when tags for filtering.
Get skill: get_skill returns the resolved markdown checklist for a specific skill, with placeholders filled from the manifest.
Project overlay skills: list_project_skills and get_project_skill manage domain-specific skills stored in the project’s .skills/ directory.
Project manifest: get_project_manifest returns the parsed sdlc.project.yaml used for placeholder resolution; validate_manifest (may not be exposed in all versions) checks for missing core/conditional keys.
Launch reviews: Prompts like independent_code_review, architecture_review, and launch_role start subagent review sessions for any agent/skill pair.
Resources: Resources under enterprise-sdlc:// expose the catalog manifest, individual agents, and skills.
CI/CD integration: Agent write_paths can be resolved against a manifest to enforce that PR changes stay within allowed modification paths.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Enterprise SDLC MCP review PR #42 using the code reviewer agent"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Reusable build-time SDLC agent roles and skills, served over the Model Context Protocol (MCP), for any GitHub-first, AI-assisted software project.
This is build-time tooling for how software gets delivered — agent role definitions (Product Analyst, Solution Architect, Code Reviewer, etc.) and generic review checklists (PR review, architecture review, IAM least-privilege, eval-scenario design, ...). It is not a runtime dependency of any product; consuming repos only need it while an AI coding agent is doing SDLC work.
This package was extracted (with git history) from support-ticket-triage-assistant, where it was first built and used as the reference implementation. It now also serves supportrouter-aws. Extracting it removed a fragile cross-repo coupling where a second project pointed directly at the first project's virtualenv and folder path.
Related MCP server: speckitmcp
9 agents: product-analyst, solution-architect, implementation-planner, test-eval-designer, code-reviewer, refactor-reviewer, documentation-agent, release-manager, dependency-upgrade-agent.
31 skills: generic SDLC checklists (pr-code-review, architecture-review, github-backlog-creation, release-readiness-review, application-security-review, dependency-supply-chain-review, cicd-pipeline-review, api-contract-review, incident-postmortem-review, ...) plus stack-specific technical checklists (cdk-stack-review, cloud-infra-review, iam-least-privilege-review, bedrock-guardrails-review, dynamodb-data-model-review, fastapi-service-review, frontend-accessibility-review, llm-as-judge-rubric-design, eval-scenario-design, synthetic-data-design, knowledge-graph-modeling-review, graph-rag-retrieval-review, ...).
See enterprise_sdlc_mcp/catalog/manifest.yaml for the full index.
Every skill declares an applies_when tag so a consuming project can tell which ones are actually relevant to it, independent of the fixed used_by agent-role list:
Tag | Meaning |
| Generic SDLC guidance — relevant to any project regardless of stack. |
| Only relevant if the project exposes an API surface (REST/GraphQL/RPC), independent of framework. |
| Only relevant if the project has a frontend/UI surface. |
| Only relevant if the project provisions cloud/infra resources (any provider). |
| Only relevant if the product itself is LLM-backed at runtime (not just built with an AI coding agent). |
| Only relevant if the project's primary data store is a property graph / knowledge graph. |
| Only relevant if the project retrieves from a graph database to ground LLM-generated answers (graph-native retrieval, as distinct from document/vector retrieval). |
| Only relevant once that specific technology has been adopted — see the skill's own file for its "applies only if/when adopted" note. |
list_skills() returns applies_when for each entry so tooling (or an agent) can filter to what matters for a given project.
Every agent also declares a machine-readable permissions block — a structured companion to the prose "Code-Modify Permission" section in its own markdown — with a code_modify tier (none / scoped / conditional) and a write_paths allowlist. list_agents() returns this so tooling (a pre-merge hook, a CI gate) can check a PR's actually-changed files against what the authoring role was supposed to touch, instead of relying on someone reading prose. Pass manifest_path to list_agents() to get write_paths resolved against a real project instead of raw {{project.*}} placeholders.
Catalog markdown uses {{project.*}} placeholders resolved at serve time from each consuming repo's own sdlc.project.yaml manifest — deterministic string substitution, no LLM involved. See enterprise_sdlc_mcp/catalog/manifest_keys.yaml for the full, tested reference of every key the catalog can use (which keys are required for any project vs. only needed for a specific stack-tagged skill).
This is designed to be installed editable, from a local sibling checkout, into each consuming project's own virtualenv — never referenced across repos by path.
# from the consuming project's own repo, with its own .venv active
git clone https://github.com/raghuram-chittibomma/enterprise-sdlc-mcp.git ../enterprise-sdlc-mcp
pip install -e ../enterprise-sdlc-mcpStarting a brand-new project? Copy templates/new-project/ into the repo root instead of building this by hand — it ships a filled-out sdlc.project.yaml, AGENTS.md, .cursor/mcp.json, the docs/00_project–docs/03_operations skeleton every core doc key points at, a .skills/ overlay stub, and .github/ PR/issue templates + a CI workflow. It's the same folder structure support-ticket-triage-assistant and supportrouter-aws already converged on by hand, now codified so a new repo gets it for free. See templates/new-project/README.md for the checklist.
Adding this to an existing repo instead? Add an sdlc.project.yaml manifest at the consuming repo's root (see tests/fixtures/sdlc.project.yaml for the shape) and enable the server in the consuming repo's .cursor/mcp.json:
{
"mcpServers": {
"enterprise-sdlc": {
"command": "C:\\absolute\\path\\to\\consuming-project\\.venv\\Scripts\\python.exe",
"args": ["-m", "enterprise_sdlc_mcp.server"],
"env": {
"SDLC_PROJECT_MANIFEST": "C:\\absolute\\path\\to\\consuming-project\\sdlc.project.yaml"
}
}
}
}Use absolute paths for both command and SDLC_PROJECT_MANIFEST. A relative command (e.g. .venv/Scripts/python.exe) is not reliably resolved against the workspace root by Cursor on Windows — it can silently fall back to the global interpreter on PATH, which won't have this package installed and fails with ModuleNotFoundError. Absolute paths avoid that ambiguity entirely. (On Linux/macOS use .venv/bin/python; the same relative-path caveat may not apply there, but absolute paths are still the safer default.)
No PYTHONPATH tricks are needed once the package is pip-installed into that project's own venv — just point command at that venv's own interpreter.
Already have this installed somewhere and just want to pick up a new version? See ROLLOUT.md for the upgrade checklist instead of repeating first-time setup.
sdlc.project.yaml keys used by the core (always-tier) agents/skills — define these regardless of stack:
display_name, repo_root, docs.architecture, docs.data_model, docs.test_strategy, docs.product_brief, docs.orchestrator_brief, docs.project_charter, docs.release_notes, docs.runbook, paths.source, paths.tests, paths.evals, paths.project_skills, milestone.current, extensions.
A handful of keys are conditional — only needed if you invoke the specific stack-tagged skill that reads them (e.g. paths.infra for cdk-stack-review, docs.eval_strategy for llm-as-judge-rubric-design). See enterprise_sdlc_mcp/catalog/manifest_keys.yaml for the complete, tested list with descriptions and exactly which skill each conditional key belongs to.
An unresolved placeholder — a missing manifest key referenced by a skill you actually call — is a real gap: it leaks literal {{project.x}} text into the resolved output instead of failing loudly. Call the validate_manifest tool against your own sdlc.project.yaml to check which core/conditional keys are missing before that happens. tests/test_manifest_keys.py separately guards against catalog changes introducing an undocumented key.
Tool | Description |
| Catalog agent IDs, titles, source file, and |
| Resolved agent role markdown for a project |
| Catalog skill IDs, titles, and |
| Resolved skill checklist for a project |
| Domain skills from the project's own overlay path |
| Read a project-local overlay skill file |
| Parsed project manifest |
| Report which core/conditional |
Prompt | Use |
| Launch a Code Reviewer subagent with resolved role + |
| Launch a Solution Architect / Refactor Reviewer review pass |
| Generic: launch any agent id with any comma-separated list of skill ids and free-text context — use this instead of adding a new hardcoded prompt function per pairing |
Resources are also exposed under enterprise-sdlc://catalog/manifest, enterprise-sdlc://agents/{id}, and enterprise-sdlc://skills/{id}.
MCP has no concept of hooks — a server can't register lifecycle interceptors the way it registers tools/prompts/resources (see .cursor/hooks.json for what Cursor's hooks actually are: local, beforeShellExecution/afterFileEdit/etc.-triggered scripts, distributed via version control, MDM, or an Enterprise team dashboard — never via MCP).
This repo ships one project-level hook, in .cursor/hooks.json (and mirrored into templates/new-project/.cursor/): beforeShellExecution flags gh pr merge and asks for confirmation that the required independent review (get_agent("code-reviewer") + get_skill("pr-code-review")) actually happened, since that step is otherwise only enforced by whoever remembers to read AGENTS.md/this README. It's a reminder, not a hard block — it can't verify the review actually ran, only ask.
That's deliberately the only hook shipped here. Broader safety hooks (destructive-git guard, dangerous-shell-command guard, secret-staging guard) are a good idea but belong at the user level (~/.cursor/hooks.json), not per-project — they're personal safety nets that should apply across every repo you touch, not something each consuming project should have to opt into separately.
pip install -e ".[dev]"
ruff check .
pytestClosed a coverage gap found while onboarding the first graph/Graph-RAG consuming project: nothing in the catalog reviewed property-graph data modeling or graph-native retrieval, even though postgresql-schema-review/dynamodb-data-model-review cover the equivalent for their stacks.
Added knowledge-graph-modeling-review — entity/relationship minimality, no persisted derivable relationships (the graph-modeling analogue of avoiding redundant columns), natural-key identity strategy, provenance fields, and cardinality/directionality documentation. Used by Solution Architect; tagged graph.
Added graph-rag-retrieval-review — traversal depth/fan-out bounds, citeable retrieved-path identifiers, validation of dynamically generated queries (e.g. text-to-Cypher) before execution, and a hard rule that generated answers only assert relationships actually present in the retrieved subgraph. Complements (does not replace) rag-retrieval-design-review, the same way fastapi-service-review complements api-contract-review. Used by Solution Architect; tagged graph-rag.
Added the graph and graph-rag applies_when tags to the catalog tag table.
No new agent added — both gaps are checklists for the existing Solution Architect role, not a missing role.
Added the first Cursor hook to this repo, after establishing (see "Hooks" section above) that MCP and hooks are separate mechanisms — a catalog server can't push hook definitions to a client, so this had to ship as an actual .cursor/hooks.json, not new MCP server code.
Added .cursor/hooks.json + .cursor/hooks/pr_merge_gate.py: a beforeShellExecution hook that asks for confirmation before gh pr merge runs, reminding whoever's merging that the independent-review requirement (get_agent("code-reviewer") + get_skill("pr-code-review")) should already be satisfied. Mirrored into templates/new-project/.cursor/ so new consuming repos get it for free.
Added tests/test_hooks.py, which runs both copies of the hook script as real subprocesses (matching Cursor's own JSON-over-stdin/stdout contract) and checks hooks.json points at a script that actually exists.
Also fixed two blank-rendering list items introduced in the 0.6.0 scaffold docs (an ordered/bulleted list item whose entire content was an HTML comment rendered as an empty list marker on GitHub) in AGENTS.md, PROJECT_CHARTER.md, and AI_ORCHESTRATOR_BRIEF.md.
Closed the "new project scaffolding" gap: nothing previously codified how a brand-new consuming repo's folder structure should look, so validate_manifest could report a manifest as fully valid while every docs.* path it declared pointed at a file that was never created.
Added templates/new-project/ — a starter kit a new repo copies in wholesale: a filled-out sdlc.project.yaml (core keys pre-filled, conditional keys commented out with guidance), AGENTS.md, .cursor/mcp.json, the docs/00_project–docs/03_operations skeleton (one starter file per core docs.* key, plus an ADR convention note under docs/01_architecture/DECISIONS/), a .skills/ project-overlay stub, and .github/ templates (PR template, story/feature_task/bug_report issue templates matching the github-backlog-creation skill's Story→Task hierarchy, and a ruff+pytest CI workflow).
This codifies, rather than invents, the convention: it matches the folder structure support-ticket-triage-assistant and supportrouter-aws already converged on by hand — the difference is a third project no longer has to reverse-engineer it from an existing consumer.
Added tests/test_new_project_template.py, which fails CI if the shipped template ever drifts from manifest_keys.yaml's core key contract, or if a docs.* path in the template manifest stops pointing at a real file in the scaffold.
Updated the "Installing into a consuming project" section to point brand-new projects at the scaffold before the manual first-time-setup steps.
Addressed external review feedback on the two highest-priority remaining gaps: the core PR review skill had no actual review rigor, and code-modify permissions existed only as prose.
Rewrote pr-code-review.md from a 6-item process-compliance checklist into a substantive correctness review: a Blocker/Major/Minor severity model, a mandatory evidence rule (cite file+line, quote the offending code — an unsupported claim isn't a finding), a correctness checklist (edge cases, error handling, concurrency, resource cleanup, external-call failure handling), and an explicit ## Output Format with an always-rendered "None." path so a clean PR is stated as a real outcome, not implied by silence. The prior process checklist is retained as its own section.
Updated code-reviewer.md's Outputs/Allowed Actions to match: findings are severity-tagged with cited evidence, and a verdict (Approve/Request Changes) is always explicit.
Added a structured permissions block (code_modify: none/scoped/conditional, plus a write_paths allowlist) to every agent in manifest.yaml, alongside — not replacing — each agent's existing prose "Code-Modify Permission" section. list_agents() now returns it, and can resolve write_paths against a real project manifest when one is passed in, so a CI gate or pre-merge hook can allowlist a PR's changed files against what the authoring role is actually meant to touch.
Added test_every_agent_declares_well_formed_permissions to tests/test_catalog_consistency.py, enforcing the code_modify/write_paths shape (e.g. none must have an empty allowlist; scoped/conditional must have a non-empty one).
Deliberately did not extend the severity/evidence/output-format convention to the other 15+ review-style skills yet — scoped to the flagged highest-priority file for now; worth revisiting as a separate pass.
Rounds out the tightening roadmap's P2 items plus the two previously-unscheduled gap items.
Added dependency-upgrade-agent — a 9th agent role that plans and executes dependency/runtime version upgrades as their own isolated, tracked workflow (distinct from refactor-reviewer, which is structure-focused, and from dependency-supply-chain-review, which is a review checklist rather than an execution role).
Added incident-postmortem-review (blameless postmortems, root cause vs. contributing factors, tracked follow-ups), frontend-accessibility-review (keyboard operability, alt text, contrast, screen-reader-perceivable state), and cloud-infra-review (a vendor-neutral infra baseline above the AWS-only cdk-stack-review, which is now also tagged infra).
Added a validate_manifest tool that reports which core/conditional {{project.*}} keys a project's own manifest is missing, instead of only discovering the gap when a placeholder leaks into a live prompt.
Added a generic launch_role prompt (agent id + comma-separated skill ids + free-text context) so new agent/skill pairings don't require new hardcoded prompt functions in server.py. The two existing convenience prompts are unchanged.
Added tests/test_catalog_consistency.py, which fails CI if a skill's manifest.yaml used_by list and its own markdown "Used by:" line ever drift apart, or if used_by references an agent id that doesn't exist.
Added frontend and infra applies_when tags.
Added ROLLOUT.md — a version-agnostic checklist for upgrading a consuming repo's enterprise-sdlc-mcp install (or onboarding a new one), since that step had never been written down anywhere before now.
Closed the biggest coverage gaps identified in the tightening review — areas relevant to virtually any consuming project, unlike the AWS/LLM-specific skills already in the catalog.
Added application-security-review — cloud/stack-agnostic secrets, input validation, authn/authz, and error-leakage checklist (complements the AWS-only iam-least-privilege-review / bedrock-guardrails-review).
Added dependency-supply-chain-review — lockfile pinning, CVE triage, license compliance, and Dependabot/Renovate PR review. No skill covered this before.
Added cicd-pipeline-review — vendor-neutral pipeline health checklist (required checks, secrets in CI, caching, flaky-check handling), independent of cdk-stack-review's AWS-only infra focus.
Added api-contract-review — a generic REST/GraphQL contract checklist decoupled from any framework; fastapi-service-review is now tagged as its FastAPI-specific complement (applies_when: [fastapi, api]).
All four are used by the existing Solution Architect and Code Reviewer agents (plus Release Manager for cicd-pipeline-review) — no new agent role was added.
Added the api applies_when tag for skills that only apply when a project exposes an API surface.
A tightening pass focused on keeping the catalog genuinely reusable across unrelated projects, not just its two current consumers. No agent/skill ids, file paths, or manifest keys were removed or renamed — existing consuming repos are unaffected by upgrading.
Removed origin-project-specific details (support-ticket-triage domain language, hardcoded ADR-004/ADR-005 references) from dynamodb-data-model-review, iam-least-privilege-review, eval-scenario-design, architecture-review, synthetic-data-design, observability-dashboard-review, bedrock-guardrails-review, cdk-stack-review, llm-as-judge-rubric-design, and prompt-caching-review so they read as genuinely generic (or genuinely generic-to-their-stack) guidance instead of one project's architecture presented as a universal rule.
Genericized "Main Orchestrator" — previously an undefined, assumed-to-exist actor referenced across 7 agent/skill files — to "the coordinating agent (or human driving the session)".
Added an applies_when tag to every skill in manifest.yaml (always, or a stack tag like aws / dynamodb / bedrock / langgraph / rag / fastapi / postgresql / llm-product), now returned by list_skills().
Documented the full {{project.*}} placeholder contract in catalog/manifest_keys.yaml (required vs. conditional keys, and which skill needs each conditional one).
Expanded tests/fixtures/sdlc.project.yaml to define every documented key, and added tests/test_manifest_keys.py, which fails CI if a catalog file ever references an undocumented placeholder or if any catalog file fails to resolve cleanly against the fixture manifest.
MIT — see LICENSE.
Return resolved agent role markdown for the given project manifest.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| manifest_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It hints at processing with 'resolved' but does not disclose side effects, permissions, error behavior, or the optional manifest_path behavior. There is no contradiction with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundant wording, efficiently conveying the core action and result. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about what 'resolved' means, the relationship between agent_id and manifest_path, and when to use this tool. The output schema covers return structure, but key selection and behavioral information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain either parameter. While the schema defines agent_id as required and manifest_path as optional, the description's reference to 'given project manifest' is ambiguous relative to optional manifest_path. No additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies the resource ('resolved agent role markdown') and context ('for the given project manifest'). This distinguishes it from sibling listing tools like list_agents, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as list_agents or get_project_manifest. The description only states what it returns, not the circumstances for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return parsed project manifest used for placeholder resolution.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not state whether the operation is read-only, what happens if the manifest path is invalid, or whether side effects exist. The word 'Return' suggests safety but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence efficiently conveys the tool's purpose, with the verb and resource front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain the optional parameter's behavior or any error handling, making it incomplete for an agent to invoke the tool correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. However, it does not mention the 'manifest_path' parameter, what it controls, or what happens when it is null. The parameter name is somewhat self-explanatory, but the description adds no meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a parsed project manifest used for placeholder resolution. This is a specific verb+resource and naturally distinguishes from sibling tools that focus on agents, skills, and project skills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives. It implies a purpose (placeholder resolution) but lacks any statement of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a project-local overlay skill (domain-specific checklists).
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_path | No | ||
| skill_filename | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The 'Read' verb clearly signals a non-mutating operation, but it does not disclose behavior on missing files, whether the overlay merges with global skills, or error conditions. It is minimal yet acceptable for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action verb, with no redundant or extraneous content. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and an output schema exists, the description is incomplete for invocation because it does not explain the parameters at all, especially manifest_path. This leaves a critical gap in the agent's ability to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero semantic support for the parameters (skill_filename, manifest_path). It mentions neither parameter nor hints at their roles, so the agent cannot infer meaning beyond the property names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('project-local overlay skill') with a clarifying parenthetical about domain-specific checklists. The 'project-local' qualifier distinguishes it from sibling get_skill, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for project-local skills, but it does not explicitly contrast with get_skill or provide when-not-to-use guidance. It lacks direct alternatives or exclusions, though the intent is inferable from the naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return resolved skill checklist markdown for the given project manifest.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | ||
| manifest_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only states the return value and offers no insight into side effects, error conditions, permissions, or the meaning of 'resolved'. As a read operation, it fails to explicitly state that it is non-mutating or what inputs affect the resolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the action and object. It contains no filler or redundancy, and all words contribute to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists and covers return value structure, the description lacks essential context about how the skill_id and manifest_path interact, what resolution entails, and when to choose this over the many sibling tools. The tool is simple, but the description leaves notable gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain either parameter. 'skill_id' is never mentioned, and 'manifest_path' is only alluded to via 'for the given project manifest'. The description fails to compensate for the schema's lack of documentation, leaving the agent to infer parameter purposes from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies the resource ('resolved skill checklist markdown') and context ('for the given project manifest'). This makes the tool's purpose clear and distinguishes it from siblings like list_skills or get_project_manifest, though it doesn't explicitly contrast with get_project_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not mention when to use this tool versus alternatives such as get_project_skill or list_project_skills, nor does it state any prerequisites or exclusions. The implied use case (need a resolved checklist) is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List enterprise catalog build-time agent roles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'List' clearly conveys a read-only operation, but no additional behavioral context such as return format, pagination, or authorization is disclosed. The description is minimal, providing only the basic action and resource.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is immediately understandable. It is front-loaded with the verb and resource, and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero parameters and an output schema available, the description is sufficient to understand the tool's purpose. The output schema covers return values, and the simple nature of the operation does not require extensive context. Minor gaps exist in usage guidance but that is addressed separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so there are no parameter details to clarify. The description adds context about the type of agents listed, which is meaningful. Baseline for 0 params is 4, and the description does not detract from that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'enterprise catalog build-time agent roles', distinguishing it from sibling tools like get_agent (singular) and list_skills (different resource). The scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all agent roles, but it does not explicitly mention when to use this tool versus alternatives such as get_agent for a specific agent. No when-not-to-use or alternative guidance is provided, leaving the guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List markdown skill filenames in the project overlay (.skills/ by default).
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does state that it lists filenames only (not contents) and indicates the default path, but it does not mention edge cases like missing manifests, recursion, or whether only .md files are returned. For a simple read-only list tool, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no filler. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and there is only one optional parameter, the description covers the core purpose and scope. However, it lacks explicit usage guidance relative to sibling tools and doesn't fully explain the manifest_path parameter, so it is not complete enough for seamless tool selection in a broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (manifest_path) with no description and 0% schema coverage. The description indirectly explains the default behavior of the parameter ('.skills/ by default') but does not explicitly state that manifest_path overrides this default. This adds some meaning but leaves the parameter's role implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('markdown skill filenames in the project overlay'), clearly distinguishing it from siblings like list_skills or get_skill by scoping to the project overlay. The default path (.skills/) adds helpful specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that this tool operates on the project overlay, which implies a distinction from global skill listing. However, it does not explicitly state when to use this over list_skills or when not to use it, and no alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List enterprise catalog SDLC skills/checklists.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It implies a read-only operation via 'List' but does not state whether it returns all items, supports pagination, or any side effects. This is minimal but not misleading, so a 2 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It contains no fluff or redundant information, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, straightforward list operation) and an output schema exists, so detailed return value explanation is unnecessary. The phrase 'enterprise catalog' provides essential scope context relative to sibling tools, making the description complete enough for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so there is no parameter information to add. Per the rubric, a baseline of 4 applies for tools with no parameters, as the description cannot add value beyond what the schema already communicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('List') and the resource ('enterprise catalog SDLC skills/checklists'). It distinguishes itself from sibling tools like list_project_skills by emphasizing 'enterprise catalog', indicating a global scope rather than project-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the phrase 'enterprise catalog' versus project-specific skills, but there is no explicit guidance on when to use this tool instead of alternatives like list_project_skills or get_skill. No when-to-use or when-not-to-use instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_agentget_project_manifestget_project_skillget_skilllist_agentslist_project_skillslist_skillsScored across 7 tools
Each tool targets a distinct resource (catalog agents, catalog skills, project skills, manifest), but list_skills vs list_project_skills and get_skill vs get_project_skill could be confused if descriptions are not read closely. The clear qualifiers reduce ambiguity.
All tools follow the consistent list_<plural>/get_<singular> pattern, with project-scoped variants prefixed by project_. This is a uniform, predictable naming convention.
7 tools is well-scoped for a read-only catalog server covering agents, skills, project overlays, and manifest resolution. No tool feels redundant or missing.
The tool surface covers the full lifecycle for this domain: listing and getting catalog agents, catalog skills, project-local skills, plus the manifest. No obvious dead ends for the server's stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
Roadmap, tasks, releases and user feedback your coding agent reads and writes over MCP.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
