What can you do with this server?

The prompts-mcp-server maintains conversational context and continuity across development sessions, helping AI assistants manage project state, workflows, and tasks. * Initialize Project (init_prompts / pmcp setup): Scans a project and generates a prompt system (context.md, workflow logs, todos, dev rules, module directories) without overwriting existing files. * Bootstrap Session (bootstrap): Loads the full context chain (context.md, daily logs, recent activity, summaries, todos, module records) — the first step an AI agent should call when starting a session. * Clarify Requirements (check_requirements): Runs a 5-point clarity check on a task description and generates follow-up questions instead of guessing when requirements are ambiguous. * Generate Execution Plan (make_plan): After requirements are confirmed, generates a concrete, actionable plan awaiting user approval. * Log Dialogs (log_dialog): Records a conversation session into the context chain (daily log, recent activity, summaries, session state) including decisions, code changes, and leftover todos. * Log & Read Module Changes (log_module / read_module): Records modifications per code module and retrieves historical records — read module history before making changes. * Manage Todos (update_todos): Add, complete, or remove items in the project's todos.md. * Skill System (pmcp skill): Manage and apply specialized role-based skills (e.g., analyst, architect, backend) for different tasks. * Code Version Control: Facilitates commits, pushes, and publishing workflows including privacy audits (pmcp audit, pmcp publish). * Tool & Scene Recommendation (pmcp tools / pmcp recommend): Discover and recommend appropriate development tools and scenarios for specific contexts.

How do I use prompts-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., "@prompts-mcp-server Initialize prompts for my project" 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.

de en es ja ko ru zh

prompts-mcp-server

by thana0623

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

prompts-mcp-server

A universal MCP (Model Context Protocol) Server that automatically generates and manages a prompts system for any software project, enabling AI coding assistants to maintain persistent context across development sessions.

Features

Intelligent Project Scanning — Automatically identifies the target project's tech stack, frameworks, databases, and build tools
Context Persistence — Maintains a complete chain of project context, conversation logs, and module change history
Requirement Clarification Check — A 5-point standard requirement confirmation mechanism to prevent blind development
Plan Generation — Generates an executable plan after requirement confirmation, awaiting user approval before implementation
Rolling Window System — Maintains the last 5 conversation records and 10 status summaries, with automatic rotation
Module-level Tracking — Records change history by functional module for easy traceability
Dual Interface Mode — Supports both MCP Server (stdio protocol) and CLI usage
Non-destructive Initialization — Does not overwrite existing files when generating prompt files

Related MCP server: MCP Prompt Enhancer

MCP Tools

Tool	Description
`init_prompts`	Scans the target project and automatically generates the prompts file system
`bootstrap`	Loads all context files at once; called as the first step when an AI agent starts
`check_requirements`	5-point standard requirement clarification check (Goal, Input/Output, Constraints, Acceptance Criteria, Impact Scope)
`make_plan`	Generates an executable plan after requirements are clarified
`log_dialog`	Logs conversation entries to the transmission chain (rolling window + status summary)
`log_module`	Records module-level changes (directory-based management)
`read_module`	Reads module change history
`update_todos`	Updates the TODO list (add/complete/remove)

Installation

npm install
npm run build

Usage

Integration as an MCP Server

Add the following to your AI assistant's configuration (e.g., Cline, Claude Desktop, etc.):

{
  "mcpServers": {
    "prompts-mcp": {
      "command": "node",
      "args": ["/path/to/prompts-mcp-server/build/index.js"],
      "env": {
        "PROJECT_ROOT": "/path/to/your/project"
      }
    }
  }
}

Usage as CLI

# 初始化 prompts 系统
npm run cli init [--project-root /path]

# 加载所有上下文
npm run cli bootstrap

# 需求检查
npm run cli check "任务描述"

# 生成计划
npm run cli plan "任务描述"

# 记录对话
npm run cli log --title "xxx" --request "xxx" [--changes ...]

# 模块日志
npm run cli module-log <module> --change "xxx"
npm run cli module-read <module>
npm run cli module-list

# TODO 管理
npm run cli todos add|complete|remove "todo text"

Development Mode

npm run dev        # 运行 MCP Server
npm run dev:cli    # 运行 CLI

Environment Variables

