Skip to main content
Glama
LeonNonnast

Dev MCP Prompt Server

by LeonNonnast

MCP DevPrompts

npm version License: MIT TypeScript Model Context Protocol

Curated AI prompts for developers, delivered through the Model Context Protocol

A lightweight MCP server providing battle-tested prompts for AI-powered development workflows. Create specialized agents by combining modular skills, or use expert AI profiles for debugging, SQL optimization, and more.

πŸš€ Quick Start

Installation

git clone https://github.com/LeonNonnast/mcpdevprompts
cd mcpdevprompts
npm install
npm run build

claude mcp add mcpdevprompts --node /path/to/mcpdevprompts/build/server.js

Usage with Claude


# Use prompts directly
claude prompt debug-andy "My API returns 500 errors randomly"
claude prompt sql-expert "Optimize this slow query"
claude prompt clean-code-clarity-readability "Create a user service with clean code"

Quick Workflow Examples

πŸ” Discover Available Profiles & Skills

# See all available AI profiles
claude search_profiles
# Returns: debug-andy, sql-expert, performance-kai, lovable-ai-editor-base, etc.

# List all development skills
claude list_skills
# Returns: clean-code-clarity-readability, testing-strategies, error-handling-best-practices, etc.

πŸ‘₯ Work with AI Profiles

# Use a specialized debugging expert
claude prompt debug-andy "My React app crashes randomly on mobile devices"

# Get SQL optimization help
claude prompt sql-expert "This query takes 30 seconds, how can I optimize it?"

# Performance analysis
claude prompt performance-kai "My Node.js API response time increased by 200%"

🧠 Load Skills into Your Agent

# Load clean code skills
claude load_skills '{
  "skill_ids": ["clean-code-clarity-readability", "clean-code-small-functions"],
  "agent_name": "Clean Code Assistant"
}'

# Load testing expertise
claude load_skills '{
  "skill_ids": ["testing-strategies", "error-handling-best-practices"],
  "agent_name": "Testing Expert"
}'

# Create a full-stack quality agent
claude load_skills '{
  "skill_ids": ["clean-code-clarity-readability", "clean-code-small-functions", "testing-strategies"],
  "agent_name": "Full-Stack Expert"
}'

🎯 Real-World Scenarios

Scenario 1: Debugging Session

# 1. Start with debugging expert
claude prompt debug-andy "API endpoint returns 500 error intermittently"

# 2. Load additional skills for comprehensive solution
claude load_skills '{
  "skill_ids": ["error-handling-best-practices", "testing-strategies"],
  "agent_name": "Debug & Test Expert"
}'

# 3. Now ask for complete solution
"Create robust error handling and tests for this API endpoint"

Scenario 2: Code Quality Review

# 1. Load clean code skills
claude load_skills '{
  "skill_ids": ["clean-code-clarity-readability", "clean-code-small-functions", "clean-code-commenting"],
  "agent_name": "Code Quality Reviewer"
}'

# 2. Review and improve code
"Review this function and suggest improvements following clean code principles"

Scenario 3: Onboard New AI Agent

# 1. Onboard a specialized editor
claude prompt project-onboarding "Introduce lovable-ai-editor-base for code refactoring tasks"

# 2. Combine with additional skills
claude load_skills '{
  "skill_ids": ["clean-code-clarity-readability", "testing-strategies"],
  "agent_name": "Enhanced Code Editor"
}'

Local Development Testing

# Clone and test locally
git clone https://github.com/mcpdevprompts.git
cd server
npm install
npm run build
npm run inspector  # Opens MCP Inspector for testing

Related MCP server: Open MCP Server

πŸ“š Available Prompts

πŸ‘₯ AI Profiles

Expert AI assistants for specialized tasks:

  • debug-andy: Systematic debugging with root cause analysis

  • sql-expert: Advanced SQL query optimization and database design

  • performance-kai: Performance analysis and optimization strategies

  • lovable-ai-editor-base: AI-powered code editing and refactoring

  • perplexity-search-assistant: Research and information gathering

  • replit-expert-software-developer-editor: Full-stack development guidance

