How do I use Functional Requirements MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Functional Requirements MCP Server Generate a user story for a password reset feature." 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.

Functional Requirements MCP Server

by xTr161

Overview Schema Source Related Servers Discussions Admin

Python

Local

Functional Requirements MCP Server

A Model Context Protocol (MCP) server that provides AI-powered prompts for generating user stories, requirements, technical specifications, and other software development documentation.

🎯 Overview

This MCP server offers a collection of specialized prompts designed to streamline the software development lifecycle by automating the creation of structured documentation. It focuses on functional requirements analysis and technical documentation generation.

Related MCP server: Spec Workflow MCP

✨ Features

Core Functionality

User Story Creation: Generate detailed user stories with proper formatting and structure
Requirements Generation: Convert user stories into functional and non-functional requirements
Technical Specifications: Transform requirements into detailed technical documentation
Meeting Documentation: Extract action items and decisions from meeting notes
Release Notes: Create professional release documentation
Architecture Decision Records (ADRs): Document technical decisions and rationale

Structured Data Models

UserStory Model: Comprehensive data structure with MoSCoW prioritization
Step-by-Step Processes: Support for normal and exceptional flow documentation
Actor Management: Track stakeholders and system users

🚀 Quick Start

Prerequisites

Python 3.13 or higher
uv package manager
Claude Desktop or compatible MCP client

Installation

Clone the repository:

git clone <repository-url>
cd Coding_MCP

Install dependencies:
```
uv sync
```

Configure Claude Desktop: Add this server configuration to your claude_desktop_config.json:

{
  "mcpServers": {
    "Functional Requirements": {
      "command": "C:\\Users\\<your-username>\\AppData\\Local\\Programs\\Python\\Python311\\Scripts\\uv.EXE",
      "args": [
        "run",
        "--with",
        "mcp[cli]",
        "mcp",
        "run",
        "C:\\Users\\<your-username>\\source\\repos\\Coding_MCP\\main.py"
      ]
    }
  }
}

Restart Claude Desktop to load the new server.

📖 Usage Guide

Available Prompts

1. Create User Story

Purpose: Generate structured user stories from contextual information.

Usage: Provide context about a feature or requirement, and the prompt will create a properly formatted user story following the "As a [actor], I want [feature] so that [benefit]" convention.

Output: JSON-structured user story with:

Unique identifier and name
Definition following user story conventions
Pre/post conditions
Actors involved
Normal and exceptional process flows
MoSCoW prioritization with explanation
Related requirements

2. Create Requirements

Purpose: Transform user stories into detailed functional and non-functional requirements.

Input: UserStory object Output: Comprehensive requirements covering:

Functional requirements (system capabilities)
Non-functional requirements (performance, security, usability)
Technical constraints and dependencies
Acceptance criteria for testing

3. Technical Specification Writer

Purpose: Convert requirements into detailed technical specifications.

Output Structure:

Overview and Scope
System Architecture
Detailed Design (APIs, data models, database design)
Implementation Details
Integration Points
Quality Attributes

4. Meeting Summary Generator

Purpose: Extract structured information from meeting notes.

Output Includes:

Key decisions made
Action items with owners and due dates
Discussion points and open questions
Next steps and dependencies
Parking lot items

5. Release Notes Creator

Purpose: Generate professional, user-facing release documentation.

Sections Include:

What's New (features and enhancements)
Improvements (performance, UX, developer experience)
Bug Fixes
Security Updates
Breaking Changes with migration guides
Technical details and acknowledgments

6. Architecture Decision Record (ADR)

Purpose: Document technical decisions with proper rationale.

Structure:

Status and decision makers
Context and problem statement
Options considered with pros/cons
Decision rationale
Implementation plan
Consequences and risks
Compliance considerations

🏗️ Project Structure

Coding_MCP/
├── main.py                 # MCP server with prompt definitions
├── pyproject.toml         # Project configuration and dependencies
├── uv.lock               # Dependency lock file
├── models/
│   ├── user_story.py     # UserStory and Step data models
│   └── requirements.py   # Requirements-related models
├── prompts/              # (Future: Additional prompt templates)
└── __pycache__/         # Python bytecode cache

