Skip to main content
Glama
bacoco

prompt-plus-plus-mcp

by bacoco
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Prompt++ MCP Server

An advanced MCP (Model Context Protocol) server that intelligently enhances prompts using 44+ metaprompt strategies. Features enterprise-grade architecture with caching, performance monitoring, and multiple workflow patterns.

🚀 Key Features

  • 🎯 3-Step Intelligent Workflow: LLM-guided category → strategy → execution pipeline

  • 🧠 44+ Metaprompt Strategies: Comprehensive collection across 5 specialized categories

  • 🤖 Smart Auto-Selection: AI-powered strategy matching with 95%+ accuracy

  • ⚡ High Performance: Sub-millisecond selection with intelligent caching

  • 🛡️ Enterprise Ready: Health monitoring, structured logging, graceful error handling

  • 🔧 Developer Experience: Hot reloading, performance metrics, TypeScript throughout

  • 📦 Zero Dependencies: Completely local execution, no external APIs

  • 🎨 Custom Prompts: Create and use your own prompt strategies alongside built-in ones

  • 📚 Strategy Collections: Create personal collections of favorite strategies for quick access

Related MCP server: Prompt Auto-Optimizer MCP

📦 Quick Start

Installation Options

Option 1: Using npx (Recommended)

No installation needed! Configure Claude Desktop to use npx:

Claude Desktop Configuration: Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "prompt-plus-plus": {
      "command": "npx",
      "args": [
        "-y",
        "prompt-plus-plus-mcp"
      ]
    }
  }
}

Option 2: Global Installation

npm install -g prompt-plus-plus-mcp

Claude Desktop Configuration:

{
  "mcpServers": {
    "prompt-plus-plus": {
      "command": "prompt-plus-plus-mcp"
    }
  }
}

Claude Code

Works automatically with either approach.

🧠 How It Works: The Core Principle

The MCP server ONLY provides prompt templates and metadata. The LLM (Claude) makes ALL decisions about which strategy to use.

This is a Meta-Prompt Server - it doesn't enhance prompts directly. Instead, it provides the LLM with:

  1. All available strategy templates and metadata

  2. Instructions for the LLM to analyze and select

  3. The framework for the LLM to apply enhancements

graph TD
    A[User Prompt] --> B[MCP Server]
    B --> C[Present All Strategies to LLM]
    C --> D[LLM Analyzes & Selects]
    D --> E[LLM Applies Selected Strategy]
    E --> F[Enhanced Prompt]

🎯 What Actually Happens: Step-by-Step Example

Let's walk through what happens when you use Prompt++ to refine a prompt:

Scenario: You want to improve a coding prompt

Your Original Prompt: "Write a function to process user data"

Option 1: Auto-Refinement (Fastest)

Step 1: You ask Claude:

Use auto_refine prompt with user_prompt: "Write a function to process user data"

Step 2: MCP Server sends to Claude:

You are an expert prompt engineer. Your task is to analyze the user's prompt and select the most appropriate strategy from all available options, then apply it.

**User's Prompt:** Write a function to process user data

**Available Strategy Categories & Options:**
{
  "core_strategies": {
    "category": "Core Strategies",
    "description": "Fundamental prompt enhancement approaches",
    "strategies": {
      "star": {
        "name": "ECHO Prompt", 
        "description": "Comprehensive multi-stage refinement",
        "best_for": ["complex tasks", "creative work"],
        "complexity": "high"
      },
      "done": {
        "name": "Done Prompt",
        "description": "Structured approach with role-playing",
        "best_for": ["general tasks", "business problems"],
        "complexity": "medium"
      },
      // ... 8 more strategies
    }
  },
  "software_development": {
    "category": "Software Development",
    "description": "Code and system design focused strategies",
    "strategies": {
      "boomerang": {
        "name": "Boomerang Development",
        "description": "Iterative development with testing cycles",
        "best_for": ["api development", "feature implementation"],
        "triggers": ["iterative", "testing", "development"],
        "complexity": "medium"
      },
      // ... 3 more strategies
    }
  },
  // ... 3 more categories with 30+ more strategies
}

**Your Process:**
1. Analyze the user's prompt
2. Review all available strategies
3. Select the most appropriate strategy
4. Apply the selected strategy

Step 3: Claude (the LLM) Analyzes and Responds:

SELECTED STRATEGY: boomerang (software_development)