πŸ› οΈ Skills & Techniques

Development skills and methodologies:

  • project-onboarding: Introduce specialized AI agents to your workflow

  • clean-code-clarity-readability: Generate clear, self-explanatory code

  • clean-code-small-functions: Write focused, single-purpose functions

  • clean-code-commenting: Add meaningful comments and documentation

  • error-handling-best-practices: Implement robust error handling

  • testing-strategies: Create comprehensive test suites

🎯 Specialized Tools

Built-in tools for enhanced functionality:

  • search_prompts: Find prompts by keyword or category

  • search_profiles: Find AI profiles by specialization

  • get_prompt_stats: View prompt collection statistics

  • get_tool_stats: View available tools and usage

  • list_skills: List all available development skills

  • load_skills: Load multiple skills into an agent's knowledge base

Tool Examples:

# Search for profiles
claude search_profiles
# Returns: debug-andy, sql-expert, performance-kai, etc.

# List all available skills
claude list_skills
# Returns: clean-code-clarity-readability, testing-strategies, etc.

# Load multiple skills into an agent
claude load_skills '{"skill_ids": ["clean-code-clarity-readability", "testing-strategies"], "agent_name": "Clean Code Expert"}'
# Returns: Agent loaded with specified skills and ready to use them

# Get collection statistics
claude get_prompt_stats
# Returns: total prompts, categories, effectiveness ratings

πŸ’‘ Use Cases

For Frontend Developers

# Get clean code generation
claude prompt clean-code-clarity-readability "Create a React component for user profile"

# Small, focused functions
claude prompt clean-code-small-functions "Refactor this large function into smaller parts"

# Add proper documentation
claude prompt clean-code-commenting "Add documentation to this API endpoint"

For Backend Developers

# Database optimization
claude prompt sql-expert "Optimize this N+1 query problem"

# Performance debugging
claude prompt performance-kai "My Node.js API is slow under load"

# Systematic debugging
claude prompt debug-andy "Random 500 errors in production"

For Team Leads

# Agent onboarding
claude prompt project-onboarding "Introduce lovable-ai-editor profile for code review"

# Error handling standards
claude prompt error-handling-best-practices "Establish error handling guidelines"

# Testing strategies
claude prompt testing-strategies "Create testing plan for new microservice"

For Code Quality & Skill Management

# Clean code generation
claude prompt clean-code-clarity-readability "Create a user authentication service"

# Create a specialized agent with multiple skills
claude list_skills  # First see all available skills
claude load_skills '{"skill_ids": ["clean-code-clarity-readability", "clean-code-small-functions", "testing-strategies"], "agent_name": "Code Quality Expert"}'
# Now the agent has all three skills loaded and ready to use

πŸŽͺ Skill Management System

Available Skills

Our skill system provides modular development expertise that can be combined into specialized agents:

Clean Code Skills:

  • clean-code-clarity-readability: Generate self-explanatory code with meaningful names

  • clean-code-small-functions: Write focused, single-responsibility functions

  • clean-code-commenting: Add meaningful comments and documentation

Development Skills:

  • testing-strategies: Create comprehensive test suites and testing plans

  • error-handling-best-practices: Implement robust error handling patterns

  • project-onboarding: Guide specialized AI agents into workflow integration

Skill Workflow

1. Discover Available Skills

claude list_skills

Returns:

[
  {
    "id": "clean-code-clarity-readability",
    "title": "Generate Clear and Readable Code",
    "description": "Generate self-explanatory code with meaningful names",
    "tags": ["clean code", "readability", "maintainability"],
    "effectiveness": 5
  },
  {
    "id": "clean-code-small-functions",
    "title": "Generate Small, Single-Responsibility Functions",
    "description": "Write focused, single-purpose functions under 20 lines",
    "tags": ["clean code", "functions", "modularity"],
    "effectiveness": 5
  }
]

2. Load Skills into Agent

claude load_skills '{
  "skill_ids": ["clean-code-clarity-readability", "clean-code-small-functions", "testing-strategies"],
  "agent_name": "Clean Code Expert"
}'