🔧 Development

Local Development Setup

Activate the virtual environment:
```
uv venv
.venv\Scripts\activate
```
Install in development mode:
```
uv pip install -e .
```
Run the server directly (for testing):
```
uv run python main.py
```

Testing the Server

You can test individual prompts by running the server locally and using the MCP client tools:

# Run the server
uv run mcp run main.py

# In another terminal, test prompts
uv run mcp call main.py prompts/list

Adding New Prompts

Define your prompt function in main.py:

@mcp.prompt(title="your prompt title", description="Description of what it does")
def your_prompt_function(input_parameter: str) -> str:
    return f"""Your prompt template here with {input_parameter}"""

Follow the established patterns for structured output and clear instructions.
Test your prompt thoroughly before deployment.

📊 Data Models

UserStory Model

The UserStory class provides a comprehensive structure for capturing user requirements:

class UserStory(BaseModel):
    id: str                           # Unique identifier
    name: str                         # Concise title
    definition: str                   # "As a..., I want..., so that..."
    pre_condition: Optional[str]      # Required state before execution
    post_condition: Optional[str]     # Expected state after completion
    actors: List[str]                 # Involved stakeholders
    normal_flow: List[Step]           # Happy path steps
    exceptional_flows: List[Step]     # Error/alternative paths
    moscow: MoSCoW                    # Priority (Must/Should/Could/Won't Have)
    moscow_explanation: Optional[str] # Priority rationale
    requirements: List[str]           # Related requirement references

Step Model

For process flow documentation:

class Step(BaseModel):
    id: str      # Step identifier (e.g., "1", "2a", "3b")
    action: str  # Description of what happens

🔒 Security Considerations

The server processes text input only - no file system access
All prompts generate documentation, not executable code
Input validation is handled by Pydantic models
No external API calls or network access required

🤝 Contributing

Fork the repository
Create a feature branch: git checkout -b feature/new-prompt
Add your changes and tests
Commit with clear messages: git commit -m "Add new prompt for..."
Push and create a pull request

Code Style

Follow PEP 8 for Python code
Use type hints for all function parameters and returns
Add docstrings for new models and complex functions
Maintain consistent prompt formatting and structure

📄 License

[Add your license information here]

🆘 Troubleshooting

Common Issues

Server not appearing in Claude Desktop:

Verify the path in claude_desktop_config.json is correct
Ensure uv is installed and accessible
Check that Python 3.11+ is installed
Restart Claude Desktop after configuration changes

Import errors:

Run uv sync to ensure all dependencies are installed
Verify you're using Python 3.11 or higher

Prompt not working as expected:

Check the prompt formatting and structure
Ensure input parameters match the expected types
Review the output for any parsing errors

Getting Help

Check the MCP documentation
Review existing prompt implementations in main.py
Create an issue for bugs or feature requests

🔮 Future Enhancements

Additional prompt templates for specific domains
Integration with project management tools
Export capabilities for generated documentation
Batch processing for multiple user stories
Custom template support
Integration with version control systems

Made with ❤️ for better software documentation

Available Tools

8 tools

create_task create taskC

Create a new task in the task repo system.

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Name of the task
`uuid`	Yes	Unique identifier for the task
`state`	Yes	Current state of the task (e.g., 'in_progress', 'completed')
`created_at`	Yes	Timestamp when the task was created
`started_at`	No	Timestamp when the task was started
`parent_task`	No	UUID of the parent task if this is a subtask

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish this as a non-read-only, non-idempotent, non-open-world mutation. The description adds nothing beyond that: no information about required permissions, whether fields like uuid/created_at are system-generated or caller-supplied, or what happens on duplicate creation. With annotations covering the safety profile, the description still fails to add the useful behavioral context a mutation tool needs.

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?

A single short sentence that is front-loaded and free of waste. It is concise to a fault; the issue is omission rather than verbosity.

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?

For a creation tool with a nested required Task object, zero schema coverage, and no output schema, the description is inadequate. It does not explain the expected argument shape, system-generated fields, or how the created task interacts with siblings like create_user_story. The presence of a nested $ref in the input schema makes the omission more serious.

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%, yet the description does not explain the single required 'task' parameter or its nested Task model at all. The schema's own $defs provides some field-level documentation, but the description does not compensate for the reported coverage gap and gives no mapping guidance.

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?