REASONING: The user wants to implement a specific algorithm. The Boomerang Development strategy is optimal because:
- It focuses on iterative development with testing
- Perfect for algorithm implementation
- Includes performance considerations
- Emphasizes clean, testable code

REFINED PROMPT:
Create a robust data processing function with the following specifications:

**Core Requirements:**
- Function name: processUserData()
- Input validation for all parameters
- Comprehensive error handling with specific error types
- Return type annotations and documentation

**Implementation Details:**
- Use TypeScript for type safety
- Include input sanitization for security
- Add logging for debugging purposes
- Handle edge cases (null, undefined, empty objects)

**Testing Requirements:**
- Unit tests for valid inputs
- Error case testing
- Performance benchmarks for large datasets
- Integration tests with sample data

**Documentation:**
- JSDoc comments explaining purpose and parameters
- Usage examples with different data types
- Error handling examples

**Quality Assurance:**
- Follow existing code patterns in the project
- Use consistent naming conventions
- Implement defensive programming practices

KEY IMPROVEMENTS:
- Added specific implementation requirements
- Included performance optimization needs
- Specified testing requirements
- Added code quality standards
- Defined clear deliverables

Option 2: 3-Step Intelligent Workflow (Most Precise)

This workflow gives the LLM maximum control at each decision point:

Step 1: Category Selection

Use step1_get_categories prompt with user_prompt: "Write a function to process user data"

MCP Server provides all 5 categories to Claude:

  • Core Strategies (10 strategies)

  • Software Development (4 strategies)

  • AI Core Principles (13 strategies)

  • Vibe Coding Rules (11 strategies)

  • Advanced Thinking (6 strategies)

Claude analyzes and responds:

{
  "selected_category": "software_development",
  "reasoning": "The prompt involves writing code functionality, which aligns with software development practices and requires technical implementation guidance",
  "analysis": "The prompt requests function creation with data processing, indicating need for coding best practices, error handling, and testing considerations"
}

Step 2: Strategy Selection

Use step2_get_strategies prompt with category_name: "software_development" and user_prompt: "Write a function to process user data"

MCP Server provides all Software Development strategies to Claude:

  • architect: System design and architecture

  • boomerang: Iterative development with testing cycles

  • reviewer: Code review and QA frameworks

  • devops: CI/CD and infrastructure automation

Claude reviews and responds:

{
  "selected_strategy": "boomerang",
  "strategy_name": "Boomerang Development",
  "reasoning": "The iterative development approach is optimal for function creation as it emphasizes testing, feedback loops, and incremental improvement - essential for robust data processing",
  "expected_improvements": "Will add comprehensive testing framework, error handling patterns, input validation, and documentation standards"
}

Step 3: Execute Strategy

Use step3_execute_strategy prompt with strategy_key: "boomerang" and user_prompt: "Write a function to process user data"

MCP Server provides the boomerang template to Claude, who applies it to create:

REFINED PROMPT:
Design and implement a data processing function using iterative development methodology:

**Phase 1: Core Implementation**
- Define processUserData() with clear interface
- Implement basic data transformation logic
- Add comprehensive TypeScript types
- Create initial error handling structure

**Phase 2: Testing & Validation**
- Write unit tests before extending functionality
- Test with various data formats (JSON, arrays, objects)
- Validate input sanitization and security measures
- Performance test with realistic datasets

**Phase 3: Refinement & Documentation**
- Refactor based on test feedback
- Add comprehensive JSDoc documentation
- Implement logging and monitoring hooks
- Create usage examples and integration guides

**Quality Gates:**
- All tests must pass before proceeding to next phase
- Code review checklist completion
- Performance benchmarks meet requirements
- Security validation passes

KEY IMPROVEMENTS:
- Structured iterative approach prevents scope creep
- Test-driven development ensures reliability
- Clear phases enable progress tracking
- Quality gates maintain high standards

STRATEGY APPLIED: Boomerang Development

🔑 Key Differences from Traditional Approaches

❌ OLD (Hardcoded) Approach:

# Server code that made decisions
if "fibonacci" in prompt or "algorithm" in prompt:
    return "boomerang"  # Server decided!
elif "decision" in prompt:
    return "devils_advocate"  # Server decided!

✅ NEW (LLM-Driven) Approach:

# Server only provides data
return {
    "all_strategies": get_all_strategies(),
    "instruction": "You analyze and decide"
}
# LLM makes the decision!

🎬 Real-World Process Examples