Returns:

You are now a Clean Code Expert with the following specialized skills:

[Combined skill prompts...]

You have been equipped with these 3 specialized skills:
- Generate Clear and Readable Code: Generate self-explanatory code with meaningful names
- Generate Small, Single-Responsibility Functions: Write focused, single-purpose functions
- Create Comprehensive Test Suites: Design testing strategies and test plans

Please acknowledge that you have integrated these skills and are ready to apply them.

3. Use Your Specialized Agent

After loading skills, your agent automatically applies them to relevant requests:

# Agent now combines all loaded skills
"Create a user authentication service with clean code and tests"
# β†’ Uses clean code + testing skills together

Pre-Built Skill Combinations

🧹 Clean Code Expert

claude load_skills '{
  "skill_ids": ["clean-code-clarity-readability", "clean-code-small-functions", "clean-code-commenting"],
  "agent_name": "Clean Code Expert"
}'

πŸ§ͺ Testing Specialist

claude load_skills '{
  "skill_ids": ["testing-strategies", "error-handling-best-practices"],
  "agent_name": "Testing Specialist"
}'

🎯 Full-Stack Quality Agent

claude load_skills '{
  "skill_ids": ["clean-code-clarity-readability", "clean-code-small-functions", "testing-strategies", "error-handling-best-practices"],
  "agent_name": "Full-Stack Quality Agent"
}'

Benefits of Skill Management

  • πŸ”§ Modular: Mix and match skills for specific needs

  • πŸ“ˆ Scalable: New skills integrate seamlessly

  • πŸ‘₯ Collaborative: Share skill combinations with your team

  • 🎯 Focused: Create highly specialized agents for specific tasks

  • πŸ’‘ Intelligent: Skills work together contextually

πŸ—οΈ Architecture

mcpdevprompts/
β”œβ”€β”€ src/                    # TypeScript source code
β”‚   β”œβ”€β”€ server.ts          # Main MCP server
β”‚   β”œβ”€β”€ prompt-manager.ts  # Prompt loading and management
β”‚   β”œβ”€β”€ tool-manager.ts    # Tool management system
β”‚   └── utils/
β”œβ”€β”€ public/
β”‚   β”œβ”€β”€ prompts/
β”‚   β”‚   β”œβ”€β”€ profiles/      # AI assistant profiles
β”‚   β”‚   β”œβ”€β”€ skills/        # Development skills & techniques
β”‚   β”‚   └── onboarding/    # Project & team setup
β”‚   β”œβ”€β”€ tools/             # MCP tools definitions
β”‚   └── schema/            # JSON schemas for validation
β”œβ”€β”€ build/                 # Compiled JavaScript
└── docs/                  # Documentation

πŸ”§ Development

Prerequisites

  • Node.js 18.0.0 or higher

  • npm or yarn

Setup

# Clone the repository
git clone https://github.com/mcpdevprompts/server.git
cd server

# Install dependencies
npm install

# Build the project
npm run build

# Run in development mode
npm run dev

# Test with MCP Inspector
npm run inspector

Adding New Prompts

  1. Choose the right category:

    • profiles/ - AI assistant personalities

    • skills/ - Development techniques

    • onboarding/ - Setup and integration

  2. Follow the schema (see public/schema/prompt-schema.json):

    {
      "id": "unique-prompt-id",
      "title": "Human-readable title",
      "description": "What this prompt does",
      "category": "profiles|skills|onboarding",
      "tags": ["relevant", "searchable", "tags"],
      "prompt": "Your detailed prompt text here...",
      "examples": [
        {
          "input": "Example input",
          "output": "Expected output description"
        }
      ],
      "effectiveness": 4.5,
      "author": "Your Name",
      "version": "1.0.0",
      "created_at": "2024-01-01T00:00:00Z",
      "updated_at": "2024-01-01T00:00:00Z"
    }
  3. Test thoroughly with various inputs

  4. Submit a pull request with clear description

Adding New Tools

