Skip to main content
Glama
tisu19021997

Meta Prompt MCP Server

by tisu19021997
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Meta Prompt MCP

This project is an implementation of the Meta-Prompting technique from the paper "Meta-Prompting: Enhancing Language Models with Task-Agnostic Scaffolding".

At its core, this MCP transforms a standard Language Model (LM) into a dynamic, multi-agent system without the complex setup. It works by having the LM adopt two key roles:

  1. The Conductor: A high-level project manager that analyzes a complex problem, breaks it down into smaller, logical subtasks, and delegates them.

  2. The Expert: Specialized agents (e.g., "Python Programmer," "Code Reviewer," "Creative Writer") that are "consulted" by the Conductor to execute each subtask.

The magic is that this entire collaborative workflow is simulated within a single LM. The Conductor and Experts are different modes of operation guided by a sophisticated system prompt, allowing the model to reason, act, and self-critique its way to a more robust and accurate solution. It's like having an automated team of AI specialists at your disposal, all powered by one model.

Demo

Demo Video

Related MCP server: OpenRouter Agents MCP Server

Getting Started

1. Clone the Repository

First, clone this repository to your local machine.

git clone https://github.com/tisu19021997/meta-prompt-mcp-server.git .
cd meta-prompt-mcp-server

2. Install uv

This project uses uv, an extremely fast Python package manager from Astral. If you don't have it installed, you can do so with one of the following commands.

Note: use which uv to know the path of your uv installation.

macOS / Linux:

curl -LsSf https://astral.sh/uv/install.sh | sh

Windows (PowerShell):

powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

For more details, see the official uv installation guide.

Usage

To use this Meta Prompt MCP server, you need to configure your client (e.g., Cursor, Claude Desktop) to connect to it. Make sure to replace the placeholder paths with the actual paths on your machine.

Cursor

Add the following configuration to your mcp.json settings:

"meta-prompting": {
  "command": "path/to/your/uv",
  "args": [
    "--directory",
    "path/to/your/meta-prompt-mcp",
    "run",
    "mcp-meta-prompt"
  ]
}

Claude Desktop

Add the following configuration to your claude_desktop_config.json settings:

"meta-prompting": {
  "command": "path/to/your/uv",
  "args": [
    "--directory",
    "path/to/your/meta-prompt-mcp",
    "run",
    "mcp-meta-prompt"
  ]
}

Activating the Meta-Prompt Workflow

Important: To leverage the full power of this MCP, always start your request by invoking the meta_model_prompt (then fill in the query with your prompt, see Demo video) from the meta-prompting server. This is the official entry point that activates the Conductor/Expert workflow. Once the prompt is added, simply provide your problem statement.

How it Differs from the Paper

The core methodology in the original paper involves a two-step process for expert consultation:

  1. The "conductor" model generates instructions for an expert.

  2. A separate, independent LM instance (the "expert") is invoked with only those instructions to provide a response. This ensures the expert has "fresh eyes."

This implementation simplifies the process into a single LLM call. The conductor model generates the expert's name, instructions, and the expert's complete output within a single tool call. This is a significant difference that makes the process faster and less expensive, but it deviates from the "fresh eyes" principle of the original research.

Limitations

The expert_model tool in this MCP server is designed to use the ctx.sample() function to properly simulate a second, independent expert model call as described in the paper. However, this function is not yet implemented in most MCP clients (such as Cursor and Claude Desktop).

Due to this limitation, the server includes a fallback mechanism. When ctx.sample() is unavailable, the expert_model tool simply returns the output content that was generated by the conductor model in the tool call. This means the expert's response is part of the conductor's single generation, rather than a true, independent consultation.

Comparison

Below is two conversations I asked Claude to implement the Meta Prompt MCP Server itself, with and without Meta Prompt MCP.

Some artifacts are missing from the conversation but you could see the implementation with Meta Prompt MCP is much better, and it also did kind of "self-reviewing" by consulting a QA expert.

References

Available Tools

2 tools
expert_modelC

Use this tool to communicate with an expert.

Args: name: The name of the expert to communicate with. Required. instructions: The instructions to send to the expert. Required. output: The answer from the expert based on the instructions. Required. iteration: The number of experts you have consulted so far. Start with 1.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
instructionsYes
outputYes
iterationYes