Example 1: Complex Technical Task

User Prompt: "Build a real-time chat system with websockets"

Process:

  1. MCP Server Action:

    • Loads metadata for all 44+ strategies

    • Formats them with descriptions, use cases, complexity

    • Sends everything to Claude

  2. Claude's Analysis:

    Analyzing prompt characteristics:
- Domain: Software development
- Type: System implementation
- Complexity: High
- Key aspects: real-time, networking, architecture

Reviewing all strategies...

Best matches:
- architect: System design focus ✓
- boomerang: Iterative development ✓
- devops: Infrastructure needs ✓

  3. Claude's Selection:

    SELECTED: architect
REASON: Building a real-time system requires careful architectural planning

  4. Claude's Enhancement: Applies architect methodology to create comprehensive system design prompt with scalability, security, and performance considerations

Example 2: Decision Making Task

User Prompt: "I need to make a difficult decision about our product roadmap"

What Claude Does:

  1. Step 1: Reviews all 5 categories, selects "AI Core Principles" for its decision-making frameworks

  2. Step 2: From 13 AI Core Principles, selects "devils_advocate" for systematic analysis

  3. Step 3: Applies Devil's Advocate methodology to create comprehensive decision framework

Example 3: Compare Multiple Strategies

User: "Help me optimize database queries"

MCP Server: Presents ALL strategies to Claude

Claude independently selects 3-5 relevant ones:

  • boomerang (iterative optimization)

  • reviewer (performance review)

  • pattern_recognizer (identify optimization patterns)

Then compares their approaches and provides multiple refinement options.

📚 All 44+ Available Strategies

🔧 Core Strategies (10)

Strategy

Use Case

Complexity

ECHO (star)

Complex creative tasks, detailed analysis

High

Done

Structured tasks, role-playing scenarios

Medium

Physics

Scientific analysis, technical problems

Medium

Morphosis

Quick improvements, simple tasks

Low

Verse

Technical prompts, information flow

Medium

Math

Mathematical reasoning, formal proofs

High

Phor

Advanced technique combination

High

Bolism

Optimization tasks, structured output

Medium

Arpe

Advanced reasoning, complex logic

High

Touille

General refinement, balanced approach

Medium

💻 Software Development (4)

Strategy

Best For

Time Investment

Architect

System design, microservices, scalability

High

Boomerang

Iterative development, testing, refactoring

Medium

Reviewer

Code review, quality assurance, standards

Medium

DevOps

CI/CD, infrastructure, deployment

Medium-High

🧠 Advanced Thinking (6)

Strategy

Application

Cognitive Focus

Metacognitive

Bias analysis, thinking about thinking

Self-reflection

Adversarial

Stress testing, vulnerability analysis

Attack/Defense

Fractal

Scale-invariant problems, hierarchies

Recursive patterns

Quantum

Uncertainty navigation, parallel possibilities

Superposition

Temporal

Time-aware analysis, causality chains

Multi-timeline

Synthesis

Cross-domain innovation, concept fusion

Creative combination

🎯 AI Core Principles (13)

Critical thinking enhancement frameworks:

  • Assumption Detector → Challenge hidden assumptions

  • Devil's Advocate → Generate systematic counterarguments

  • Ripple Effect Analyzer → Trace cascading consequences

  • Perspective Multiplier → Multi-stakeholder analysis

  • Evidence Seeker → Demand concrete validation

  • Pattern Recognizer → Identify recurring patterns

  • Root Cause Analyzer → Find fundamental causes

  • Constraint Identifier → Map limiting factors

  • Paradox Navigator → Resolve contradictions

  • Tradeoff Tracker → Explicit cost-benefit analysis

  • Context Expander → Prevent local optimization

  • Precision Questioner → Transform vague to precise

  • Time Capsule Test → Long-term durability assessment

🤖 Vibe Coding Rules (11)

AI-assisted development patterns:

  • Start from Template → Leverage proven foundations

  • Use Agent Mode → Optimize AI collaboration

  • Write Tests First → TDD for clarity and quality

  • Keep Files Small → Modular, readable structure

  • Run Locally, Test Frequently → Rapid feedback loops

  • Follow Existing Patterns → Consistency and conventions

  • Delete Aggressively → Remove complexity and dead code

  • Ship Small Changes → Incremental, safe deployment

  • Collaborate Early and Often → Stakeholder engagement

  • Refactor Continuously → Ongoing improvement

  • Document Intent → Focus on why, not how