Tools extend the MCP server functionality with custom operations. Follow these steps:

  1. Choose a meaningful tool name (e.g., analyze_code, generate_tests, check_dependencies)

  2. Create the tool definition in public/tools/your-tool.json:

    {
      "id": "analyze_code_complexity",
      "name": "analyze_code_complexity",
      "description": "Analyze code complexity and suggest improvements",
      "input_schema": {
        "type": "object",
        "properties": {
          "code": {
            "type": "string",
            "description": "The code to analyze"
          },
          "language": {
            "type": "string",
            "description": "Programming language (js, ts, py, etc.)"
          },
          "metrics": {
            "type": "array",
            "items": { "type": "string" },
            "description": "Metrics to calculate (cyclomatic, cognitive, etc.)"
          }
        },
        "required": ["code", "language"]
      }
    }
  3. Implement the tool logic in src/server.ts CallToolRequestSchema handler:

    case "analyze_code_complexity":
      if (!args || typeof args.code !== "string") {
        throw new McpError(ErrorCode.InvalidRequest, "Code parameter is required");
      }
    
      const analysis = await this.analyzeCodeComplexity(args.code, args.language);
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(analysis, null, 2)
          }
        ]
      };
  4. Test the tool with MCP Inspector and various inputs

Tool Ideas:

  • validate_env_vars: Check environment variable completeness

  • generate_tests: Create unit tests for given code

  • check_dependencies: Analyze package.json for vulnerabilities

  • format_sql: Format and validate SQL queries

  • analyze_performance: Detect performance bottlenecks

  • generate_docs: Create documentation from code comments

πŸ“Š Quality Standards

All prompts must meet these criteria:

  • Effectiveness: Average rating of 4.0+ from community testing

  • Clarity: Clear, actionable instructions

  • Completeness: Comprehensive coverage of the task

  • Best Practices: Follow current industry standards

  • Accessibility: Consider accessibility requirements where applicable

🀝 Contributing

We welcome contributions! Please see our Contributing Guide for details.

Types of Contributions

  • New Prompts: Add high-quality prompts for common development tasks

  • Prompt Improvements: Enhance existing prompts based on user feedback

  • Documentation: Improve setup guides and usage examples

  • Bug Fixes: Report and fix issues with the server

  • Tools: Add new MCP tools for enhanced functionality

πŸ”’ Security

  • No sensitive data in prompts

  • Input validation for all user inputs

  • Rate limiting on API endpoints

  • Regular security audits

  • Schema validation for all prompts and tools

🎯 Roadmap

  • Phase 1: TypeScript MCP server with core prompts

  • Phase 2: AI profiles and specialized tools

  • Phase 3: Skill management system with combinable expertise

  • Phase 4: Community contributions and rating system

  • Phase 5: IDE integrations and advanced analytics

  • Phase 6: Custom prompt collections and enterprise features

πŸ“ License

MIT License - see LICENSE for details.

πŸ™ Acknowledgments

πŸ“ž Support


Made with ❀️ by the MCP DevPrompts community

Available Tools

6 tools
get_prompt_statsB

Get statistics about available prompts

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 provided, the description carries the full burden of behavioral disclosure but only states the action without details on permissions, rate limits, response format, or side effects. It doesn't clarify if this is a read-only operation or has other behavioral traits, making it insufficient for informed use.

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, efficient sentence that directly states the tool's purpose without any unnecessary words or structural fluff. It is front-loaded and appropriately sized for a simple tool, 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.

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 and output schema, the description is incomplete for a tool that likely returns statistical data. It doesn't explain what statistics are provided, the format of the response, or any prerequisites, leaving significant gaps in understanding the tool's full context.

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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately avoids redundancy, earning a high baseline score for this context.

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 with a specific verb ('Get') and resource ('statistics about available prompts'), making it easy to understand what the tool does. However, it doesn't differentiate from sibling tools like 'search_prompts' or 'get_tool_stats', which prevents a perfect score.

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 like 'search_prompts' or 'get_tool_stats'. It lacks context about whether this is for aggregated data, metadata, or other specific use cases, leaving the agent without clear usage instructions.

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

