The MCP Prompt Server provides centralized, preset prompt templates as MCP tools for various development and writing tasks. These templates can be used in compatible code editors like Cursor and Windsurf through the MCP protocol.
Key capabilities include:
Development Assistance: Generate API documentation, refactor code, perform code reviews, design architecture, and create test cases
Writing Assistance: Help with content creation for blogs, social media, and other platforms
Template Management: Add, modify, and reload prompt templates dynamically
Parameter Replacement: Support dynamic parameter substitution within templates
Integration: Seamlessly connect with MCP-compatible editors
Provides pre-configured prompt templates for code review, API documentation, and code refactoring of JavaScript code through editor tools.
Provides formatting options for API documentation generation with support for Markdown output format.
Used for server installation and dependency management with npm commands for setup and execution.
Offers specialized prompt templates for reviewing, documenting, and refactoring Python code with parameter customization.
Allows defining prompt templates in YAML format with structured metadata, arguments, and message content.
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., "@MCP Prompt Server generate API documentation for my Python function in markdown format"
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.
🚀 重要升级通知！
我们基于基于 MCP Prompt Server 使用场景，推出全新升级服务：mypromptmcp.com。
通过该平台，您可以在线自由管理自己的 prompt 提示词，并且允许灵活组合、打包成 MCP 服务，轻松集成到不同的 AI Agent 或工具中（如 Cursor、Windsurf、Cline 等），实现跨平台调用和高效协作。
立即体验更强大的 prompt 管理与分发能力，访问 mypromptmcp.com 了解详情！
⚠️ 重要提醒：
MCP Prompt Server 依然可以正常使用，但后续我们将不再进行功能升级和维护。如果您希望持续获得最新的功能和体验，建议迁移并使用 mypromptmcp.com。
这是一个基于Model Context Protocol (MCP)的服务器，用于根据用户任务需求提供预设的prompt模板，帮助Cline/Cursor/Windsurf...更高效地执行各种任务。服务器将预设的prompt作为工具(tools)返回，以便在Cursor和Windsurf等编辑器中更好地使用。
提供预设的prompt模板，可用于代码审查、API文档生成、代码重构等任务
将所有prompt模板作为MCP工具(tools)提供，而非MCP prompts格式
支持动态参数替换，使prompt模板更加灵活
允许开发者自由添加和修改prompt模板
提供工具API，可重新加载prompt和查询可用prompt
专为Cursor和Windsurf等编辑器优化，提供更好的集成体验
Related MCP server: RT-Prompt-MCP
prompt-server/
├── package.json # 项目依赖和脚本
├── src/ # 源代码目录
│ ├── index.js # 服务器入口文件
│ └── prompts/ # 预设prompt模板目录
│ ├── code_review.yaml
│ ├── api_documentation.yaml
│ ├── code_refactoring.yaml
│ ├── test_case_generator.yaml
│ └── project_architecture.yaml
└── README.md # 项目说明文档安装依赖：
cd prompt-server
npm install启动服务器：
npm start服务器将在标准输入/输出上运行，可以被Cursor、Windsurf或其他MCP客户端连接。
您可以通过在src/prompts目录中添加新的YAML或JSON文件来创建新的prompt模板。每个模板文件应包含以下内容：
name: prompt_name # 唯一标识符，用于调用此prompt
description: prompt description # 对prompt功能的描述
arguments: # 参数列表（可选）
- name: arg_name # 参数名称
description: arg description # 参数描述
required: true/false # 是否必需
messages: # prompt消息列表
- role: user/assistant # 消息角色
content:
type: text # 内容类型
text: | # 文本内容，可包含参数占位符 {{arg_name}}
Your prompt text here...添加新文件后，服务器会在下次启动时自动加载，或者您可以使用reload_prompts工具重新加载所有prompt。
{
"name": "code_review",
"arguments": {
"language": "javascript",
"code": "function add(a, b) { return a + b; }"
}
}{
"name": "api_documentation",
"arguments": {
"language": "python",
"code": "def process_data(data, options=None):\n # 处理数据\n return result",
"format": "markdown"
}
}服务器提供以下管理工具：
reload_prompts: 重新加载所有预设的prompts
get_prompt_names: 获取所有可用的prompt名称
此外，所有在src/prompts目录中定义的prompt模板都会作为工具提供给客户端。
在Cursor中，您需要编辑MCP配置文件：
找到或创建Cursor的MCP配置文件（通常位于~/.cursor/目录）
添加以下内容：
{
"servers": [
{
"name": "Prompt Server",
"command": ["node", "/path/to/prompt-server/src/index.js"],
"transport": "stdio",
"initialization_options": {}
}
]
}请确保将/path/to/prompt-server替换为您实际的项目路径。
保存配置并重启编辑器
现在您应该能够在工具面板中看到所有可用的prompt工具
在Windsurf中，通过以下方式访问MCP配置：
导航至 Windsurf - 设置 > 高级设置，或
使用命令面板 > 打开Windsurf设置页面
滚动到Cascade部分，您会看到添加新服务器的选项
点击"添加服务器"按钮，然后选择"添加自定义服务器+"
或者，您可以直接编辑~/.codeium/windsurf/mcp_config.json文件，添加以下内容：
{
"mcpServers": {
"prompt-server": {
"command": "node",
"args": [
"/path/to/prompt-server/src/index.js"
],
"transport": "stdio"
}
}
}请确保将/path/to/prompt-server替换为您实际的项目路径。
添加服务器后，点击刷新按钮
现在您应该能够在工具面板中看到所有可用的prompt工具
添加更多专业领域的prompt模板
实现prompt版本控制
添加prompt分类和标签
实现prompt使用统计和分析
添加用户反馈机制
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | 编程语言 | |
| code | Yes | 要生成文档的API代码 | |
| format | Yes | 文档格式(markdown/html/jsdoc等) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | 编程语言 | |
| code | Yes | 要重构的代码 | |
| focus_areas | Yes | 重点关注的重构领域(如性能、可读性、模块化等) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | 编程语言 | |
| code | Yes | 要审查的代码 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| project_type | Yes | 项目类型(如Web应用、移动应用、API服务等) | |
| technologies | Yes | 使用的技术栈(如React, Node.js, Python等) | |
| features | Yes | 项目主要功能和特性 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt_name | Yes | 新prompt的名称（唯一标识符） | |
| prompt_description | Yes | 对prompt功能的描述 | |
| task_type | Yes | 任务类型（如代码生成、文档编写、数据分析等） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | 编程语言 | |
| code | Yes | 要测试的代码 | |
| test_framework | Yes | 测试框架(如Jest, Pytest, JUnit等) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | Yes | 用户提供的草稿内容 | |
| platform | Yes | 目标平台（如公众号、小红书、推特等） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools cover distinct areas like code (refactoring, review), prompts (get, reload, template), and general assistance (writing, test generation), but there is some overlap in purpose. For example, 'code_refactoring' and 'code_review' could be confused as both involve code improvement, and 'writing_assistant' might overlap with 'prompt_template_generator' in text creation tasks. Descriptions are missing, which adds to the ambiguity.
The naming is inconsistent with mixed conventions: some use snake_case (e.g., 'api_documentation', 'get_prompt_names'), others use more descriptive phrases without a clear pattern (e.g., 'build_mcp_server', 'project_architecture'). There is no uniform verb_noun structure, making it harder to predict tool purposes from names alone.
With 10 tools, the count is reasonable for a server focused on MCP and prompt-related tasks. It covers a range of functions from development to content generation, which aligns well with the server's apparent scope, though it might be slightly broad. No tools feel redundant or excessive in number.
Inferring the domain as MCP server development and prompt management, there are notable gaps. For instance, tools like 'build_mcp_server' and 'reload_prompts' suggest lifecycle operations, but there's no clear update or delete functionality for prompts or servers. Core areas like testing and documentation are covered, but the surface feels incomplete for full CRUD workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gdli6177/mcp-prompt-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