💡 Common Patterns & LLM Selection Behavior

Technical Tasks

  • Claude often selects from Software Development category

  • Frequently chooses: boomerang, architect, reviewer

Decision Making

  • Claude gravitates toward AI Core Principles

  • Common picks: devils_advocate, tradeoff_tracker, ripple_effect

Creative Work

  • Claude selects from Core Strategies or Advanced Thinking

  • Popular choices: star, synthesis, quantum

Quick Tasks

  • Claude identifies simplicity need

  • Often selects: morphosis, done

🏗️ Architecture & Performance

🎯 How the LLM Selects Strategies

The MCP server provides rich metadata that Claude uses for selection:

  • Keywords: 50+ trigger patterns across domains

  • Complexity: Task complexity indicators

  • Domain: Technical, creative, analytical, mathematical

  • Best For: Specific use case recommendations

  • Examples: Sample prompts for pattern matching

⚡ Performance Features

  • Sub-millisecond Selection: Optimized matching algorithms

  • Intelligent Caching: 10-minute TTL with automatic cleanup

  • Hot Reloading: File watcher for development

  • Memory Efficient: Resource cleanup and monitoring

  • Graceful Degradation: Fallback strategies on failures

🛡️ Enterprise Grade

  • Structured Logging: Environment-aware with context

  • Health Monitoring: Built-in diagnostics and metrics

  • Error Boundaries: Comprehensive exception handling

  • Type Safety: Strong TypeScript throughout

  • Resource Management: Proper cleanup and shutdown

🔧 Advanced Usage

Performance Monitoring

Use get_performance_metrics tool

Health Checks

Use health_check tool

Strategy Discovery

Use discover_strategies tool

Compare Multiple Strategies

Use compare_refinements prompt with user_prompt: "your prompt" and strategies: "star,physics,boomerang"

🎨 Custom Prompts Support

Create your own prompt strategies to extend Prompt++ with domain-specific or team-specific enhancements.

Setting Up Custom Prompts

  1. Create a custom prompts directory:

mkdir -p ~/.prompt-plus-plus/custom-prompts

  1. Set environment variable (optional):

export PROMPT_PLUS_CUSTOM_DIR="/path/to/your/custom-prompts"

  1. Add your custom strategies (see custom-prompts-example/ for templates)

Using Custom Strategies

# List all custom strategies
Use list_custom_strategies tool

# Use a specific custom strategy
Use refine_with_custom_my-team_code_review prompt with user_prompt: "Review this code"

# Auto-refine using only custom strategies
Use auto_refine prompt with user_prompt: "..." and source: "custom"

# Auto-refine using only built-in strategies
Use auto_refine prompt with user_prompt: "..." and source: "built-in"

Custom Strategy Format

Each strategy is a JSON file with:

  • name: Display name

  • description: What it does

  • template: Metaprompt template with [Insert initial prompt here] placeholder

  • examples: Usage examples

  • triggers: Keywords for auto-selection

  • best_for: Ideal use cases

See custom-prompts-example/ directory for complete examples.

📚 Strategy Collections

Create personal collections of your favorite strategies (both built-in and custom) for quick access.

Creating Collections

# Create a new collection
Use manage_collection tool with action: "create" and collection: "my-favorites" and name: "My Favorite Strategies" and description: "Go-to strategies for daily work"

# Add strategies to collection
Use manage_collection tool with action: "add_strategy" and collection: "my-favorites" and strategy: "star"
Use manage_collection tool with action: "add_strategy" and collection: "my-favorites" and strategy: "boomerang"

Using Collections

# List all collections
Use list_collections tool

# Use a collection with auto-refine
Use auto_refine prompt with user_prompt: "Create a function to sort data" and collection: "quick-coding"

Managing Collections

# Remove strategy from collection
Use manage_collection tool with action: "remove_strategy" and collection: "my-favorites" and strategy: "star"

# Update collection details
Use manage_collection tool with action: "update" and collection: "my-favorites" and description: "Updated description"

# Delete collection
Use manage_collection tool with action: "delete" and collection: "my-favorites"

Example Collections

See collections-example.json for pre-made collections:

  • quick-coding: Rapid development strategies

  • deep-analysis: Complex problem solving

  • creative-work: Innovation and creative thinking

  • code-review: Quality assurance strategies

  • decision-making: Strategic planning frameworks

  • learning: Educational and understanding strategies