get_tool_statsC

Get statistics about available tools

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits like rate limits, authentication needs, response format, or whether it's read-only/destructive. It adds minimal context beyond the obvious purpose.

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, efficient sentence with no wasted words, front-loading the core purpose. It's appropriately sized for a simple tool with no parameters, making it easy to parse quickly.

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 no annotations, no output schema, and a vague purpose, the description is incomplete. It doesn't explain what 'statistics' includes, how results are structured, or any operational constraints, leaving significant gaps for an agent to understand the tool's behavior fully.

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 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add param semantics, but this is acceptable given the lack of parameters, aligning with the baseline for zero-param tools.

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 'Get statistics about available tools' clearly states the action (get) and resource (statistics about tools), but it's vague about what 'statistics' entails and doesn't differentiate from siblings like 'get_prompt_stats' or 'list_skills'. It avoids tautology but lacks specificity.

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 'get_prompt_stats' or 'list_skills'. The description implies usage for statistical queries but offers no context on prerequisites, exclusions, or comparative scenarios with sibling tools.

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

list_skillsB

List all available development skills with descriptions and IDs

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoOptional: filter by tags (clean-code, testing, etc.)

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a listing operation, implying read-only behavior, but doesn't mention any constraints like rate limits, authentication needs, pagination, or what happens if no skills are found. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational traits.

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, efficient sentence that front-loads the core purpose without any wasted words. It clearly communicates the action, resource, and included details, making it easy to parse quickly.

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 (one optional parameter, no output schema, no annotations), the description is adequate but has clear gaps. It covers the basic purpose but lacks behavioral details and usage guidelines. For a simple listing tool, this is the minimum viable level, but it could benefit from more context on when and how to use it effectively.

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 description coverage is 100%, with the single parameter 'tags' documented as optional for filtering by tags like 'clean-code' or 'testing'. The description adds no additional parameter information beyond what the schema provides, such as tag format or examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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 ('all available development skills'), specifying what information is included ('with descriptions and IDs'). It distinguishes this from siblings like 'load_skills' (which likely loads rather than lists) and 'search_profiles' (which focuses on profiles rather than skills). However, it doesn't explicitly differentiate from 'get_prompt_stats' or 'get_tool_stats', which are about 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'list_skills' over 'load_skills' (which might load specific skills) or 'search_profiles' (which might include skill-related searches). There's no context about prerequisites, timing, or exclusions for usage.

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

load_skillsC

Load and combine multiple skills into an agent's knowledge base

ParametersJSON Schema
NameRequiredDescriptionDefault
skill_idsYesArray of skill IDs to load (e.g., ['clean-code-clarity-readability', 'testing-strategies'])
agent_nameNoOptional: name for the specialized agent (e.g. sql-expert)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('load and combine') but doesn't describe key traits: whether this is a read-only or mutating operation (e.g., modifies agent state), any side effects (e.g., overwrites existing skills), authentication needs, rate limits, or error handling. This is inadequate for a tool that likely alters an agent's knowledge base.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action ('load and combine'), making it easy to parse. Every part of the sentence contributes essential information, earning a top score for conciseness.

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 of loading and combining skills (likely a mutating operation), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., side effects, permissions), return values, or error cases. For a tool that modifies an agent's state, this leaves significant gaps in understanding.

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 ('skill_ids' as an array of IDs and 'agent_name' as optional). The description adds no additional meaning beyond the schema, such as explaining how skills are combined or what happens if 'agent_name' is omitted. Baseline 3 is appropriate when the schema does the heavy lifting.

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 'load and combine' and the resource 'multiple skills', specifying the action and target. It distinguishes from siblings like 'list_skills' (which lists rather than loads) and 'search_profiles' (which searches profiles, not skills). However, it doesn't explicitly mention what 'load and combine' entails operationally (e.g., merging knowledge vs. sequential loading), keeping it from 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 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 doesn't mention prerequisites (e.g., whether skills must exist or be accessible), exclusions (e.g., not for single skills), or comparisons to siblings like 'list_skills' (for viewing available skills). This lack of context leaves the agent without clear usage cues.

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

