dev-prompt-mcp
Provides a specialized tool to generate API service code by retrieving interface definitions via Apifox, facilitating the automation of API client development.
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., "@dev-prompt-mcpperform a code review on my selected code"
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.
dev-prompt-mcp
一个基于 MCP (Model Context Protocol) 的 Prompt 管理服务器,将常用的 Prompt 模板注册为 MCP 工具,通过自然语言对话即可调用。
✨ 特性
🚀 TypeScript 开发 - 完整的类型支持,代码更健壮
📦 Prompt 即工具 - 所有 Prompt 自动注册为 MCP 工具,支持参数化调用
🔄 热加载 - 支持命令式动态加载 Prompt,无需重启服务
🧩 易于扩展 - 添加 YAML/JSON 文件即可扩展新 Prompt
🛠️ 开发友好 - 支持开发模式、Inspector 调试
Related MCP server: MCP-YNU FastMCP Server
📦 安装
方式 1:NPM 全局安装
npm install -g dev-prompt-mcp方式 2:NPX 直接运行(推荐)
无需安装,直接在 MCP 配置中使用 npx。
方式 3:从源码安装
git clone https://github.com/sayll/dev-prompt-mcp.git
cd dev-prompt-mcp
pnpm install
pnpm run build🔧 MCP 配置
方式 1:使用 npx(推荐)
适用于 Cursor / Windsurf / Augment / Trae 等,编辑对应的 mcp_config.json:
{
"mcpServers": {
"dev-prompt": {
"command": "npx",
"args": ["dev-prompt-mcp"]
}
}
}方式 2:全局安装后使用
{
"mcpServers": {
"dev-prompt": {
"command": "dev-prompt-mcp"
}
}
}方式 3:从源码运行
{
"mcpServers": {
"dev-prompt": {
"command": "node",
"args": ["/your/path/to/dev-prompt-mcp/dist/index.js"]
}
}
}Raycast
搜索
install server (MCP)Name:
dev-promptCommand:
npxArguments:
dev-prompt-mcp
📁 项目结构
dev-prompt-mcp/
├── src/
│ ├── index.ts # 服务器入口
│ ├── PromptManager.ts # Prompt 管理器(加载、注册、监听)
│ ├── types.ts # TypeScript 类型定义
│ └── prompts/ # Prompt 模板目录
│ ├── gen_summarize.yaml
│ ├── gen_apifox_api_service.yaml
│ ├── i18n_chinese_transform.yaml
│ ├── code_review.yaml
│ └── code_refactoring.yaml
├── dist/ # 编译输出目录
├── package.json
├── tsconfig.json
└── README.md🛠️ 开发
安装依赖
pnpm install可用脚本
命令 | 说明 |
| 开发模式(tsx watch,自动重启) |
| 使用 MCP Inspector 调试 |
| 编译 TypeScript |
| 监听模式编译 |
| 运行编译后的代码 |
📝 内置 Prompt
Prompt | 说明 |
| 生成内容摘要 |
| 通过 Apifox MCP 获取接口并生成 API 服务代码 |
| 将页面中文通过 i18n 转义,管理多语言文件 |
| 代码审查 |
| 代码重构 |
🛠️ 管理工具
工具 | 说明 |
| 重新加载所有 Prompt(支持热更新) |
| 获取当前所有可用 Prompt 名称 |
📄 扩展 Prompt
在 src/prompts/ 目录下创建 YAML 或 JSON 文件:
name: my_custom_prompt
description: 这个 Prompt 的用途说明
arguments:
- name: input
description: 输入参数说明
required: false
messages:
- role: user
content:
type: text
text: |
你的 Prompt 内容
支持参数占位符:{{input}}🏗️ 技术栈
Runtime: Node.js (ESM)
Language: TypeScript
MCP SDK: @modelcontextprotocol/sdk
配置解析: yaml, zod
文件操作: fs-extra
📦 依赖
生产依赖:
@modelcontextprotocol/sdk- MCP 服务器核心 SDKfs-extra- 增强的文件操作yaml- YAML 解析zod- Schema 验证
开发依赖:
typescript- TypeScript 编译器tsx- 开发模式运行 TS@types/node,@types/fs-extra- 类型定义
📄 License
MIT
Available Tools
2 toolsget_prompt_names获取 Prompt 列表B
获取所有可用的prompt名称
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the action. It does not disclose behavioral traits such as read-only nature, side effects, or any prerequisites. The description adds no value beyond the tool's name.
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, front-loaded sentence that efficiently conveys the tool's purpose with no superfluous words. It earns its place.
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 (0 parameters, no output schema), the description is minimally adequate. However, it does not mention the format of the returned names or any ordering, leaving room for interpretation.
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% (0 parameters), so the description does not need to add parameter details. Baseline of 3 applies as the description provides no additional semantic context 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 the verb '获取' (get) and resource 'prompt名称' (prompt names), making the purpose specific. However, it does not differentiate from the sibling tool 'reload_prompts', which could cause ambiguity for the AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling tool 'reload_prompts'. The description lacks any context about appropriate usage scenarios or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reload_prompts重新加载 PromptsA
重新加载所有预设的prompts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states 'reload all preset prompts', lacking details on side effects, persistence, or whether it disrupts existing operations.
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, direct sentence with no redundancy, front-loading the verb and object effectively.
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 simple parameterless tool, the description covers the basic action. However, it could mention that prompts are reloaded from storage, but overall it is adequate.
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, and schema coverage is 100%. The description adds no additional meaning but is sufficient given the absence of parameters.
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 tool description clearly states the action 'reload' and the resource 'prompts', distinguishing it from the sibling tool 'get_prompt_names' which likely lists prompts.
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. The description does not indicate scenarios where reloading is needed or mention any prerequisites.
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. Dates show when Glama detected each change.
2 tool updates
v1.0.0- First observed
get_prompt_names - First observed
reload_prompts
TDQS
The two tools, get_prompt_names and reload_prompts, have clearly distinct purposes: one retrieves names, the other reloads prompts. There is no overlap or ambiguity.
Both tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to understand.
With only 2 tools, the set is on the lower end of appropriate. It feels thin for a prompt management server, which typically would have more operations, but it could be a minimal interface for simple listing and reloading.
The tool surface lacks essential operations for prompt management, such as retrieving prompt content, creating, updating, or deleting prompts. Agents cannot perform basic CRUD tasks, leading to significant gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for generating rough-draft project plans from natural-language prompts.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Related MCP Servers
- FlicenseCqualityDmaintenanceThis is an MCP server that facilitates building tools for interacting with various APIs and workflows, supporting Python-based development with potential for customizable prompts and user configurations.1-

MCP-YNU FastMCP Serverofficial
AlicenseNot gradedqualityDmaintenanceA dynamic MCP server implementation that automatically loads tools, resources, and prompts from their respective directories, allowing for easy extension and configuration.MIT- FlicenseNot gradedqualityDmaintenanceA basic MCP server template that provides a foundation for building custom tools, resources, and prompts. Serves as a starting point for developers to create their own MCP server functionality.-
- AlicenseNot gradedqualityCmaintenanceA lightweight, file-based server for managing and serving personal prompt templates with variable substitution support via the Model Context Protocol. It allows users to store, update, and organize prompts in a local directory through integrated MCP tools and CLI assistants.207MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sayll/dev-prompt-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server