Collections are stored in ~/.prompt-plus-plus/collections.json

📁 Project Structure

prompt-plus-plus-mcp/
├── src/                          # TypeScript source code
│   ├── index.ts                 # Main MCP server with workflow factory
│   ├── strategy-manager.ts      # Enhanced loading with caching
│   ├── strategy-selector.ts     # Intelligent selection algorithm  
│   ├── prompt-refiner.ts        # Simplified interface
│   ├── workflow-factory.ts      # Factory pattern for handlers
│   ├── cache.ts                # TTL caching system
│   ├── logger.ts               # Structured logging
│   ├── schema-validator.ts     # JSON schema validation
│   └── types.ts                # Comprehensive type definitions
├── metaprompts/                 # Built-in strategy definitions by category
│   ├── core_strategies/         # 10 foundational approaches
│   ├── software_development/    # 4 dev-focused strategies  
│   ├── advanced_thinking/       # 6 cognitive frameworks
│   ├── ai_core_principles/      # 13 critical thinking tools
│   └── vibe_coding_rules/       # 11 AI development patterns
├── custom-prompts-example/      # Example custom strategies (copy as template)
│   ├── my-team/                # Team-specific strategies example
│   └── personal/               # Personal productivity example
├── dist/                        # Compiled JavaScript
├── IMPROVEMENTS.md              # Implementation history
└── USER_GUIDE.md               # Comprehensive usage guide

🤝 Contributing

We welcome contributions! Areas where you can help:

Adding New Strategies

  1. Create JSON file in appropriate category subdirectory

  2. Follow schema: name, description, template, examples, triggers, best_for

  3. Add metadata entry if creating new category

  4. Test with various prompt types

Improving Selection Logic

  • Enhance keyword matching in strategy-selector.ts

  • Add new domain detection patterns

  • Improve confidence scoring algorithms

  • Contribute test cases for edge cases

Documentation & Examples

  • Add real-world usage scenarios

  • Create video tutorials

  • Improve error messages

  • Write integration guides

📊 Performance Benchmarks

  • Strategy Loading: 44 strategies in ~50ms

  • Selection Time: <1ms average, <5ms 99th percentile

  • Memory Usage: <10MB baseline, <50MB peak

  • Cache Hit Rate: 90%+ in typical development workflow

  • Error Recovery: <100ms fallback to safe defaults

🎯 Summary: The Core Concept

The Prompt++ MCP server is a pure data provider. It:

  • ✅ Loads strategy templates and metadata

  • ✅ Presents all options to the LLM

  • ✅ Provides structured prompts for LLM to process

  • ❌ Does NOT make selection decisions

  • ❌ Does NOT analyze prompts

  • ❌ Does NOT score strategies

The LLM (Claude) is the intelligent decision maker. It:

  • ✅ Analyzes the user's prompt

  • ✅ Reviews all available strategies

  • ✅ Selects the best match

  • ✅ Applies the strategy methodology

  • ✅ Explains its reasoning

This separation ensures the system leverages the LLM's intelligence rather than relying on rigid keyword matching.

📄 License

MIT License - see LICENSE file for details.

🔗 Links

Available Tools

8 tools
discover_strategiesB

Get comprehensive metadata about all strategy categories and their available strategies for intelligent selection

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states the tool returns 'comprehensive metadata', but does not disclose side effects, authentication needs, rate limits, or the exact nature of the output. The behavior is only partially transparent.

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 a single sentence, concise and front-loaded. It could be more specific about the metadata, but it avoids unnecessary verbosity.

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?

With zero parameters and no output schema, the description is the only source of context. It covers the main purpose but lacks detail on the format or comprehensiveness of the metadata, leaving the agent with partial information.

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?

There are no parameters, so schema coverage is trivially 100%. The description adds value by explaining the scope of the output (categories and strategies), which is useful beyond the empty schema.

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 uses a specific verb ('Get') and resource ('strategy categories and their available strategies'), clearly indicating the tool's purpose. However, it lacks differentiation from sibling tools like list_strategies or list_custom_strategies, which might also list strategies.

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?

No guidance is provided on when to use this tool over siblings. The phrase 'intelligent selection' implies a high-level overview, but there's no explicit when-to-use or when-not-to-use information.

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

get_performance_metricsA

