MCP SDD Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v5.0.0
Disambiguation3/5
Most tools map to distinct SDD phases, but sdd-implement and sdd-spec-impl could be confused as both relate to implementation, and sdd-steering vs sdd-steering-custom have overlapping purposes. The descriptions help but boundaries are not always crisp.
Naming Consistency3/5
All tools share the 'sdd-' prefix, but the structure is mixed: some are verb-led (sdd-approve, sdd-validate-design), some are noun-led (sdd-requirements, sdd-status), and sdd-spec-impl uses an abbreviation, so the pattern is readable but inconsistent.
Tool Count3/5
16 tools is slightly above the ideal 3-15 range, and several are highly specialized (sdd-context-load, sdd-template-render) that may not be used in every workflow, making the set feel a bit heavy for the domain.
Completeness4/5
The surface covers the full SDD lifecycle from init to implementation, including requirements, design, tasks, validation, quality, and steering. Minor gaps exist such as no general artifact update/review tool beyond test cases, but core workflows are well supported.
Average 2.4/5 across 16 of 16 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on July 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for behavioral disclosure. It does not state whether the operation is read-only, what it computes, what side effects it might have, or what output to expect. 'Analyze the implementation gap' reveals no behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (5 words) but lacks substantive content. This is under-specification, not efficient conciseness; it omits critical information about purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In a multi-step SDD workflow with one parameter and no output schema, the description is the only source of context. It fails to explain what 'implementation gap' means, what the tool does, what it returns, or how it relates to the rest of the workflow. This is completely inadequate for an agent to decide when and how to use the tool.
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 schema fully documents the single parameter featureName with a clear pattern and description. Per the baseline rule for high schema coverage (100%), the description need not add parameter details. However, the description does not mention the parameter at all, so it adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analyze the implementation gap' uses a generic verb ('Analyze') and an undefined resource ('implementation gap'). It does not specify what a gap is, what analysis is done, or how this differs from sibling tools like sdd-validate-design.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool, what triggers its use, or how it fits into the workflow alongside sdd-validate-design, sdd-review-test-cases, or other siblings. The name hints at validation but no context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but 'Render an optional SDD scaffold' reveals nothing about side effects (e.g., file creation), permissions, rate limits, or whether it is read-only. Even its mutation impact is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It lacks essential details and does not effectively summarize what the tool does, making it low-value despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 3 parameters, no annotations, and no output schema, the description is far from complete. It provides no information about when to invoke the tool, what it produces, or how it behaves, making it inadequate for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only featureName has a description), and the tool description adds no parameter information. It fails to explain templateType or customTemplate, leaving a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Render' as the verb and identifies 'SDD scaffold' as the resource, but 'optional SDD scaffold' is ambiguous. It doesn't clarify what the scaffold is or how it differs from sibling tools like sdd-requirements or sdd-design, making the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, what prerequisites exist, or how it relates to alternatives. The word 'optional' implies it may not be required, but there is no explicit context, exclusions, or mention of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. 'Validate design artifact' does not indicate whether the operation is read-only, whether it modifies any state, what permissions are needed, or what output is returned. This is a serious omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is easy to read, but it sacrifices substance for brevity. It is under-specified rather than concise, providing no meaningful detail about the tool's behavior or scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description should have compensated by explaining the validation process, expected inputs, and outputs. It does none of this, making it inadequate for a tool that appears to be a workflow gate.
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 fully describes the only parameter, featureName, with a clear description and pattern, achieving 100% coverage. The description adds no parameter-specific information, but the schema already provides sufficient semantics, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Validate design artifact', which uses a verb and resource but is largely a restatement of the tool name 'sdd-validate-design'. It does not specify what validation entails, what a 'design artifact' is, or how it differs from sibling tools like sdd-validate-gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or how it fits into the SDD workflow. The sibling tool list suggests a sequence, but the description offers no context about prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral information. 'Submit' implies a write operation, but nothing is said about side effects, resource modifications, concurrency handling, or failure modes. Key behavioral details like optimistic concurrency (expectedRevision) and integrity checks (expectedArtifactSha256) are entirely omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short phrase, which is concise in length but severely under-specified. It lacks a complete sentence structure and fails to convey any meaningful detail. This is under-specification, not effective conciseness, as no value is packed into the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool operates within a larger SDD workflow, but the description gives no context about the design lifecycle, where this submission fits, or what input is expected. With four required parameters, no output schema, and no annotations, the description is grossly inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only featureName has a description), so the description must compensate for the other parameters, but it doesn't. It provides no explanation of what 'content' should contain, the meaning of 'expectedRevision', or the purpose of 'expectedArtifactSha256'. Without this information, an agent cannot correctly construct a submission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Submit') and resource ('design artifact'), which gives a basic idea of the operation. However, it doesn't clearly define what a design artifact is or how this tool differs from sibling tools like sdd-validate-design, which also deals with design. The lack of scope and sibling differentiation makes the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., running sdd-init or sdd-requirements first), nor does it indicate when validation or approval steps are needed. The description provides no usage context whatsoever.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, permissions, and reversibility, but it does not. 'Submit' implies a write operation, but no further behavioral details are given, such as whether it creates, updates, or executes tasks, or what happens on submission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of four words, which is concise but under-specified. It does not provide enough information for the agent to understand the tool's purpose or usage, making it more of an under-specification than a well-structured concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 required parameters, no output schema, and no annotations. The brief description is wholly inadequate to guide correct invocation, especially given the lack of sibling differentiation and the absence of any behavioral or parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only featureName is described), and the description mentions no parameters. It fails to compensate for the missing parameter documentation, leaving the agent with no additional meaning for content, expectedRevision, expectedArtifactSha256, or reviewTestCases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Submit' and a resource 'implementation tasks artifact', but the resource is ambiguous and does not distinguish this tool from siblings like sdd-implement. It lacks clarity on what the artifact actually contains or how it relates to implementation tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It is a single imperative sentence with no context, prerequisites, or exclusions, leaving the agent to guess when this should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It only says 'Record review' without explaining side effects, required permissions, error behavior, or what happens after recording. The lack of detail is a significant gap for a tool that likely mutates state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just one short sentence, but it is under-specified rather than effectively concise. It lacks structure and fails to convey critical details, making it more of a placeholder than a useful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and three parameters, a brief description is inadequate. The tool appears to record a review outcome, but the description does not explain the inputs, outputs, or workflow context, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only featureName has a description). The description does not mention any parameters, failing to clarify the meaning or format of expectedTasksRevision and expectedArtifactSha256. It adds no value beyond the schema and does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states an action ('Record review') and a target ('tasks revision'), but it is vague about what recording a review entails and does not distinguish this tool from siblings like sdd-quality-check or sdd-approve. The phrase 'exact tasks revision' is ambiguous, leaving room for interpretation about the tool's precise role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling tools in the SDD workflow. The description does not mention any prerequisites, alternatives, or exclusion cases, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits, but it only states 'Load phase-aware governed context.' It does not describe whether the operation is read-only, whether it requires prior initialization, what 'governed' means in terms of permissions or data handling, or what the tool actually returns. This is insufficient for a tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short phrase and is concise, but it is under-specified. It is not tautological, but it reads more like a title than a useful explanation. Every word is used, but the content is too thin to earn full marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, this description is completely inadequate. It does not explain return values, side effects, parameter behavior, or how the tool fits into a workflow. An agent would have to guess or rely solely on the schema, which itself lacks descriptions for most parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only featureName has a description). The description itself mentions no parameters. While the schema provides enum values for mode and phase, it lacks descriptions for those enums and the remaining parameters like ifNoneMatch, includeUnapproved, and maxEstimatedTokens. The description does nothing to compensate for this low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Load phase-aware governed context' uses the verb 'Load' and identifies a resource ('context'), but 'phase-aware governed' is vague jargon. It does not clearly distinguish this from sibling tools like sdd-requirements or sdd-init, which might also load specific context. It states a clear action but lacks the specificity needed to fully understand what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where another sibling tool would be more appropriate. The agent is left without any usage context beyond the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It says 'Initialize' but does not disclose what initialization entails (e.g., creating files, validating, requiring auth, side effects). This lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but this is under-specification rather than effective conciseness. It omits essential information while providing no structure or detail that would help an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, a nested object, and no output schema, yet the description provides almost no context. Given the complexity and lack of annotations, the description is far from complete to support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the tool description adds no parameter guidance. The schema only documents featureName; other parameters like clarificationAnswers and language lack meaningful descriptions. The description does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Initialize' and names a resource 'governed SDD feature', which is clear about the action and target. However, it does not distinguish this from sibling tools like sdd-requirements or sdd-design, and 'governed SDD feature' is somewhat vague without elaboration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context such as prerequisites, workflow position, or situations where this tool is appropriate, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description is the only source of behavioral information. It does not disclose whether the tool is read-only, what it returns, or any side effects, leaving the agent with no safety or outcome expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. It is front-loaded with the primary purpose, though it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and minimal description, the tool is severely under-specified. The agent cannot know expected outputs, behavior, or how to integrate this into the SDLC workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters with 0% schema description coverage. The description does not mention 'code' or 'language', so the agent receives no semantic guidance beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'perform' with the resource 'code quality analysis', clearly indicating an analysis action on code. However, it is vague about what kind of analysis and does not differentiate it from sibling validation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context about when to use this tool versus siblings like sdd-validate-design or sdd-review-test-cases. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only restates the creation action and offers no information about side effects, file system changes, overwrite behavior, or relationship to other sdd tools. This is insufficient for a tool that appears to generate artifacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is technically efficient, but it is under-specified rather than concise. A tool with four parameters and custom behavior needs more than a purpose statement to be useful, so the brevity is not appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, annotations, and parameter descriptions, the single-sentence description is far from complete. It fails to address the tool's input requirements, behavior, or expected outputs, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for four parameters (topic, fileName, filePattern, inclusionMode), and the description does not compensate by explaining any parameter meanings or relationships. The agent must rely solely on parameter names and the enum for inclusionMode, which is inadequate.
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 'Create a custom steering document' uses a specific verb ('Create') and resource ('custom steering document'), clearly distinguishing it from the sibling tool 'sdd-steering' which likely handles standard steering documents. The word 'custom' is a meaningful qualifier that sets it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'sdd-steering'. The description does not mention prerequisites, conditions, or scenarios where a custom steering document would be needed, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavior. 'Submit requirements artifact' implies a write operation but does not explain side effects, validation, conflict handling, or reversibility, which is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no unnecessary words, making it efficient. However, its extreme brevity borders on under-specification, but as a statement of purpose it is structurally sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 required parameters, no annotations, and no output schema, the description is wholly inadequate. It does not explain the artifact's purpose, the meaning of revision and checksum, or what outcome the agent should expect, making the tool invocation risky and unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description does not mention any parameter (featureName, content, expectedRevision, expectedArtifactSha256) or their semantics. The description fails to compensate for the low schema coverage, leaving the agent without understanding the parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Submit' and a resource 'requirements artifact', which clearly indicates the tool's function. It is distinguishable from sibling tools by its focus on requirements, but it does not explicitly differentiate from siblings or provide scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. It only states 'Begin implementation of approved tasks' without explaining side effects, required permissions, file modifications, or any operational consequences. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in length (one sentence) and front-loaded, but it is under-specified rather than efficiently minimal. It conveys only a vague action without enough detail to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low parametric complexity, but no output schema and no annotations. The description is too sparse for an implementation tool; it does not state what 'begin implementation' entails, what artifacts are produced, or how to verify completion.
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?
Schema description coverage is 100% for the single parameter featureName, which is already described as 'Feature name under .spec/specs'. The main description adds no further meaning to the parameter, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Begin implementation') and a resource ('approved tasks'), which conveys the core purpose. However, it does not distinguish from sibling tools like sdd-spec-impl, which may also involve implementation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, prerequisites, or expected workflow steps. The phrase 'approved tasks' implies a dependency on prior approval but gives no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'record progress' and fails to mention side effects, revision-checking behavior via expectedRevision, evidence requirements for certain actions, or potential error conditions. The description gives no detail about what happens when the tool is invoked, making it insufficient for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no wasted words. However, given the tool's complexity (7 parameters, nested objects, conditional requirements), this length is under-sized and not appropriately informative for the task of selecting and invoking the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex schema, no annotations, and no output schema. The description omits essential context such as the meaning of action values, the evidence object's purpose, expectedRevision semantics, and where this tool fits in the SDD workflow. It is far from complete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only featureName has a description), and the tool description adds no parameter information. While the schema's action enum and property names are somewhat self-explanatory, the description does not clarify evidence, expectedRevision, blocker, or affectedArtifacts. The agent must rely solely on the schema, which lacks semantic richness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as recording progress on implementation tasks, with 'record' as a specific verb and 'governed implementation task progress' as the resource. It is distinguishable from siblings like sdd-implement and sdd-status, though it does not mention the specific action types (start, record-red, record-green, complete, block) defined in the schema, leaving 'governed' somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as sdd-implement, sdd-tasks, or sdd-status. It does not include any context about the SDD workflow, prerequisites, or situations that warrant recording red/green/complete/block actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing effects. It states create or update but does not describe what happens to existing documents, whether content is overwritten, required permissions, or any side effects.
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 a single sentence that is extremely concise and front-loaded. Every word is purposeful, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema and no output schema, but the description is too sparse for a mutation tool. It lacks context about what a steering document is, how updateMode changes behavior, and the implications of the operation, especially given zero annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no explanation of the updateMode parameter. The enum values create and update are self-evident in the schema, but the description does not clarify how the parameter affects behavior or whether a missing parameter defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create or update project steering documents' includes a clear specific verb and resource. It is easy to understand the core function, though it does not differentiate from sibling tools like sdd-steering-custom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention prerequisites, exclusions, or compare with sdd-steering-custom or other related SDD tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavior. It only says 'Approve' which implies a mutation but does not explain the validation mechanism, what happens if the expected revision or artifact SHA does not match, or any side effects. There is no mention of safety, reversibility, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, which is concise, but it is under-specified for a tool with four required parameters. It does not waste words, but it also fails to convey essential usage details, making it borderline adequate in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters, no output schema, and no annotations, yet the description provides no information about return values, preconditions, or postconditions. It does not explain what constitutes a valid revision or how the approval process works, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only featureName has a description), and the tool description does not compensate. It mentions 'exact' but does not explain that expectedRevision and expectedArtifactSha256 are used for exact matching. The description adds no meaning beyond the schema's basic field list.
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 clearly states the action ('Approve') and the object ('an exact validated phase revision'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools like validation or status checks by indicating it is the approval step for phase revisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a phase revision has been validated and needs approval, but it does not explicitly state when to use it versus alternatives like sdd-validate-design or sdd-status. There are no exclusions or alternative tool guidance, though the context of 'validated' hints at a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Get' and 'list' imply a read-only operation, which is helpful, but the description does not explicitly state that it is non-destructive, nor does it describe the output format or behavior when the featureName doesn't exist. It adds some transparency but leaves gaps.
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 a single, concise sentence with no filler. It is front-loaded with the action and immediately conveys both modes of operation, earning a perfect score for brevity and clarity.
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?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the main usage. However, it is slightly ambiguous whether 'list all features' returns full statuses or just feature names, and there's no mention of return details. Still, it is mostly complete for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is well-formed, but the description adds crucial semantics: providing featureName retrieves one status, omitting it lists all features. This clarifies the conditional behavior beyond what the schema alone conveys.
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 'Get one feature status or list all features' uses specific verbs (get/list) and clearly identifies the resource (feature status). It distinguishes between two modes of operation and stands apart from sibling tools like sdd-requirements or sdd-implement, which focus on other phases.
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 clearly implies when to use it: to retrieve status for a single feature or all features. It doesn't explicitly mention alternatives or exclusions, but the context is unambiguous enough for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sdd-mcp MCP server](https://glama.ai/mcp/servers/yi-john-huang/sdd-mcp/badges/card.svg)](https://glama.ai/mcp/servers/yi-john-huang/sdd-mcp)

Score Badge

Copy to your README.md:

[![sdd-mcp MCP server](https://glama.ai/mcp/servers/yi-john-huang/sdd-mcp/badges/score.svg)](https://glama.ai/mcp/servers/yi-john-huang/sdd-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yi-john-huang/sdd-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server