States a specific verb (Create) and resource (task) and scope (in the task repo system), which distinguishes it from update_task_status and delete_task. It does not, however, differentiate clearly from create_user_story or generate_requirements, which may also create task-adjacent artifacts.

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 on when to use this tool versus create_user_story, generate_requirements, or other sibling creation tools. The only implied context is 'new task in the task repo system', which is weak. An agent has no explicit when-to-use or when-not-to-use cues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_user_storycreate user storyC

Create a structured user story based on provided context

ParametersJSON Schema

Name	Required	Description	Default
`user_story`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`ID`	Yes	Unique user story identifier
`Name`	Yes	Short title of the story
`Actors`	Yes	List of actors involved
`MoSCoW`	Yes	Priority category
`Definition`	Yes	What the story is about
`Requirements`	Yes	Related requirement IDs or references
`Pre-condition`	No	State that must hold before
`Post-condition`	No	State after completion
`MoSCoW explanation`	No	Why it’s that priority
`Acceptance criteria`	No	Conditions for acceptance
`Normal process flow`	Yes	Ordered happy‐path steps
`Exceptional process flows`	Yes	Any error or alternate paths

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, openWorldHint=false, idempotentHint=false. The description restates the creation behavior but adds no new context: it doesn't mention required permissions, whether it persists to storage, whether it overwrites, or whether it validates against an existing ID. For a mutation tool, this is sparse.

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?

One concise sentence with no filler. It is front-loaded with the main action and resource. Very efficient, though a bit more context could be added without bloat.

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 input schema (nested UserStory object) and a defined output schema. The description does not explain the required fields, the relationship to requirements or tasks, or the tool's behavior after creation. Given the complexity, the description is too thin.

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 0%, meaning the parameter documentation resides entirely in the schema itself (which is extensive with nested properties). The description says 'structured user story' which hints at the schema shape but adds no syntax, format, or constraint details. However, the schema is self-documenting for an agent that reads it, so a baseline 3 is fair.

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?

States a clear verb+resource: 'Create a structured user story'. This distinguishes it from the get_* and update_* siblings. However, it doesn't explicitly differentiate from generate_requirements or create_task, though the resource name implies 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?

No when-to-use guidance or alternatives mentioned. The description only says it creates a story 'based on provided context', leaving the agent to infer when this is appropriate versus generate_requirements or create_task.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_taskdelete taskC

Destructive

Delete a task from the task repo system.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write. The description adds nothing beyond that—no mention of permanence, cascade effects, required permissions, or recovery options. For a destructive operation, more behavioral context would be valuable.

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?

Single, efficient sentence with no waste. Front-loaded with the action and target. Could be slightly more informative but is appropriately sized.

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?

For a destructive tool with no output schema, the description is too thin. It omits critical details like what happens on success/failure, whether the task is permanently removed, and any side effects. Annotations cover the safety profile but the description should still provide operational context.

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 coverage is 0%, so the description must compensate but doesn't. It doesn't clarify that 'uuid' identifies the task to delete or its format. However, with only one required parameter and the schema naming it clearly, the baseline of 3 is defensible, though the description should do more.

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?

Clear verb+resource: 'Delete a task from the task repo system.' An agent knows exactly what this tool does. It does not, however, differentiate itself from siblings like update_task_status or create_task, though the delete action is inherently distinct.

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 when-to-use guidance, no prerequisites, no alternatives mentioned. The description simply states the action without context about when deletion is appropriate vs. archiving or status changes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_requirementsgenerate requirementsC

Idempotent

Generate structured requirements from a user story

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and idempotentHint=true, but the description adds no behavioral context such as side effects, permission needs, or what happens on repeated calls. It also does not contradict the annotations, so this is not an inconsistency.

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, front-loaded sentence with no wasted words. It is appropriately concise, though the brevity leaves other dimensions under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. The description states the core purpose, but it leaves usage guidance and behavioral details largely uncovered, making it only minimally complete for an agent.

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?