Get performance metrics for strategy selection and usage

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits. 'Get' implies a read-only operation with no side effects, which is appropriate. However, it does not mention any required permissions, data scope limitations, or potential impacts, leaving gaps in transparency.

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, concise sentence that directly states the tool's purpose. There is no extraneous information, and the key action and resource are front-loaded. Every word earns its place.

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 simplicity (no parameters, no output schema, no annotations), the description is adequate but minimal. It tells what the tool does but does not explain return values or any contextual constraints. For a straightforward 'get' tool, this may be sufficient, but it lacks completeness compared to richer descriptions.

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 tool has zero parameters, so the input schema is trivial. The description adds context by specifying 'for strategy selection and usage', which clarifies the intended use case. Since no parameters need documentation, the description adequately serves its purpose.

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 'Get performance metrics for strategy selection and usage' uses a specific verb ('Get') and identifies the resource ('performance metrics'). It is distinct from sibling tools like 'get_strategy_details' or 'discover_strategies', which focus on strategies themselves. However, it does not explicitly differentiate from other tools, leaving some ambiguity.

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

Usage Guidelines3/5

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

The description implies usage when performance metrics are needed for strategy selection, but it provides no explicit guidance on when to use this tool versus alternatives. No exclusions or prerequisites are mentioned, relying on the context of sibling tool names.

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

get_strategy_detailsA

Get detailed information about a specific strategy

ParametersJSON Schema
NameRequiredDescriptionDefault
strategyYesThe strategy to get details for

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description must carry the burden of behavioral disclosure. It correctly indicates a read operation but does not elaborate on what 'detailed information' includes (e.g., metadata, parameters, performance stats). No contradictions with annotations (none provided).

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 sentence that is concise and front-loaded with the core action. No superfluous words—every part earns its place.

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 low complexity (one parameter, no output schema, no nested objects) and high schema coverage, the description is mostly sufficient. However, it could hint at what 'details' entail to set expectations, but the gap is minor.

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?

The input schema provides 100% documentation of the single parameter 'strategy' with an enum and description. The tool description adds no additional meaning beyond what the schema already states. Baseline score of 3 applies because schema coverage is high and description adds no extra value.

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 uses a specific verb ('Get') and resource ('detailed information about a specific strategy'), clearly indicating the tool's action and object. It distinguishes from sibling tools like 'list_strategies' which would return summaries rather than details.

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?

No usage guidance is provided. The description does not specify when to use this tool versus alternatives such as 'list_strategies' or 'discover_strategies'. There is no mention of prerequisites or post-conditions.

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

health_checkA

Check the health status of the server and strategy manager

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/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 checking health status but does not disclose if it is read-only, affects server state, or requires authentication. For a health check, it is likely safe, but this is not explicitly stated.

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, concise sentence that conveys the entire purpose without unnecessary words. It is front-loaded and directly usable.

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 simplicity (0 parameters, no output schema), the description is largely sufficient. It could be improved by noting the expected return format (e.g., status string or object), but the current description covers the core functionality.

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

Parameters5/5

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

The tool has no parameters, and schema coverage is 100%. The description adds value by specifying what components are checked (server and strategy manager), providing meaning beyond the empty 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 verb 'Check' and the specific resources 'health status of the server and strategy manager'. It distinguishes this tool from siblings like 'discover_strategies' and 'get_performance_metrics', which focus on specific data rather than overall health.

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 alternatives. It does not state that it should be used for health monitoring or system readiness checks, nor does it exclude misuse cases.

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

list_collectionsB

List all strategy collections

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits, but it only states 'List all' without mentioning side effects, authentication needs, rate limits, or what 'all' entails, leaving significant gaps.

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?

Single sentence with no wasted words, highly efficient. However, could be slightly expanded to add context while remaining concise.

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?

Lacks details on return format, pagination, or what 'collections' are. For a simple list tool with no output schema and no annotations, the description should provide more completeness.

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 has 0 parameters and 100% coverage, baseline is 3. The description adds no parameter-specific info, but none is needed.

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 'List all strategy collections' clearly states the verb and resource, and distinguishes from sibling tools like list_strategies and list_custom_strategies which target different resources.

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?

No guidance provided on when to use this tool versus alternatives, no exclusions, and no context for appropriate usage beyond the generic description.

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

list_custom_strategiesA

List all custom user-defined strategies with their categories

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only describes the basic action and output (categories) without mentioning any side effects, performance implications, authentication needs, or other behavioral traits. This is minimal.

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 sentence that directly conveys the tool's purpose without any wasted words. It is appropriately sized and front-loaded.

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?