Variable	Description	Default Value
`PROJECT_ROOT`	Target project root directory	`process.cwd()`

Generated File Structure

After initialization, the following will be generated in the .github/prompts/ directory of the target project:

.github/prompts/
├── context.md           # 项目上下文：技术栈、规则、TODO、日志索引
├── workflow-log.md      # 工作流规则和 AI 对话规范
├── recent-5.md          # 最近 5 条对话记录（滚动窗口）
├── summary-10.md        # 每 10 条的状态摘要
├── log-state.json       # JSON 状态追踪
├── todos.md             # TODO 列表
├── dev-rules.md         # 自动生成的开发规则
├── daily/               # 每日完整日志
│   └── YYYY-MM-DD.md
└── modules/             # 各模块变更历史
    └── <module-name>.md

Tech Stack

TypeScript (ES2022, ESM)
@modelcontextprotocol/sdk — Official MCP SDK
Node.js Runtime

License

MIT

Available Tools

8 tools

bootstrapA

【一键启动】自动读取传递链（context.md + daily + recent-5 + summary-10 + todos + 模块记录）。智能体启动时第一步调用。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It describes a read operation but does not explicitly state it is read-only or mention other behavioral traits like permissions or side effects. Adequate but minimal.

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?

One sentence with a clear title-like mark. Every word contributes to purpose and usage. No waste.

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 no parameters and no output schema, description is complete for a simple bootstrap. It specifies the files read and when to call. Could add return value context, but not essential.

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?

No parameters in input schema, so baseline is 4. Description adds context by listing the files read, but no param details needed.

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 verb 'reads' and the resource 'delivery chain (context.md + daily + recent-5 + summary-10 + todos + module records)', and specifies it's the first step when the agent starts. This distinguishes it from siblings like init_prompts.

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?

Explicitly states when to use: 'called as the first step when the agent starts'. No explicit alternatives or when-not-to-use, but context is clear for an initialization tool.

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

check_requirementsA

【需求澄清】执行 5 项需求明确标准检查。不明确时生成追问问题，禁止猜测执行。

ParametersJSON Schema

Name	Required	Description	Default
`taskDescription`	Yes	用户提出的任务需求描述

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, description carries burden. It discloses the no-guessing rule and question generation, but lacks detail on the 5 standards and output format.

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?

Extremely concise with two sentences; front-loaded with purpose and key behavioral rule. No fluff.

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?

Lacks description of return value (likely list of questions or report). For a tool with no output schema, this is a notable gap. Sibling tools suggest a workflow but missing output 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?

Single parameter has 100% schema coverage; description does not add significant new meaning beyond using the parameter in context. Baseline score appropriate.

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?

Description clearly states the tool checks requirements against 5 clarity standards and generates follow-up questions. It is specific and distinct from sibling tools like make_plan.

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?

Explicitly says to generate questions when unclear and prohibits guessing, providing clear usage guidance. Could mention when to prefer this tool over alternatives.

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

init_promptsA

【初始化】扫描目标项目，自动生成原始 prompts 体系（context.md / workflow-log.md / recent-5.md / summary-10.md / todos.md / dev-rules.md / modules/）。已有文件不会覆盖。

ParametersJSON Schema

Name	Required	Description	Default
`projectRoot`	No	目标项目根目录路径。不传则使用 PROJECT_ROOT 环境变量或当前目录。

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that existing files are not overwritten, which is a key safety behavior. Additional traits like side effects are not mentioned but the non-destructive nature is clear.

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 sentence listing all generated files; no redundant information. Could be slightly more structured but it is efficient and front-loaded.

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 no output schema and one parameter, the description covers generation scope, parameter fallback, and non-destructive behavior. Lacks details on return values but that is acceptable.

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 schema describes the parameter, and the description adds value by explaining the fallback behavior (using PROJECT_ROOT environment variable or current directory if not provided), which goes beyond schema.

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 tool initializes a target project by scanning and auto-generating specific prompt files, listing them explicitly. This distinguishes it from sibling tools like 'bootstrap' or 'make_plan'.

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 implies it's for initial setup and that existing files are not overwritten, but does not explicitly state when to use vs alternatives or provide exclusions. The context is clear enough for an AI agent.

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

log_dialogB

