RT-Prompt-MCP is a server that provides domain-specific prompt suggestions to enhance LLM-generated content across various development and design tasks:
Backend Development: Suggestions based on context, programming language, and database type
Frontend Development: Prompts tailored to framework, device type, and context
UI Design: Design conversion prompts considering platform and design type
General Scenarios: Task-specific prompts for code or document generation
RT CRUD Standards: Development prompts following Rongtong backend standards
Feishu Integration: Specialized prompts for Feishu-related use cases
Provides specialized prompt suggestions for MySQL database design and development tasks
Offers tailored prompt suggestions for PostgreSQL database design and development
Delivers frontend-specific prompt suggestions optimized for React framework development
Click on "Deploy 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., "@RT-Prompt-MCP get backend suggestions for creating a user authentication API with Node.js and MongoDB"
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.
RT-Prompt-MCP 是一个基于 Model Context Protocol (MCP) 的服务器，专注于提供开发和设计相关的提示词补充建议。
提供特定领域的提示词补充，帮助 LLM 生成更符合要求的内容
支持后端开发、前端开发和通用场景的提示词
易于集成到支持 MCP 协议的客户端
使用 TypeScript 开发，类型安全
Related MCP server: Git Prompts MCP Server
To install rt-prompt-mcp-server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @yuyao1999/rt-prompt-mcp-server --client claude全局安装:
npm install -g rt-prompt-mcp安装后，直接运行:
rt-prompt-mcp在支持 MCP 协议的应用中（如 Claude Desktop）配置:
{
"mcpServers": {
"rt-prompt-mcp": {
"command": "rt-prompt-mcp",
"args": []
}
}
}该 MCP Server 提供五个主要工具:
get_backend_suggestions: 获取后端开发相关的提示词补充
context: 当前上下文或任务描述
databaseType: 数据库类型（如 MySQL、PostgreSQL 等）
language: 编程语言（如 Java、Python 等）
get_frontend_suggestions: 获取前端开发相关的提示词补充
context: 当前上下文或任务描述
framework: 前端框架（如 React、Vue 等）
deviceType: 设备类型（如移动端、桌面端等）
get_general_suggestions: 获取通用场景的提示词补充
context: 当前上下文或任务描述
taskType: 任务类型（如代码生成、文档生成等）
get_ui_design_suggestions: 获取 UI 设计图转化相关的提示词补充
context: 当前上下文或任务描述
designType: 设计类型（如线框图、高保真原型图等）
platform: 平台类型（如 Web、iOS、Android 等）
get_rt_crud_suggestions: 获取荣通后端标准 CRUD 开发规范提示词。
base_path (可选): Java/Kotlin 根包路径，例如 'com.example.myapp' 或 'cn.teamy'。如果提供，将替换提示中默认的 'cn.teamy'。请使用点分隔路径。
get_feishu_prompt: 获取飞书相关的提示词
prompt_name: 提示词名称，如'UI 转化提示词'、'AI 生成 UI-3D 风格'等
例如，要获取 MySQL 数据库设计的建议:
使用 get-backend-suggestions 工具，并提供以下参数:
- context: "创建用户和订单的数据库表结构"
- databaseType: "MySQL"
- language: "SQL"Node.js 16+
npm 或 yarn
克隆仓库:
git clone https://github.com/yourusername/rt-prompt-mcp.git
cd rt-prompt-mcp安装依赖:
npm install构建项目:
npm run build本地测试:
npm startMIT
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | 当前上下文或任务描述 | |
| databaseType | No | 数据库类型，如MySQL、PostgreSQL等 | |
| language | No | 编程语言，如Java、Python等 |
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 | 提示词名称，如'UI转化提示词'、'AI生成UI-3D风格'等 |
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 |
|---|---|---|---|
| context | No | 当前上下文或任务描述 | |
| deviceType | No | 设备类型，如移动端、桌面端等 | |
| framework | No | 前端框架，如React、Vue等 |
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 |
|---|---|---|---|
| context | No | 当前上下文或任务描述 | |
| taskType | No | 任务类型，如代码生成、文档生成等 |
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 |
|---|---|---|---|
| base_path | No | 可选的 Java/Kotlin 根包路径，例如 'com.example.myapp' 或 'cn.teamy'。如果提供，将替换提示中默认的 'cn.teamy'。请使用点分隔。 |
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 |
|---|---|---|---|
| context | No | 当前上下文或任务描述 | |
| designType | No | 设计类型，如线框图、高保真原型图等 | |
| platform | No | 平台类型，如Web、iOS、Android等 |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_backend_suggestionsget_feishu_promptget_frontend_suggestionsget_general_suggestionsget_rt_crud_suggestionsget_ui_design_suggestionsScored across 6 tools
The tools are clearly distinguished by their target domains (backend, frontend, general, RT-CRUD, UI design, Feishu), making misselection unlikely. However, the lack of descriptions means the exact boundaries between 'general' and domain-specific suggestions are unclear, which could cause minor confusion.
All tools follow a perfect 'get_[domain]_suggestions' pattern, with consistent snake_case and verb-noun structure. This predictability makes it easy for agents to understand and use the toolset without naming-related errors.
Six tools is a reasonable number for a prompt suggestion server, covering multiple domains without being overwhelming. It could be slightly thin if more granular domains are needed, but the scope appears well-defined for common development areas.
The toolset is severely incomplete as it only provides 'get' operations with no ability to create, update, delete, or manage prompts. For a prompt management server, this represents significant gaps that will limit agent workflows and cause dead ends in multi-step tasks.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
MCP server for AI agent profiles and smart notes. 60+ coding prompt packs with expert personas.
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