The description is adequate for a parameterless tool but lacks detail about the return format beyond mentioning 'categories.' Without an output schema, more specificity (e.g., listing fields returned) would improve completeness.

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 tool has no parameters, so the baseline is 4. The description adds no parameter information, but that is acceptable because there are none to explain. It does not add confusion.

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 states 'List all custom user-defined strategies with their categories,' which clearly identifies the verb (list), specific resource (custom user-defined strategies), and includes differentiation from siblings like 'list_strategies' (likely all strategies) and 'discover_strategies' (possibly a discovery action).

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

Usage Guidelines3/5

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

The description does not provide explicit guidance on when to use this tool versus siblings, nor does it mention any prerequisites or exclusions. The context implies use for custom strategies, but lacks direct instruction.

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

list_strategiesC

List all available metaprompt strategies with descriptions

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.8/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden but fails to disclose any behavioral traits (e.g., read-only, authentication needs, pagination, or empty results behavior).

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 a single concise sentence that is front-loaded. It earns its place, though it could be slightly more informative without sacrificing brevity.

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 lack of annotations, output schema, and sibling differentiation, the description is insufficient. It does not clarify how this tool relates to 'discover_strategies' or 'list_custom_strategies', nor does it explain what a 'strategy' is.

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?

There are no parameters, so the baseline is 4. The description adds value by stating it returns 'descriptions', which is not in the schema. No further elaboration needed.

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 verb 'list' and resource 'metaprompt strategies' with what is returned ('with descriptions'). However, it does not differentiate from sibling tools like 'list_custom_strategies', leaving potential ambiguity.

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?

No guidance is provided on when to use this tool versus alternatives such as 'discover_strategies' or 'list_custom_strategies'. There is no mention of context or prerequisites.

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

manage_collectionC

Create, update, or delete strategy collections

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform
collectionYesCollection key/identifier
nameNoCollection display name (for create/update)
descriptionNoCollection description (for create/update)
strategyNoStrategy key (for add/remove)

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only indicates mutation through verbs but does not describe side effects, permission requirements, or safety considerations. This is insufficient for a tool that creates, updates, deletes, and modifies collections.

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 a single sentence, which is concise but overly brief for the tool's complexity. It could be structured to explain the different actions and their required parameters.

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?

The tool lacks an output schema and annotations, and the description does not cover return values, error cases, or completeness of operations. It is insufficient for an agent to fully understand the tool's behavior.

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?

The schema has 100% coverage, so the description's lack of additional parameter context is acceptable but does not enhance understanding. The description does not clarify how the action parameter interacts with other parameters.

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 modifies strategy collections with create, update, delete actions. However, it omits the additional actions add_strategy and remove_strategy that appear in the schema, making it slightly incomplete. It distinguishes from the sibling list_collections tool.

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 its siblings such as list_collections, discover_strategies, or others. It fails to mention prerequisites, context, or alternatives.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation4/5

Tools are mostly distinct but list_strategies, list_custom_strategies, and discover_strategies have overlapping purposes. descriptions help clarify, but an agent might confuse them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_strategies, manage_collection). health_check deviates slightly but is still clear.

Tool Count5/5

8 tools is well-scoped for a strategy management server. Each tool serves a clear purpose without being overwhelming.

Completeness4/5

Coverage includes listing, details, metadata, performance, and collection management. Missing explicit create/delete for strategies, but likely not needed as strategies are predefined.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

  • Tyra Advanced Memory MCP

    bigrock776
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    A sophisticated MCP server providing advanced memory capabilities with RAG, hallucination detection, and enterprise-grade AI infrastructure for intelligent agent ecosystems.

  • MCP Prompt Optimizer

    Bubobot-Team
    A
    license
    Not graded
    quality
    D
    maintenance
    This MCP server provides research-backed prompt optimization tools and professional domain templates designed to improve AI performance through strategies like Tree of Thoughts and Medprompt. It enables users to analyze, auto-optimize, and refine prompts using advanced reasoning patterns and safety-critical alignment techniques.
    24
    MIT

  • Refine Prompt

    FelippeFarias
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that uses Claude 3.5 Sonnet to transform ordinary prompts into structured, professionally engineered instructions for any LLM. It enhances AI interactions by adding context, requirements, and structural clarity to raw user inputs.
    1
    3
    MIT

Appeared in Searches

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/bacoco/prompt-plus-plus-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server