Skip to main content
Glama
xXMSGXx

PromptArchitect MCP

by xXMSGXx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

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

Related

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

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 that the tool returns scores (0-100) for clarity, specificity, structure, and actionability, which adds behavioral context beyond basic functionality. However, it does not cover other traits like error handling, performance, or limitations, leaving gaps in transparency for a tool with no annotation support.

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: it starts with a clear purpose statement, followed by bullet points for usage guidelines and a summary of return values. Every sentence earns its place by adding value without redundancy, making it efficient and well-structured.

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, no annotations, and no output schema, the description does a good job by explaining the purpose, usage, and return values. It covers key aspects like what the tool does and what it outputs, but lacks details on error cases or advanced behavioral traits, which would be needed for full completeness in the absence of structured data.

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.' The description does not add any meaning beyond this, such as explaining what constitutes a 'prompt' or detailing the criteria options. With high schema coverage, the baseline is 3, as the description provides no extra parameter insights.

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: 'Evaluate prompt quality and get actionable improvement suggestions.' It specifies the verb 'evaluate' and resource 'prompt quality,' but does not explicitly differentiate it from sibling tools like 'refine_prompt' or 'generate_prompt,' which might involve similar prompt-related tasks. This makes it clear but not fully distinct from alternatives.

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 usage contexts with bullet points: 'Assess if a prompt is well-structured,' 'Identify weaknesses before using a prompt,' 'Get specific suggestions for improvement,' and 'Compare prompt quality before/after refinement.' It gives explicit when-to-use guidance but does not mention when not to use it or name specific alternatives like 'refine_prompt,' which could be a follow-up action.

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 template support, but lacks details on output format, potential limitations (e.g., length constraints), error handling, or performance characteristics. It provides some context about workspace alignment but doesn't fully compensate for the missing annotation coverage.

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?

The description is well-structured with clear sections: purpose statement, usage bullet points, template list, and important note. It's appropriately sized for a 5-parameter tool, though the template list could be more concise. Every sentence adds value, but minor trimming is possible.

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 context but lacks details about the transformation output, error cases, or behavioral constraints. It's adequate for basic understanding but leaves gaps about what the tool actually produces.

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 parameters are well-documented in the schema. The description adds minimal value beyond the schema: it mentions template types and workspace context importance, but doesn't explain parameter interactions or provide additional semantic context. Baseline 3 is appropriate given the comprehensive schema.

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: 'Transform a raw idea into a well-structured, actionable prompt optimized for AI assistants.' It uses specific verbs ('transform', 'optimize') and distinguishes from sibling tools 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?

The description provides explicit usage scenarios: 'Create a new prompt from scratch', 'Structure a vague idea into a clear request', and 'Generate role-specific prompts'. It also implicitly distinguishes from siblings by not mentioning analysis or refinement, and includes an 'IMPORTANT' note about when to provide workspace context.

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

A4.1/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 describes what information the tool returns (AI availability, cache metrics, latency), which is helpful behavioral context. However, it does not disclose potential limitations like rate limits, authentication requirements, or whether this is a read-only operation, 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 well-structured and concise, with a clear opening sentence stating the purpose followed by a bulleted list of specific checks. Every sentence earns its place by adding value without redundancy.

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 complexity (simple status check with no parameters) and lack of annotations/output schema, the description is adequate but has gaps. It explains what metrics are returned, which is good, but does not cover behavioral aspects like safety or performance implications, making it minimally viable rather than fully complete.

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 does not discuss parameters, focusing instead on the tool's purpose and outputs. A baseline of 4 is applied for zero-parameter tools, as it efficiently avoids unnecessary details.

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 ('Get', 'check') and resources ('server status and performance metrics'). It distinguishes itself from sibling tools (analyze_prompt, generate_prompt, refine_prompt) by focusing on system monitoring rather than prompt operations.

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 ('to check' AI availability, cache statistics, and latency). However, it does not explicitly state when NOT to use it or name specific alternatives among the sibling tools, which would be needed for a perfect score.

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 and does well by disclosing key behavioral traits: it's an iterative improvement tool, preserves original structure by default, and requires workspace context for project compliance. However, it doesn't mention potential side effects like rate limits 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, followed by usage guidelines and important context. Every sentence earns its place: the first states the purpose, the bulleted list provides clear usage scenarios, and the IMPORTANT section adds necessary project-specific guidance 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?

For a 5-parameter tool with no annotations and no output schema, the description provides good contextual completeness with clear purpose, usage guidelines, and behavioral context. It could be improved by mentioning what the refined prompt output looks like or any limitations, but covers most essential aspects well.

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 some value by explaining workspace context usage ('ensure refined prompts comply with project scope') and mentioning structure preservation, but doesn't provide significant additional parameter semantics beyond what's already documented in the schema.

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 ('iteratively improve', 'refine') and resources ('existing prompt'), distinguishing it from siblings like analyze_prompt (analysis) and generate_prompt (creation). It explicitly mentions applying targeted improvements based on feedback.

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 when-to-use guidance with four bulleted scenarios (e.g., 'Improve a prompt that didn't get good results', 'Adapt a prompt for a different AI model'), clearly differentiating from sibling tools. It also includes an IMPORTANT section about when to pass workspace context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.0
    • First observedanalyze_prompt
    • First observedgenerate_prompt
    • First observedget_server_status
    • First observedrefine_prompt
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 4 tools

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

Related MCP Connectors

Appeared in Searches