The top-level request parameter has no schema description coverage, and the tool description only adds that generation is based on a user story. It does not explain the request wrapper or the optional project_name field, so it fails to compensate for the low parameter description coverage.

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 specific verb and resource: generate structured requirements from a user story. It is clear enough to distinguish from get_requirements, but it does not explicitly contrast itself with sibling tools such as create_user_story or get_requirements.

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 gives no guidance on when to use this tool versus alternatives, nor does it state prerequisites or exclusions. The only implied usage is that a user story is required as input, which is already visible from the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_requirementsget requirementsB

Read-onlyIdempotent

Retrieve all stored requirements

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety and idempotency profile is fully covered. The description adds only the word 'all', which hints at no filtering but is not developed into anything about result size, paging, or failure behavior.

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?

A single short sentence with the resource front-loaded and zero filler. It is appropriately sized, though the brevity is partly because so little is specified.

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?

With an output schema present, return values need no explanation, and annotations carry the safety profile for a no-arg read. The only real gap is that the agent gets no help choosing between this and generate_requirements.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. No semantic gap is created by a parameterless signature.

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?

States a specific verb and resource ('Retrieve ... requirements') plus scope ('all stored'), which is clearer than a bare tautology. However, it never distinguishes itself from the sibling generate_requirements, so an agent cannot tell from the description alone whether this generates or just fetches.

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 when-to-use guidance and no mention of the obvious alternative, generate_requirements. The word 'stored' implies retrieval of pre-existing items rather than generation, but this is left to inference rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_tasks_toolget tasksC

Read-onlyIdempotent

Retrieve all tasks from the task repo system.

ParametersJSON Schema

Name	Required	Description	Default
`parentId`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds nothing beyond that — no pagination behavior, no scoping rules, and 'all tasks' is mildly misleading given an optional parentId filter. With annotations carrying the load, the description still contributes almost no behavioral context.

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?

One short, front-loaded sentence with no wasted clauses. It is efficient, though 'from the task repo system' is vague filler that adds no actionable meaning.

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?

An output schema exists so return values need not be explained, but for a tool with an optional parentId filter that is undocumented everywhere, the description leaves a real gap: an agent cannot tell whether omitting parentId returns a global list or a subtree. It should clarify the scoping semantics of that parameter.

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 single parentId parameter is undocumented in both schema and description. 'Retrieve all tasks' actively suggests no filtering, which obscures rather than explains the parentId argument's purpose.

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?

States a specific verb ('Retrieve') and resource ('tasks'), clearly telling an agent what the tool returns. However, it offers no differentiation from siblings like get_user_stories, create_task, or update_task_status, and the word 'all' conflicts with the fact that a parentId filter exists.

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 on when to use this versus the sibling read tools (get_user_stories, get_requirements) or the task mutation tools. The 'all tasks' phrasing implies an unfiltered dump but never explains what parentId does or when to pass it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_user_storiesget user storiesB

Read-onlyIdempotent

Retrieve all stored user stories

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety and determinism profile is covered. The description's only added behavioral signal is 'all stored', implying an unfiltered full listing, but it says nothing about pagination, ordering, or volume limits.

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?

A single short, front-loaded sentence with no filler. It is efficient, though 'stored' is mildly redundant and the sentence is arguably under-specified rather than optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and a no-parameter read tool has a low transparency burden. Still, the description omits any routing guidance relative to get_requirements, which is the main missing piece for correct tool selection.

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?

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate at the parameter level. Schema coverage is also 100%, leaving no documentation gap for the description to fill.

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 pairs a specific verb ('Retrieve') with a specific resource ('user stories') and clarifies scope with 'all stored'. It does not, however, distinguish this tool from the similarly named sibling get_requirements, so an agent gets no help choosing between them from the wording alone.

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 such as get_requirements or get_tasks_tool, nor any stated precondition or exclusion. The agent must infer usage purely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_task_statusupdate taskC

Update an existing task in the task repo system.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes
`status`	Yes

TDQS

C2.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=false, openWorldHint=false, idempotentHint=false), so the bar is lower, but the description adds nothing on top of them. It does not say what changes, whether status transitions are validated, or any side effects of a non-idempotent update.

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?