TDQS

C2.4/5.0
Behavior2/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 mentions 'communicate with an expert' and describes parameters, but doesn't disclose behavioral traits such as what the tool does (e.g., sends instructions, receives output), potential side effects, authentication needs, rate limits, or response format. The description is too minimal to compensate for the lack of annotations, leaving key behaviors unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a brief purpose statement and parameter list, but it's not optimally structured. The purpose is front-loaded, but the parameter explanations are minimal and could be more informative. It avoids waste, but given the complexity, it feels under-specified rather than efficiently concise, earning a baseline score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 parameters, no annotations, no output schema, 0% schema coverage), the description is incomplete. It doesn't explain what the tool returns, how 'output' is used as an input, or the interaction flow with the expert. The lack of behavioral details and minimal parameter semantics makes it inadequate for proper tool invocation, especially without structured support.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It lists parameters with brief explanations (e.g., 'name: The name of the expert to communicate with'), but these are basic and don't add significant meaning beyond what the schema titles imply. For example, 'output' is described as 'The answer from the expert based on the instructions', which clarifies it's an input parameter for the answer, but overall, the semantics are insufficient for a 4-parameter tool with no schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Use this tool to communicate with an expert' which provides a basic purpose, but it's vague about what 'communicate' entails (e.g., querying, consulting, getting advice). It doesn't differentiate from the sibling tool 'ready_to_answer', leaving ambiguity about when to use each. The purpose is clear enough to understand the general function but lacks specificity and sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus the sibling 'ready_to_answer' or any alternatives. It includes a note about iteration ('Start with 1'), which hints at usage in a sequence, but this is more of a parameter instruction than contextual guidance. There's no explicit when/when-not or alternative usage advice, making it minimally helpful for selection.

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

ready_to_answerB

Use this tool when you already obtained or verified the final solution with at least two independent experts and are ready to present your final answer.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior2/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 of behavioral disclosure. It mentions that the tool is used when 'ready to present your final answer,' implying it might trigger a submission or output action, but it doesn't describe what the tool actually does behaviorally (e.g., whether it logs, notifies, or finalizes). This leaves significant gaps in understanding the tool's effects.

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 a single, clear sentence that efficiently states the usage condition without unnecessary details. It is front-loaded with the key information and has zero wasted words, making it highly concise and well-structured.

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 has no parameters, no annotations, and no output schema, the description provides basic context about when to use it. However, it lacks details on what the tool does (e.g., behavioral outcomes or return values), which is a gap for a tool that likely triggers a significant action like finalizing an answer. This makes it minimally adequate but incomplete.

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, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters, as it doesn't have to compensate for any gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool is used when 'ready to present your final answer,' which indicates its purpose is to signal completion of a verification process. However, it doesn't specify what action the tool performs (e.g., submits, logs, or finalizes the answer), making it somewhat vague. It distinguishes from sibling 'expert_model' by focusing on answer presentation rather than expert consultation.

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 explicitly states when to use this tool: 'when you already obtained or verified the final solution with at least two independent experts.' This provides clear context and prerequisites. However, it doesn't mention when not to use it or explicitly compare to alternatives like 'expert_model,' which could be used for obtaining expert input instead.

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. 2 tool updates
    • First observedexpert_model
    • First observedready_to_answer
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: expert_model is for consulting experts and obtaining their responses, while ready_to_answer is for signaling completion after verification with multiple experts. There is no overlap in functionality, making it impossible to confuse them.

Naming Consistency3/5

The naming is mixed: expert_model uses snake_case but is a noun-based name, while ready_to_answer uses snake_case with a verb phrase. There is no consistent verb_noun pattern, but both names are readable and descriptive of their functions.

Tool Count2/5

With only 2 tools, the server feels under-scoped for a 'Meta Prompt' purpose, which suggests broader capabilities. The tools cover a narrow workflow (consult experts and signal readiness), lacking operations like managing experts, tracking iterations, or handling errors, making the set feel incomplete for the domain.

Completeness2/5

Inferred domain is meta-prompting or expert consultation, but there are significant gaps: no tools to list available experts, modify expert instructions, handle errors in consultations, or manage the consultation process beyond the two provided steps. This will likely cause agent failures when trying to perform full workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches