Skip to main content
Glama
xXMSGXx
by xXMSGXx

@merabylabs/promptarchitect-mcp

npm version MCP Compatible

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

refine_prompt

Improve your current prompt based on feedback and your workspace context

analyze_prompt

Evaluate prompt quality with scores and improvement suggestions

generate_prompt

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-mcp

Or install globally:

npm install -g @merabylabs/promptarchitect-mcp

Usage

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.json

  • Windows: %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.json

  • Windows: %USERPROFILE%\.cursor\mcp.json

  • Or via: Settings → MCP

{
  "mcpServers": {
    "promptarchitect": {
      "command": "npx",
      "args": ["@merabylabs/promptarchitect-mcp"]
    }
  }
}

📖 Cursor MCP Documentation


Windsurf (Codeium)

Add to your Windsurf MCP configuration:

  • macOS/Linux: ~/.codeium/windsurf/mcp_config.json

  • Windows: %USERPROFILE%\.codeium\windsurf\mcp_config.json

{
  "mcpServers": {
    "promptarchitect": {
      "command": "npx",
      "args": ["@merabylabs/promptarchitect-mcp"]
    }
  }
}

📖 Windsurf MCP Documentation


Zed

Add to your Zed settings:

  • macOS: ~/.config/zed/settings.json

  • Linux: ~/.config/zed/settings.json

{
  "context_servers": {
    "promptarchitect": {
      "command": {
        "path": "npx",
        "args": ["@merabylabs/promptarchitect-mcp"]
      },
      "settings": {}
    }
  }
}

📖 Zed MCP Documentation


JetBrains IDEs

Works with IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, GoLand, RubyMine, CLion, DataGrip, Rider, Android Studio.

  1. Install the MCP Client plugin from JetBrains Marketplace

  2. Go to Settings → Tools → MCP Servers

  3. Add a new server with this configuration:

{
  "mcpServers": {
    "promptarchitect": {
      "command": "npx",
      "args": ["@merabylabs/promptarchitect-mcp"]
    }
  }
}

Or add to .idea/mcp.json in your project.

📖 JetBrains MCP Plugin


Continue.dev

Add to your Continue configuration:

  • Global: ~/.continue/config.json

  • Project: .continue/config.json

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "npx",
          "args": ["@merabylabs/promptarchitect-mcp"]
        }
      }
    ]
  }
}

📖 Continue MCP Documentation


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
    }
  }
}

📖 Cline MCP Documentation


Other MCP-Compatible Applications

Any application supporting MCP can use this server. The standard configuration is:

Property

Value

Command

npx

Args

["@merabylabs/promptarchitect-mcp"]

For global installation, use promptarchitect-mcp as the command after running:

npm install -g @merabylabs/promptarchitect-mcp

Programmatic 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

LOG_LEVEL

No

Logging level: debug, info, warn, error. Default: info

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 build

Testing

npm test

Running Locally

npm start

Architecture

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 examples

License

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.

Available Tools

4 tools
analyze_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe prompt to analyze.
evaluationCriteriaNoSpecific criteria to evaluate. Default: all criteria.

TDQS

A4.2/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 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
ideaYesThe raw idea or concept to transform into a prompt. Can be brief or detailed.
templateNoTemplate type to use. Default: auto-detected from idea or "general".
contextNoAdditional context like domain, constraints, or preferences.
targetModelNoTarget AI model for optimization. Default: "general".
workspaceContextNoProject 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

A4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/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 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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe current prompt to refine.
feedbackYesWhat should be improved. Examples: "make it more specific", "add error handling requirements", "focus on performance".
preserveStructureNoWhether to keep the original structure. Default: true.
targetModelNoTarget AI model for optimization.
workspaceContextNoProject 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

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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

A4.2/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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

Latest Blog Posts

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