One short sentence with no filler, but its brevity reflects under-specification rather than tight writing given the tool takes two required parameters and performs a mutation.

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?

For a mutation tool with two undocumented required parameters and no output schema, the description leaves critical gaps: valid status values, task identification, and update behavior are all unstated.

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% and neither parameter has any description in the schema. The description does not explain that uuid identifies the task or what valid status values exist, so the agent gets no semantics beyond the bare property names.

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 a verb and resource ("Update an existing task"), which is clear enough at a glance, but it never mentions the status field that the tool name and required parameters center on. It also does nothing to distinguish itself from siblings like create_task, delete_task, or get_tasks_tool.

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 sibling delete_task or create_task, nor any mention of prerequisites such as needing an existing task UUID. The reader must infer everything from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Sep 13, 2026
- First observedcreate_task
- First observedcreate_user_story
- First observeddelete_task
- First observedgenerate_requirements
- First observedget_requirements
- First observedget_tasks_tool
- First observedget_user_stories
- First observedupdate_task_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-09-13 06:55 across 8 tools

Disambiguation5/5

Each tool targets a distinct resource and action: user stories (create/get), requirements (generate/get), and tasks (create/get/update status/delete). There is no overlap or ambiguity between any pair of tools.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern in snake_case (create_user_story, get_user_stories, create_task, etc.). The tool 'get_tasks_tool' deviates by appending a redundant '_tool' suffix, which is a minor inconsistency.

Tool Count5/5

Eight tools are well-scoped for managing user stories, requirements, and tasks. Each tool has a clear purpose and the count fits comfortably within the typical 3-15 range.

Completeness3/5

The server covers create and retrieve for user stories and requirements, and partial CRUD for tasks, but lacks update/delete operations for user stories and requirements, as well as task retrieval by ID or full task updates. These notable gaps limit lifecycle coverage.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

TablaCognitaOAuth
io.github.PStryder
MCP-native collaborative markdown editor with real-time AI document editing
Workplace & Productivity Note Taking App Automation
22
agent-wikiOAuth
com.getagentwiki
Hosted markdown project wikis your team's AI assistants read, search, and update over MCP.
Documentation Access Note Taking Workplace & Productivity
1
ainote B
io.github.seunghan91
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
Note Taking Developer Tools Knowledge & Memory
353
DevSpeak
io.github.juanjaragavi
Official DevSpeak MCP server — translate technical text into formal specs from any AI IDE or agent
Developer Tools AI & Machine Learning Documentation Access
2

Related MCP Servers

Memory Bank MCP
Project Management Developer Tools Content Management Systems
tuncer-byte
A
license
C
quality
D
maintenance
An MCP server that helps teams create, manage, and access structured project documentation through six core document types, leveraging AI to generate comprehensive project knowledge management.
Updated a year ago (2025-06-12 20:23 UTC)
5
17 npm
101
MIT
Spec Workflow MCP
Developer Tools Project Management Documentation Access
kingkongshot
A
license
B
quality
F
maintenance
An intelligent MCP server that helps development teams maintain high-quality project documentation by providing an AI-powered workflow for creating comprehensive specifications through requirements, design, and implementation documents.
Updated a year ago (2025-08-11 15:11 UTC)
1
31 npm
127
MIT
Backlogr MCP Server
Project Management Developer Tools Autonomous Agents
scottiesan
-
license
Not graded
quality
Not graded
maintenance
Enables AI assistants to create and manage development projects with structured backlogs, including tasks, requirements, and progress tracking. Provides a bridge between AI development assistants and project management workflows through standardized MCP tools.
Updated a year ago (2025-09-16 05:59 UTC)
-
Gigaspec
Developer Tools Software Architecture Autonomous Agents
oleksiitrembach
A
license
Not graded
quality
D
maintenance
An AI-native specification framework that enables deep requirements analysis and structured project planning through intelligent Q\&A workflows. The MCP server provides tools for project initialization, requirement analysis, and the generation of living documentation like development plans and architecture specs.
Updated 7 months ago (2026-02-18 22:58 UTC)
4 npm
Apache 2.0