PromptArchitect MCP
Provides workspace-aware prompt engineering tools within Android Studio for refining, analyzing, and generating prompts tailored to Android development projects.
Enables prompt refinement and analysis within CLion for C/C++ projects, considering project structure and dependencies.
Enables prompt refinement and generation within Windsurf IDE, leveraging project context to improve AI-assisted coding prompts.
Provides prompt engineering tools within DataGrip for database-related tasks, offering context-aware prompt refinement.
Integrates prompt engineering tools into VS Code's GitHub Copilot chat interface, enabling context-aware prompt refinement and analysis for coding tasks.
Integrates workspace-aware prompt refinement and generation into GoLand for Go development projects.
Integrates AI-powered prompt refinement and analysis tools into IntelliJ IDEA, considering project tech stack and structure for improved prompt quality.
Provides prompt engineering tools within PhpStorm for refining and generating prompts specific to PHP development contexts.
Offers prompt engineering capabilities within PyCharm, providing context-aware prompt refinement and generation for Python development workflows.
Integrates AI-powered prompt refinement into Rider for .NET development, tailoring prompts to project context and conventions.
Offers prompt engineering capabilities within RubyMine, providing context-aware refinement for Ruby development workflows.
Enables prompt refinement and analysis within WebStorm, tailoring prompts to JavaScript/TypeScript projects and their dependencies.
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., "@PromptArchitect MCPrefine this prompt for generating a React component"
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.
@merabylabs/promptarchitect-mcp
A Model Context Protocol (MCP) server that refines your prompts using PromptArchitect's AI-powered prompt engineering. Simply pass your current prompt and get an improved version back.
Works with: Claude Desktop • VS Code (Copilot) • Cursor • Windsurf • Zed • JetBrains IDEs • Continue.dev • Cline
✨ Why PromptArchitect MCP?
🎯 Workspace-Aware Refinement
Unlike generic prompt tools, PromptArchitect understands your project context. When refining prompts, it considers:
Your tech stack — React, Node, Python, or whatever you're building with
Project structure — File organization, naming conventions, architecture patterns
Dependencies — Libraries and frameworks from your package.json/requirements.txt
Your original request — Ensures refined prompts stay aligned with your actual goal
This means prompts are tailored to your specific codebase, not generic boilerplate.
🚀 Key Benefits
No API key required — Free to use, powered by PromptArchitect backend
Works in your IDE — Integrates with your existing workflow via MCP
Context-aware — Prompts that understand your project conventions
Iterative refinement — Keep improving until it's perfect
Features
🛠️ Tools
Tool | Description |
| Improve your current prompt based on feedback and your workspace context |
| Evaluate prompt quality with scores and improvement suggestions |
| Transform a raw idea into a well-structured prompt tailored to your project |
📦 Resources
Template Library: Reference templates for coding, writing, research, and analysis tasks
Category Collections: Browse templates by category for inspiration
Installation
npm install @merabylabs/promptarchitect-mcpOr install globally:
npm install -g @merabylabs/promptarchitect-mcpUsage
PromptArchitect MCP server works with any IDE or application that supports the Model Context Protocol. Below are configuration examples for popular editors.
No API key required! The MCP server uses the PromptArchitect backend API, so you don't need your own Gemini API key.
Claude Desktop
Add to your Claude Desktop configuration file:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"promptarchitect": {
"command": "npx",
"args": ["@merabylabs/promptarchitect-mcp"]
}
}
}VS Code (GitHub Copilot)
Add to your VS Code settings.json (Cmd/Ctrl+Shift+P → "Preferences: Open Settings (JSON)"):
{
"github.copilot.chat.mcp.servers": {
"promptarchitect": {
"command": "npx",
"args": ["@merabylabs/promptarchitect-mcp"]
}
}
}Cursor
Add to your Cursor MCP settings:
macOS/Linux:
~/.cursor/mcp.jsonWindows:
%USERPROFILE%\.cursor\mcp.jsonOr via: Settings → MCP
{
"mcpServers": {
"promptarchitect": {
"command": "npx",
"args": ["@merabylabs/promptarchitect-mcp"]
}
}
}Windsurf (Codeium)
Add to your Windsurf MCP configuration:
macOS/Linux:
~/.codeium/windsurf/mcp_config.jsonWindows:
%USERPROFILE%\.codeium\windsurf\mcp_config.json
{
"mcpServers": {
"promptarchitect": {
"command": "npx",
"args": ["@merabylabs/promptarchitect-mcp"]
}
}
}Zed
Add to your Zed settings:
macOS:
~/.config/zed/settings.jsonLinux:
~/.config/zed/settings.json
{
"context_servers": {
"promptarchitect": {
"command": {
"path": "npx",
"args": ["@merabylabs/promptarchitect-mcp"]
},
"settings": {}
}
}
}JetBrains IDEs
Works with IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, GoLand, RubyMine, CLion, DataGrip, Rider, Android Studio.
Install the MCP Client plugin from JetBrains Marketplace
Go to Settings → Tools → MCP Servers
Add a new server with this configuration:
{
"mcpServers": {
"promptarchitect": {
"command": "npx",
"args": ["@merabylabs/promptarchitect-mcp"]
}
}
}Or add to .idea/mcp.json in your project.
Continue.dev
Add to your Continue configuration:
Global:
~/.continue/config.jsonProject:
.continue/config.json
{
"experimental": {
"modelContextProtocolServers": [
{
"transport": {
"type": "stdio",
"command": "npx",
"args": ["@merabylabs/promptarchitect-mcp"]
}
}
]
}
}Cline (VS Code Extension)
Open Cline Settings → MCP Servers, or edit cline_mcp_settings.json:
{
"mcpServers": {
"promptarchitect": {
"command": "npx",
"args": ["@merabylabs/promptarchitect-mcp"],
"disabled": false
}
}
}Other MCP-Compatible Applications
Any application supporting MCP can use this server. The standard configuration is:
Property | Value |
Command |
|
Args |
|
For global installation, use promptarchitect-mcp as the command after running:
npm install -g @merabylabs/promptarchitect-mcpProgrammatic Usage
import { refinePrompt, analyzePrompt } from '@promptarchitect/mcp-server';
// Refine an existing prompt
const result = await refinePrompt({
prompt: 'Write code to sort an array',
feedback: 'Make it more specific about language and edge cases',
});
console.log(result.refinedPrompt);
// => "Write a TypeScript function that sorts an array of numbers..."
// Analyze prompt quality
const analysis = await analyzePrompt({
prompt: 'Help me with my code',
});
console.log(analysis.scores); // { overall: 45, clarity: 50, ... }
console.log(analysis.suggestions); // ["Be more specific about...", ...]Configuration
Environment Variables
Variable | Required | Description |
| No | Logging level: |
Tool Reference
refine_prompt
Improve an existing prompt based on feedback. This is the primary tool.
Input:
{
"prompt": "Write code",
"feedback": "Make it more specific and add examples",
"preserveStructure": true
}Output:
{
"refinedPrompt": "Write a TypeScript function that...",
"changes": ["Added specificity", "Included example"],
"metadata": {
"originalWordCount": 2,
"refinedWordCount": 45
}
}analyze_prompt
Evaluate prompt quality and get improvement suggestions.
Input:
{
"prompt": "You are a helpful assistant. Help me write code."
}Output:
{
"scores": {
"overall": 65,
"clarity": 70,
"specificity": 50,
"structure": 60,
"actionability": 80
},
"suggestions": [
"Add more specific details about the code",
"Include examples of expected output"
],
"strengths": ["Clear action verb"],
"weaknesses": ["Lacks specificity"]
}generate_prompt
Transform a raw idea into a well-structured prompt.
Input:
{
"idea": "Create a code review assistant",
"template": "coding",
"context": "For TypeScript projects"
}Output:
{
"prompt": "You are a senior code reviewer...",
"metadata": {
"template": "coding",
"wordCount": 150,
"hasStructure": true
}
}Development
Building
npm install
npm run buildTesting
npm testRunning Locally
npm startArchitecture
mcp-server/
├── src/
│ ├── tools/ # MCP tools (refine, analyze, generate)
│ ├── resources/ # Template library for reference
│ ├── utils/ # Gemini client, logger
│ ├── server.ts # MCP server configuration
│ ├── cli.ts # CLI entry point
│ └── index.ts # Main exports
└── examples/ # Configuration examplesLicense
Proprietary - © 2025 Meraby Labs. All rights reserved.
This software is provided for use exclusively with the PromptArchitect service. Unauthorized copying, modification, distribution, or use outside the intended scope is prohibited.
Related
PromptArchitect - Full web application
Model Context Protocol - MCP specification
MCP TypeScript SDK - SDK used by this server
Available Tools
4 toolsanalyze_promptA
Evaluate prompt quality and get actionable improvement suggestions.
Use this tool when you need to: • Assess if a prompt is well-structured • Identify weaknesses before using a prompt • Get specific suggestions for improvement • Compare prompt quality before/after refinement
Returns scores (0-100) for: clarity, specificity, structure, actionability.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The prompt to analyze. | |
| evaluationCriteria | No | Specific criteria to evaluate. Default: all criteria. |
TDQS
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 discloses key behavioral traits such as returning scores for specific criteria (clarity, specificity, structure, actionability) and providing improvement suggestions, which adds value beyond basic function. However, it lacks details on limitations, error handling, or performance aspects, leaving some behavioral context unspecified.
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 well-structured and front-loaded with the core purpose, followed by a bulleted list of usage guidelines and return value details. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.
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 moderate complexity (2 parameters, no output schema), the description is mostly complete: it covers purpose, usage, and return values. However, without annotations or an output schema, it could benefit from more details on behavioral constraints or error cases, slightly limiting completeness for an analysis tool.
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 description coverage is 100%, so the schema already documents both parameters ('prompt' and 'evaluationCriteria') adequately. The description does not add any parameter-specific semantics beyond what the schema provides, such as examples or usage nuances, resulting in a baseline score of 3 where the schema handles the heavy lifting.
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 tool's purpose with specific verbs ('evaluate prompt quality', 'get actionable improvement suggestions') and distinguishes it from siblings like 'generate_prompt' and 'refine_prompt' by focusing on analysis rather than creation or refinement. It explicitly mentions what the tool does without being tautological.
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?
The description provides explicit usage scenarios in a bulleted list, including when to use it (e.g., 'assess if a prompt is well-structured', 'identify weaknesses before using a prompt') and implicitly when not to use it by contrasting with siblings like 'generate_prompt' for creation. It offers clear alternatives and context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_promptA
Transform a raw idea into a well-structured, actionable prompt optimized for AI assistants.
Use this tool when you need to: • Create a new prompt from scratch • Structure a vague idea into a clear request • Generate role-specific prompts (coding, writing, research, etc.)
Supports templates: coding (for programming tasks), writing (for content creation), research (for investigation), analysis (for data/business analysis), factcheck (for verification), general (versatile).
IMPORTANT: When available, pass workspace context (file structure, package.json, tech stack) to generate prompts that align with the user's project.
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | The raw idea or concept to transform into a prompt. Can be brief or detailed. | |
| template | No | Template type to use. Default: auto-detected from idea or "general". | |
| context | No | Additional context like domain, constraints, or preferences. | |
| targetModel | No | Target AI model for optimization. Default: "general". | |
| workspaceContext | No | Project context to ensure the prompt aligns with the codebase. Include: file/folder structure, package.json dependencies, tech stack (React, Node, etc.), relevant code snippets, and the original user request. This helps generate prompts that comply with project conventions. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes the transformation behavior and mentions template support, but lacks details about rate limits, authentication needs, error conditions, or what the output looks like. It provides basic behavioral context but could be more comprehensive.
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?
Well-structured with clear sections (purpose, usage scenarios, template support, important note). Front-loaded with core purpose. Could be slightly more concise by combining some bullet points, but overall efficient with minimal waste.
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 5-parameter tool with no annotations and no output schema, the description provides good purpose and usage guidance but lacks details about output format, error handling, and behavioral constraints. It's adequate but has clear gaps given the tool's complexity.
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 description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description mentions templates and workspace context, adding some semantic context, but doesn't provide significant additional parameter meaning beyond what's in the schema descriptions.
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 tool's purpose with specific verbs ('transform', 'generate') and resources ('raw idea', 'prompt'), distinguishing it from siblings like analyze_prompt and refine_prompt by focusing on creation from scratch rather than analysis or refinement.
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?
Explicitly provides when-to-use scenarios ('create from scratch', 'structure vague idea', 'generate role-specific prompts') and mentions workspace context as important when available, giving clear guidance on appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_server_statusA
Get PromptArchitect server status and performance metrics.
Use this tool to check: • Whether AI (Gemini) is available • Cache hit rate and request statistics • Average response latency
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 discloses behavioral traits by listing what metrics are checked (AI availability, cache hit rate, request statistics, latency), which adds useful context beyond a basic 'get status' statement. However, it doesn't cover aspects like rate limits, authentication needs, or error handling, leaving some gaps.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a bulleted list for specific checks. Every sentence earns its place by providing essential information without waste, making it highly efficient.
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 low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete for a status-checking tool. It explains what metrics are returned, which compensates for the lack of output schema. However, it could be more comprehensive by including details like response format or error cases, keeping it at an adequate but not exceptional level.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage. This meets the baseline for 0 parameters, but since it doesn't add any parameter-specific value beyond the schema, it's not a 5.
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 tool's purpose: 'Get PromptArchitect server status and performance metrics.' It specifies the verb 'Get' and the resource 'server status and performance metrics.' However, it doesn't explicitly differentiate from sibling tools (analyze_prompt, generate_prompt, refine_prompt), which are unrelated to server status, so it's not a perfect 5.
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?
The description provides clear context for when to use the tool: 'Use this tool to check:' followed by specific metrics. It implies usage for monitoring server health and performance. However, it doesn't explicitly state when not to use it or name alternatives, which prevents a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refine_promptA
Iteratively improve an existing prompt based on specific feedback.
Use this tool when you need to: • Improve a prompt that didn't get good results • Add missing context or constraints • Make a prompt more specific or clearer • Adapt a prompt for a different AI model
The tool preserves the original structure while applying targeted improvements.
IMPORTANT: When available, pass workspace context (file structure, package.json, tech stack) to ensure refined prompts comply with the user's project scope and original request.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The current prompt to refine. | |
| feedback | Yes | What should be improved. Examples: "make it more specific", "add error handling requirements", "focus on performance". | |
| preserveStructure | No | Whether to keep the original structure. Default: true. | |
| targetModel | No | Target AI model for optimization. | |
| workspaceContext | No | Project context to ensure the refined prompt aligns with the codebase. Include: file/folder structure, package.json dependencies, tech stack (React, Node, etc.), relevant code snippets, and the original user request. This ensures the refined prompt complies with project conventions and scope. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: 'preserves the original structure while applying targeted improvements' and emphasizes the importance of workspace context for compliance. However, it doesn't mention potential limitations like rate limits, error handling, or authentication needs.
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 well-structured and front-loaded with the core purpose. Each sentence adds value: the first states the purpose, the bulleted list provides usage guidelines, and the final sentences add important behavioral context without redundancy.
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 no annotations and no output schema, the description does a good job covering purpose, usage, and some behavioral context. However, it could better address what the refined prompt output looks like or any constraints on the refinement process to be fully complete.
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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema, mentioning workspace context importance but not elaborating on other parameters like feedback examples or target model implications.
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 tool's purpose: 'Iteratively improve an existing prompt based on specific feedback.' It uses specific verbs ('improve', 'add', 'make', 'adapt') and distinguishes from sibling tools like analyze_prompt and generate_prompt by focusing on refinement rather than analysis or generation.
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?
The description provides explicit usage scenarios in a bulleted list: 'when you need to: • Improve a prompt that didn't get good results • Add missing context or constraints • Make a prompt more specific or clearer • Adapt a prompt for a different AI model.' This clearly differentiates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose with no overlap: analyze_prompt evaluates quality, generate_prompt creates new prompts, get_server_status checks system metrics, and refine_prompt iteratively improves existing prompts. The descriptions explicitly differentiate their use cases, making misselection unlikely.
All tool names follow a consistent verb_noun pattern using snake_case: analyze_prompt, generate_prompt, get_server_status, and refine_prompt. This predictable naming scheme enhances readability and agent usability.
With 4 tools, the server is well-scoped for prompt engineering tasks. Each tool earns its place by covering distinct aspects of the domain: analysis, generation, refinement, and system monitoring, without being overly sparse or bloated.
The tool set provides strong coverage for core prompt engineering workflows, including creation, evaluation, and refinement. A minor gap exists in lacking a tool for deleting or managing saved prompts, but agents can work around this, and the surface supports most common operations effectively.
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
Manage, version, and publish LLM prompts with blocks, variables, and evaluations.
Your prompt library inside your AI: 1,000+ pro templates, frameworks, vocab & pipelines.
PQS scores any prompt before the model runs. 8 dimensions. 5 frameworks. Pre-flight, not post-hoc.
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
Appeared in Searches
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/xXMSGXx/promptarchitect-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server