【记录日志】记录一次对话到传递链（daily + recent-5 + summary-10 + log-state.json）。

ParametersJSON Schema

Name	Required	Description
`title`	Yes	对话简明标题
`request`	Yes	清洗后的用户需求
`changes`	No	代码变更文件列表
`decisions`	No	本次技术决策
`todos`	No	遗留待办项

TDQS

B3.1/5.0

Behavior3/5

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

The description names the storage locations (daily, recent-5, summary-10, log-state.json), providing some insight into side effects. However, it does not disclose potential overwrite behavior, concurrency issues, 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence front-loading the action, but the parenthesized list of destinations is somewhat cryptic. Still, no wasted words.

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?

No output schema; description lacks information about return value, confirmation, or behavior on duplicate entries. Insufficient for an agent to fully understand the outcome.

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 100%, so the schema already describes parameters. The description adds no extra meaning or context for parameters, resulting in baseline score.

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 states the tool records a dialog to specific destinations. However, it does not explicitly differentiate from sibling tool 'log_module', which may have similar functionality.

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 over alternatives like log_module or other siblings. Usage is implied but not clarified.

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

log_moduleA

【模块记录】按模块记录一次修改（目录式）。修改功能前先 read_module，修改后调用此工具。

ParametersJSON Schema

Name	Required	Description
`moduleName`	Yes	模块名称（如 auth、rag-upload、frontend）
`change`	Yes	变更内容描述
`files`	No	涉及的文件列表
`decisions`	No	本次决策

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It indicates the tool writes a log but does not disclose persistence, idempotency, or error behavior. Some transparency, but minimal beyond the purpose.

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 two concise sentences. The first states the purpose, the second gives workflow guidance. No unnecessary words.

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?

Given no output schema and no annotations, the description explains the basic purpose and usage sequence but omits return value, failure behavior, or side effects. Adequate but not comprehensive.

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% (all 4 parameters have descriptions). The tool description adds no additional parameter information beyond what the schema already provides, earning the baseline score.

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 tool records a modification by module ('按模块记录一次修改（目录式）') and distinguishes from sibling read_module by specifying the workflow order.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use instructions: '修改功能前先 read_module，修改后调用此工具' (read_module before modification, log_module after). This guides the agent on the correct sequence.

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

make_planA

【生成计划】在需求已澄清（check_requirements 全部 ✅）后，生成可行执行计划，等待用户确认。

ParametersJSON Schema

Name	Required	Description	Default
`taskDescription`	Yes	已澄清的任务需求描述

TDQS

A4/5.0

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. It indicates the tool generates a plan and waits for user confirmation, implying a non-blocking or pending state. However, it lacks details on side effects, permissions, or what '等待用户确认' means for system state.

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 in Chinese that includes the tool's name in brackets. It includes all essential information without extra words.

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 simple tool (1 param, no output schema), the description covers prerequisite, action, and outcome adequately. It could mention the return value or plan format, but the core workflow is clear.

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?

Input schema has 100% coverage with a clear description for the required parameter 'taskDescription'. The tool description adds no new information beyond confirming it is the '已澄清的任务需求描述', so baseline 3 is appropriate.

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 specifies the tool's action ('生成可行执行计划'), its prerequisite ('在需求已澄清 (check_requirements 全部 ✅) 后'), and its outcome ('等待用户确认'). It clearly distinguishes from sibling tool check_requirements by stating the sequential dependency.

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 explicitly states when to use the tool: after check_requirements is fully completed. It does not provide explicit when-not-to-use scenarios or list alternatives beyond the implied sibling, but the context is clear.

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

read_moduleB

【读取模块记录】修改功能前调用，读取对应模块的历史修改记录。

ParametersJSON Schema

Name	Required	Description	Default
`moduleName`	Yes	模块名称

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It indicates a read operation with no side effects, which is appropriate for a read tool. It does not mention authorization, rate limits, or output details, but the read nature is clear.

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 very concise, consisting of a single sentence that effectively communicates the purpose and timing. It is well-structured and front-loaded with the key action.

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?

