Spec Driver MCP is a Model Context Protocol server that enables structured, spec-driven AI development by guiding projects through a 3-phase workflow (Requirements → Design → Tasks) with approval gates and automation hooks.
Initialize a spec workspace (init-spec): Set up a .spec/ directory with config, default hooks, and support for feature or bugfix spec types using requirements-first or design-first workflows.
Write spec documents (write-spec-file): Create or update the three core spec files:
requirements.md — User stories and acceptance criteria
design.md — Architecture, components, and data flow
tasks.md — Trackable checkbox task lists
Read spec documents (read-spec-file): Retrieve the current content of any core spec file.
List spec files (list-spec-files): View the status of all spec files, including existence, size, task counts, and associated hooks.
Track task progress (update-task): Mark individual tasks as completed [x] or pending [ ] in tasks.md, identified by line number or partial text match.
Get task summary (get-task-summary): Retrieve overall task completion statistics (completed vs. total tasks).
Create automation hooks (create-hook): Register event-driven rules that instruct the AI to automatically perform actions when specific workflow events occur (e.g., auto-mark tasks, validate phase transitions, sync docs on requirement changes).
List hooks (list-hooks): View all registered automation hooks, their trigger events, and descriptions.
Delete hooks (delete-hook): Remove a specific automation hook by name.
Run hooks (run-hooks): Execute all hooks associated with a specific event (e.g., on-task-completed, on-spec-phase-change), enabling automated workflow enforcement at key development milestones.
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., "@spec-driver-mcp analyze my project and create a spec"
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.
A Model Context Protocol server that brings Kiro-style spec-driven development to any AI coding tool (Claude Code, Cursor, opencode, Codex CLI, Reasonix, Gemini CLI, and more).
Replaces unstructured chat with a 3-phase workflow when you ask AI to build, plan, or refactor a project:
Phase 1: Requirements → requirements.md (EARS format: WHEN...THE SYSTEM SHALL...)
Phase 2: Design → design.md (architecture, components, data flow)
Phase 3: Tasks → tasks.md (trackable [x] checkboxes)Each phase requires your approval before advancing. Hooks auto-maintain consistency.
Related MCP server: Pathfinder MCP Server
npx github:linanwanttodo/spec-driver-mcpOr install globally:
npm install -g github:linanwanttodo/spec-driver-mcpAdd to ~/.config/opencode/opencode.json:
{
"mcp": {
"spec-driver": {
"type": "local",
"command": ["npx", "github:linanwanttodo/spec-driver-mcp"]
}
}
}Add to ~/.claude/settings.json:
{
"mcpServers": {
"spec-driver": {
"command": "npx",
"args": ["github:linanwanttodo/spec-driver-mcp"]
}
}
}Then copy instructions/CLAUDE.md to your project root as CLAUDE.md.
Create .cursor/mcp.json in your project:
{
"mcpServers": {
"spec-driver": {
"command": "npx",
"args": ["github:linanwanttodo/spec-driver-mcp"]
}
}
}Then copy instructions/cursor-rules.md to your project root as .cursorrules.
Add to ~/.codex/config.toml:
[mcp_servers.spec-driver]
command = "npx"
args = ["github:linanwanttodo/spec-driver-mcp"]Add to ~/.reasonix/config.json mcp array:
"spec-driver=npx github:linanwanttodo/spec-driver-mcp"Add to ~/.gemini/config/mcp_config.json:
{
"mcpServers": {
"spec-driver": {
"command": "npx",
"args": ["github:linanwanttodo/spec-driver-mcp"]
}
}
}Once configured, just tell your AI:
"帮我开发一个博客系统" or "帮我分析这个项目" or "我们来重构这个"
The AI will automatically:
Read your codebase to understand context
Ask you clarifying questions (requirements-first or design-first? specific details?)
Write requirements.md using EARS notation
Wait for your approval before proceeding
Write design.md with architecture and component design
Wait for your approval
Write tasks.md with - [ ] checkboxes
Wait for your approval, then implement
During implementation:
- [x] Task completed via update-task
- [ ] Still pendingThe AI auto-runs hooks at each event:
on-task-completed → auto-mark task [x], check acceptance criteria
on-spec-phase-change → validate document completeness
on-user-request-change → sync all documents
Tool | Description |
| Initialize .spec/ with config + 3 default hooks |
| Write requirements.md / design.md / tasks.md |
| Read any spec file |
| Show file status + hooks |
| Toggle task [x] or [ ] |
| Task completion stats |
| Create automation rules |
| List all hooks |
| Remove a hook |
| Execute hooks for an event |
All files are created in .spec/ at your project root:
your-project/
├── .spec/
│ ├── .config # Project metadata
│ ├── requirements.md # Phase 1: Requirements
│ ├── design.md # Phase 2: Design
│ ├── tasks.md # Phase 3: Tasks
│ └── hooks/ # Automation rules
│ ├── auto-mark-completed.md
│ ├── validate-before-phase.md
│ └── notify-on-change.md
├── ...your code...Hook | Event | What it does |
|
| Auto update-task after implementation |
|
| Validate doc completeness before advancing |
|
| Sync all docs when requirements change |
If you're asking an AI to set this up for you, copy this:
Install spec-driver-mcp from GitHub and configure it:
1. Run: npm install -g github:linanwanttodo/spec-driver-mcp
2. Add "spec-driver" to the MCP servers config of my AI tool
(the config format depends on which tool I use)
3. Done - no server needed, no API keys, no registrationMIT
Register an automation hook for the spec workflow. Hooks define actions the AI should automatically perform when specific events occur. Events: on-requirements-confirmed, on-design-confirmed, on-tasks-confirmed, on-task-completed, on-implementation-done, on-spec-phase-change, on-user-request-change, manual
Example: when a task is completed (on-task-completed), auto-run update-task to mark it [x].
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique hook name (e.g. auto-mark-completed) | |
| event | Yes | Event that triggers this hook | |
| description | Yes | Short description of what this hook does | |
| instructions | Yes | Detailed instructions for the AI to execute when triggered |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the action (registration), events, and example; but lacks details on persistence or limits.
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?
Concise, front-loaded with purpose, followed by explanation, events list, and example; 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?
Provides necessary context for a registration tool, but could clarify manual event vs automatic, and return behavior.
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 100% and the description adds meaning by explaining each parameter, listing events, and providing an example.
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 verb 'Register' and resource 'automation hook', and distinguishes from siblings like delete-hook, list-hooks, run-hooks.
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 explains when to use (to automate actions on events) and provides examples, but does not explicitly contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a hook by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the hook to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It only states the action but omits whether deletion is irreversible, requires permissions, or has 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded. Efficient for a simple tool, though slightly under-specified for a deletion operation.
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 delete tool with no output schema, the description should mention irreversibility, dependencies, or error conditions. It lacks critical context needed for safe invocation.
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 100% with parameter description 'Name of the hook to delete'. The tool description adds no extra meaning beyond the schema, baseline score of 3 is appropriate.
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?
Description clearly states the action: 'Remove a hook by name.' It uses a specific verb (remove) and resource (hook), distinguishing it from siblings like create-hook and list-hooks.
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 on when to use this tool, prerequisites, or when not to use it. Missing context like whether the hook must exist or if deletion is permanent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of task completion status from tasks.md.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description implies a read-only operation but does not explicitly state behavioral traits like side effects or required permissions.
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?
Single sentence, front-loaded, no unnecessary 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?
For a parameterless tool, the description sufficiently explains input and function; output details are implied but not required.
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?
No parameters exist; the description adds value by specifying the data source (tasks.md), which is not captured in the empty 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 verb 'Get' and the resource 'summary of task completion status from tasks.md', which is distinct from sibling tools dealing with hooks and spec files.
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 on when to use this tool versus alternatives; no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a spec-driven development workspace for the current project. Creates a .spec/ directory that will hold three files:
requirements.md: User stories, acceptance criteria (EARS format)
design.md: Architecture, diagrams, implementation approach
tasks.md: Trackable checkbox tasks
hooks/: Event-driven automation rules
Call this FIRST when user expresses intent to build, plan, design, analyze, or refactor.
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Project or feature name | |
| specType | No | Type of spec (default: feature) | |
| workflowType | No | Workflow variant (default: requirements-first) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses creation of .spec/ directory and files, but does not mention idempotency, potential side effects, or what happens if called multiple times.
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?
Description is structured but somewhat verbose with file list. Could be more concise by noting file structure is standard and documented elsewhere.
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 no output schema, description adequately informs about created files and directory structure. Lacks details on success indicators or return value.
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 100%, so description adds no further meaning beyond schema. All parameters are already well-described in input 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?
Description clearly states the tool initializes a spec-driven workspace for the current project. It lists specific files and directories created, distinguishing it from siblings by indicating it should be called first when building, planning, etc.
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?
Explicitly states 'Call this FIRST when user expresses intent to build, plan, design, analyze, or refactor.' This provides clear when-to-use guidance. However, it does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered hooks with their event type and description. Use this to review what automations are active.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes the tool as listing data, implying read-only behavior, but does not explicitly state that it is non-destructive or discuss potential limits like pagination. Adequate for a simple read operation.
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 two short sentences, front-loaded with the primary purpose, and contains no waste. Every sentence adds value.
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 no parameters and no output schema, the description adequately explains what is listed and why. It could mention return format or ordering, but the information provided is sufficient for selection.
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 input schema has no parameters, so schema description coverage is trivially 100%. The description adds value by specifying the returned fields (event type, description), which is meaningful beyond the empty 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 that the tool lists all registered hooks with event type and description, which is a specific verb-resource pairing. It distinguishes from siblings like create-hook and delete-hook by focusing on listing.
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 provides a clear usage context: 'Use this to review what automations are active.' It does not include explicit when-not-to-use or alternatives, but the tool is simple and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all spec files with their status (exists, size, task count).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states it lists files with status, but does not mention that it is read-only, or any side effects, authentication needs, or performance implications. The description is minimal.
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 short sentence that concisely conveys the purpose and key output fields, with no unnecessary 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?
The description covers the basic purpose and output fields, but given no output schema, it could specify the return format (e.g., a list of objects) or any ordering. It is minimally adequate for a zero-parameter tool.
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, so the baseline is 4. The description adds no parameter info, but none is needed.
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 verb 'List' and the resource 'spec files', and mentions the status fields included. However, it does not explicitly differentiate from sibling tools like read-spec-file, but the resource and action are distinct enough.
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 vs alternatives (e.g., read-spec-file or get-task-summary). The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the content of one of the three spec files. Use this to review requirements, check design decisions, or see task status.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavior. It implies a non-destructive read operation, but does not disclose the return format (e.g., raw text, markdown) or any potential side effects. For a simple read tool, this is adequate but lacks detail.
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?
Two concise sentences with the verb and resource front-loaded. No wasted words; every sentence adds value.
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 tool's simplicity (single parameter, no output schema), the description covers the core purpose and usage context. It slightly overlaps with sibling get-task-summary in 'see task status', but overall is adequate. Missing output details reduce completeness slightly.
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%, so the description does not add meaning beyond the schema. However, the single enum parameter 'file' is self-explanatory with values 'requirements.md', 'design.md', 'tasks.md'. The description could have briefly explained the purpose of each file, but it's not critical.
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 it reads the content of spec files and provides specific use cases (review requirements, check design decisions, see task status). However, it does not differentiate from sibling tools like get-task-summary, which also relates to task status.
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 explicitly mentions when to use the tool (review requirements, check design decisions, see task status). It does not provide when-not-to-use guidance or mention alternatives like write-spec-file for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all hooks matching a specific event type. The AI should call this when an event occurs and execute the matching hooks' instructions. For example, after completing implementation of a task, call run-hooks with event "on-task-completed" to find and execute all relevant hooks.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | The event that just occurred |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently reveals that the tool both retrieves and executes hooks: 'get all hooks' and 'execute the matching hooks' instructions.' No annotations are provided, so the description carries the full burden. It clearly conveys the dual nature, but could further detail what execution entails (e.g., 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with no wasted words. The first sentence states the purpose, the second gives usage guidance, and the third provides a concrete example. It is well-structured and efficient.
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 has one parameter, no output schema, and no annotations. The description explains what it does and when to use it, but does not describe the return format or the nature of hook execution. For a tool that also performs actions, more details about execution behavior would improve completeness.
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 input schema covers 100% of parameters with a description and an enum. The description adds an example event ('on-task-completed'), but this does not significantly add meaning beyond the schema. Per guidelines, with high schema coverage, baseline is 3, which is appropriate.
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 'Get all hooks matching a specific event type,' using a specific verb and resource. It distinguishes itself from sibling tools like create-hook, delete-hook, and list-hooks by focusing on matching events and executing hooks.
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 explicitly states when to call the tool: 'The AI should call this when an event occurs and execute the matching hooks' instructions.' It provides a concrete example with the event 'on-task-completed.' However, it does not explicitly mention when not to use it or alternatives, but the example and sibling list provide sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a task as done or pending in tasks.md. Use this during implementation to track progress. The task is identified by matching its text content (case-insensitive partial match).
| Name | Required | Description | Default |
|---|---|---|---|
| match | No | Text to match against task descriptions (partial, case-insensitive) | |
| done | Yes | true = [x], false = [ ] | |
| line | No | Exact line number (0-indexed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It discloses that tasks are identified via case-insensitive partial match and that the tool modifies the file (marks as done/pending). However, it does not detail error handling, required permissions, or side effects beyond the stated modification.
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?
Three sentences, each with a clear role: stating the purpose, giving usage context, and explaining identification. No redundant words. Front-loaded with the core action.
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 no output schema and no annotations, the description covers the essential aspects: what it does, when to use it, and how parameters identify tasks. It could mention what happens on no match or multiple matches, but for a simple utility this is generally sufficient.
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 100%, so the schema already describes all parameters. The description adds context: 'match' is partial and case-insensitive, 'done' corresponds to checkbox syntax. This adds some value, but not significant depth 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 verb 'Mark' and the resource 'task' in 'tasks.md', with specific outcomes 'done or pending'. This distinguishes it from siblings like get-task-summary (reading) and hook tools (hooks management).
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 provides when to use the tool: 'during implementation to track progress'. It does not explicitly mention when not to use or alternatives, but the context signal shows siblings like get-task-summary for reading, which implies this tool is for writing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write content to one of the three spec files. Use this to create or update requirements.md, design.md, or tasks.md.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| content | Yes | Full markdown content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes write operation but does not clarify whether it overwrites or appends, nor does it mention permission needs or side effects. 'Full markdown content' hints at overwrite but 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?
Two sentences, no extra words. First sentence states purpose, second gives usage guidance. Front-loaded and efficient.
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?
No output schema, so return value is not described. Tool is simple but lacks explanation of overwrite behavior or error handling. Adequate for a basic write tool but could be more complete with behavioral details.
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?
Two parameters with schema covering 50% (only 'content' has a description). Description reiterates the three files from the enum, adding minimal value beyond schema. Baseline score appropriate given parameter count and schema coverage.
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?
Description clearly states 'Write content to one of the three spec files', specifying the action (write), resource (spec files), and scope (three specific files). Distinguishes from sibling tools like read-spec-file and list-spec-files.
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?
Explicitly says 'Use this to create or update requirements.md, design.md, or tasks.md.', providing clear context for when to use. Lacks explicit 'when not to use' statement, but purpose is well-scoped.
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. Dates show when Glama detected each change.
v0.3.0create-hookdelete-hookget-task-summaryinit-speclist-hookslist-spec-filesread-spec-filerun-hooksupdate-taskwrite-spec-fileEach tool has a clearly distinct purpose: hooks management (create/delete/list/run), spec file operations (init/read/write/list), and task tracking (get-task-summary/update-task). No overlap or ambiguity.
All tool names follow a consistent pattern of verb-noun (or verb-object) using lowercase with hyphens, e.g., 'create-hook', 'init-spec', 'update-task'. No mixing of conventions.
With 10 tools, the set is well-scoped for a spec-driven development workflow. It covers every necessary operation without being excessive or insufficient.
The tool surface covers the full lifecycle: initialization, file management, task tracking, and automation hooks. No obvious missing operations for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
Design spec + milestones AI coding agents read before building; drift flagged, changes reviewed.
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
Adaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/linanwanttodo/spec-driver-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