search_profilesC

Search for profiles

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.7/5.0
Behavior1/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. 'Search for profiles' gives no information about traits like read-only vs. destructive, authentication needs, rate limits, pagination, or response format. It lacks any context beyond the basic action, making it inadequate for a tool with zero 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.

Conciseness5/5

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

The description is extremely concise with just three words, front-loading the core action and resource without any waste. Every word ('Search for profiles') directly contributes to the purpose, making it efficient and well-structured for its minimal content.

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 and output schema, the description is incomplete. It does not explain what 'profiles' entail, how results are returned, or any behavioral aspects like search scope or limitations. For a search tool with no structured data support, more context is needed to guide effective use.

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% description coverage, meaning no parameters need documentation. The description does not add parameter details, which is acceptable since there are none to explain. It avoids redundancy and appropriately handles the lack of parameters, though it could briefly note the absence of filters or criteria.

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 'Search for profiles' states a clear verb ('Search') and resource ('profiles'), establishing the basic purpose. However, it lacks specificity about what profiles are (e.g., user profiles, skill profiles) and does not differentiate from sibling tools like 'search_prompts' or 'list_skills', leaving ambiguity about scope. It avoids tautology by not merely restating the name, but remains vague.

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 mention context, prerequisites, or exclusions, and fails to reference sibling tools such as 'search_prompts' for similar search operations. Usage is implied only by the verb 'Search', but without explicit when/when-not instructions or named alternatives.

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

search_promptsC

Search for prompts by keyword or tag

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic function without behavioral details. It lacks information on permissions, rate limits, pagination, or response format, which are critical for a search operation.

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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.

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?

For a search tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like result format, error handling, or limitations, leaving significant gaps for the agent to operate effectively.

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 the 'query' parameter. The description adds minimal value by implying keywords or tags as search criteria, but doesn't elaborate on syntax or format beyond what the schema provides.

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 action ('search') and resource ('prompts') with search criteria ('by keyword or tag'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_profiles' or 'list_skills', which would require a more precise scope definition.

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 doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'search_profiles' or 'list_skills', leaving the agent to infer usage 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. Dates show when Glama detected each change.

  1. 6 tool updates
    • First observedget_prompt_stats
    • First observedget_tool_stats
    • First observedlist_skills
    • First observedload_skills
    • First observedsearch_profiles
    • First observedsearch_prompts

TDQS

B3.2/5.0
Disambiguation4/5

Most tools have distinct purposes, but 'get_prompt_stats' and 'search_prompts' could cause mild confusion as both relate to prompts, though one is for statistics and the other for searching. The other tools target clearly different resources like skills, tools, and profiles.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as 'get_prompt_stats', 'list_skills', and 'search_profiles'. There are no deviations in naming conventions across the set.

Tool Count5/5

With 6 tools, the count is well-scoped for a prompt server, covering statistics, listing, loading, and searching across prompts, tools, skills, and profiles. Each tool appears to serve a necessary function without bloat.

Completeness3/5

The server covers retrieval and search operations for prompts, skills, tools, and profiles, but lacks obvious CRUD operations like creating, updating, or deleting prompts or skills. This could limit agent workflows that require modification, though basic querying is supported.

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

  • F
    license
    C
    quality
    Not graded
    maintenance
    A modular productivity automation server providing reusable prompt templates, composable skills, and multi-step workflows for tasks like daily planning, code review, document summarization, and project management.
    19
    1
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    A lightweight, file-based server for managing and serving personal prompt templates with variable substitution support via the Model Context Protocol. It allows users to store, update, and organize prompts in a local directory through integrated MCP tools and CLI assistants.
    20
    7
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A self-hosted remote MCP server that provides reusable prompts and development conventions across various AI tools. It features a modular architecture for organizing and namespacing custom prompts to streamline AI-assisted coding workflows.
    MIT

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/LeonNonnast/mcpdevprompts'

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