Given the simplicity (one required parameter, no output schema), the description covers the basic purpose and usage context. However, it lacks details on the output format or how to interpret the results, which could be important for an agent selecting 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 already provides a description for the single parameter ('module name') with 100% coverage. The description does not add extra meaning beyond 'the corresponding module', so it meets the baseline but does not enhance understanding.

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 states that the tool reads historical modification records of a module and is called before modification, distinguishing it from siblings like 'log_module' which likely logs new records rather than reading history.

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 specifies that the tool is used before modifying a function, providing usage context. However, no alternatives or when-not-to-use guidance are given, and there is no explicit differentiation from sibling tools like 'log_module'.

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

update_todosB

【更新待办】更新 todos.md 中的待办事项。

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	操作类型: add（添加）/ complete（完成）/ remove（删除）
`todo`	Yes	待办事项内容

TDQS

B3.2/5.0

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 burden. It does not disclose that the tool modifies a file, has persistent effects, or any side effects beyond the action parameter.

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 sentence with no wasted words. However, it is somewhat minimal.

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?

Given the two simple parameters, the description is adequate but lacks details on success conditions, error handling, or the fact that it modifies a file.

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 100%, so baseline is 3. The description adds no additional meaning beyond the schema definitions for action and todo.

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 tool updates todos in todos.md with a specific verb and resource. It is distinct from sibling tools like read_module or make_plan.

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 alternatives. It does not mention prerequisites or when not to use it.

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 updatesv1.0.0May 6, 2026
- First observedbootstrap
- First observedcheck_requirements
- First observedinit_prompts
- First observedlog_dialog
- First observedlog_module
- First observedmake_plan
- First observedread_module
- First observedupdate_todos

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

A3.9/5.0

Scored 2026-05-06 16:10 across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: bootstrap for startup, check_requirements for requirement clarity, init_prompts for initializing prompt files, log_dialog and log_module for different logging scopes, make_plan for planning after requirements, read_module for reading module history, and update_todos for todo updates. No overlap.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with imperative verbs (bootstrap, check, init, log, make, read, update). No mixing of styles or ambiguous terms.

Tool Count5/5

With 8 tools, the set is well-scoped for a development workflow assistant. Each tool addresses a specific step in the workflow without being too few or too many.

Completeness4/5

The tools cover the core workflow: initialization, requirement clarification, logging (dialog and module), planning, and todo management. Missing explicit tools for viewing summaries or resetting, but the existing tools update these automatically, so gaps are minor.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

SprintraOAuth
io.github.Sprintra-io
The project brain for AI coding agents — memory, decisions, sprints, knowledge base via MCP.
Project Management Developer Tools Knowledge & Memory
23
FairMind Project Context
ai.fairmind
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
Knowledge & Memory Code Analysis
1
OneLoreOAuth
ai.onelore
Shared project context for AI agents and teams: docs, tasks, and messages that stay current.
Project Management Documentation Access
2
Roamer MCPOAuth
com.mathismeadows
Project registry, behavioral specs, and engineering threads for AI coding agent workflows.
Agent Orchestration Developer Tools Project Management
1

Related MCP Servers

Developer MCP Server
Developer Tools Knowledge & Memory
tejpalvirk
F
license
A
quality
D
maintenance
A powerful context management system that maintains persistent context across coding sessions, helping development teams track project structure, dependencies, and progress.
Updated 10 months ago (2025-11-15 06:07 UTC)
6
5
-
MCP Prompt Enhancer
soniankur948
F
license
Not graded
quality
D
maintenance
Intelligently analyzes codebases to enhance LLM prompts with relevant context, featuring adaptive context management and task detection to produce higher quality AI responses.
Updated a year ago (2025-07-10 06:45 UTC)
2
-
PromptArchitect MCP
Developer Tools Autonomous Agents RAG Systems
MerabyLabs
F
license
A
quality
C
maintenance
Refines and improves AI prompts using workspace-aware context from your project's tech stack, structure, and dependencies. Includes tools to analyze prompt quality and generate well-structured prompts from raw ideas.
Updated 9 months ago (2025-12-19 03:10 UTC)
4
209 npm
5
-
Project Memory MCP
Developer Tools Project Management Knowledge & Memory
misaamane21j
A
license
A
quality
Not graded
maintenance
Provides AI-driven project memory management through structured prompts that help Claude parse tasks from specs, review code changes, sync with commit history, and maintain project documentation without directly accessing files.
Updated 9 months ago (2026-01-01 20:53 UTC)
7
-