Skip to main content
Glama
tanker327

Prompts MCP Server

by tanker327
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Prompts MCP Server

A Model Context Protocol (MCP) server for managing and providing prompts. This server allows users and LLMs to easily add, retrieve, and manage prompt templates stored as markdown files with YAML frontmatter support.

Quick Start

# 1. Install from NPM
npm install -g prompts-mcp-server

# 2. Add to your MCP client config (e.g., Claude Desktop)
# Add this to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
  "mcpServers": {
    "prompts-mcp-server": {
      "command": "prompts-mcp-server"
    }
  }
}

# 3. Restart your MCP client and start using the tools!

Related MCP server: RISEN Prompt Engineering MCP Tool

Features

  • Add Prompts: Store new prompts as markdown files with YAML frontmatter

  • Retrieve Prompts: Get specific prompts by name

  • List Prompts: View all available prompts with metadata preview

  • Delete Prompts: Remove prompts from the collection

  • File-based Storage: Prompts are stored as markdown files in the prompts/ directory

  • Real-time Caching: In-memory cache with automatic file change monitoring

  • YAML Frontmatter: Support for structured metadata (title, description, tags, etc.)

  • TypeScript: Full TypeScript implementation with comprehensive type definitions

  • Modular Architecture: Clean separation of concerns with dependency injection

  • Comprehensive Testing: 95 tests with 84.53% code coverage

Installation

Option 1: From NPM (Recommended)

Install the package globally from NPM:

npm install -g prompts-mcp-server

This will make the prompts-mcp-server command available in your system.

After installation, you need to configure your MCP client to use it. See MCP Client Configuration.

Option 2: From GitHub (for development)

# Clone the repository
git clone https://github.com/tanker327/prompts-mcp-server.git
cd prompts-mcp-server

# Install dependencies
npm install

# Build the TypeScript code
npm run build

# Test the installation
npm test

Option 3: Direct Download

  1. Download the latest release from GitHub

  2. Extract to your desired location

  3. Run installation steps from Option 2.

Verification

After installation, verify the server works:

# Start the server (should show no errors)
npm start

# Or test with MCP Inspector
npx @modelcontextprotocol/inspector prompts-mcp-server

Testing

Run the comprehensive test suite:

npm test

Run tests with coverage:

npm run test:coverage

Watch mode for development:

npm run test:watch

MCP Tools

The server provides the following tools:

add_prompt

Add a new prompt to the collection. If no YAML frontmatter is provided, default metadata will be automatically added.

  • name (string): Name of the prompt

  • content (string): Content of the prompt in markdown format with optional YAML frontmatter

create_structured_prompt

Create a new prompt with guided metadata structure and validation.

  • name (string): Name of the prompt

  • title (string): Human-readable title for the prompt

  • description (string): Brief description of what the prompt does

  • category (string, optional): Category (defaults to "general")

  • tags (array, optional): Array of tags for categorization (defaults to ["general"])

  • difficulty (string, optional): "beginner", "intermediate", or "advanced" (defaults to "beginner")

  • author (string, optional): Author of the prompt (defaults to "User")

  • content (string): The actual prompt content (markdown)

get_prompt

Retrieve a prompt by name.

  • name (string): Name of the prompt to retrieve

list_prompts

List all available prompts with metadata preview. No parameters required.

delete_prompt

Delete a prompt by name.

  • name (string): Name of the prompt to delete

Usage Examples

Once connected to an MCP client, you can use the tools like this:

Method 1: Quick prompt creation with automatic metadata

// Add a prompt without frontmatter - metadata will be added automatically
add_prompt({
  name: "debug_helper",
  content: `# Debug Helper

Help me debug this issue by:
1. Analyzing the error message
2. Suggesting potential causes
3. Recommending debugging steps`
})
// This automatically adds default frontmatter with title "Debug Helper", category "general", etc.

Method 2: Structured prompt creation with full metadata control

// Create a prompt with explicit metadata using the structured tool
create_structured_prompt({
  name: "code_review",
  title: "Code Review Assistant",
  description: "Helps review code for best practices and potential issues",
  category: "development",
  tags: ["code", "review", "quality"],
  difficulty: "intermediate",
  author: "Development Team",
  content: `# Code Review Prompt

Please review the following code for:
- Code quality and best practices
- Potential bugs or issues
- Performance considerations
- Security vulnerabilities

## Code to Review
[Insert code here]`
})

Method 3: Manual frontmatter (preserves existing metadata)

// Add a prompt with existing frontmatter - no changes made
add_prompt({
  name: "custom_prompt",
  content: `---
title: "Custom Assistant"
category: "specialized"
tags: ["custom", "specific"]
difficulty: "advanced"
---

# Custom Prompt Content
Your specific prompt here...`
})

Other operations

// Get a prompt
get_prompt({ name: "code_review" })

// List all prompts (shows metadata preview)
list_prompts({})

// Delete a prompt
delete_prompt({ name: "old_prompt" })

File Structure

prompts-mcp-server/
├── src/
│   ├── index.ts          # Main server orchestration
│   ├── types.ts          # TypeScript type definitions
│   ├── cache.ts          # Caching system with file watching
│   ├── fileOperations.ts # File I/O operations
│   └── tools.ts          # MCP tool definitions and handlers
├── tests/
│   ├── helpers/
│   │   ├── testUtils.ts  # Test utilities
│   │   └── mocks.ts      # Mock implementations
│   ├── cache.test.ts     # Cache module tests
│   ├── fileOperations.test.ts # File operations tests
│   ├── tools.test.ts     # Tools module tests
│   └── index.test.ts     # Integration tests
├── prompts/              # Directory for storing prompt markdown files
│   ├── code_review.md
│   ├── debugging_assistant.md
│   └── api_design.md
├── dist/                 # Compiled JavaScript output
├── CLAUDE.md            # Development documentation
├── package.json
├── tsconfig.json
└── README.md

Architecture

The server uses a modular architecture with the following components:

  • PromptCache: In-memory caching with real-time file change monitoring via chokidar

  • PromptFileOperations: File I/O operations with cache integration

  • PromptTools: MCP tool definitions and request handlers

  • Type System: Comprehensive TypeScript types for all data structures

YAML Frontmatter Support

Prompts can include structured metadata using YAML frontmatter:

---
title: "Prompt Title"
description: "Brief description of the prompt"
category: "development"
tags: ["tag1", "tag2", "tag3"]
difficulty: "beginner" | "intermediate" | "advanced"
author: "Author Name"
version: "1.0"
---

# Prompt Content

Your prompt content goes here...

MCP Client Configuration

This server can be configured with various MCP-compatible applications. Here are setup instructions for popular clients:

Claude Desktop

Add this to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "prompts-mcp-server": {
      "command": "prompts-mcp-server",
      "env": {
        "PROMPTS_FOLDER_PATH": "/path/to/your/prompts/directory"
      }
    }
  }
}

Cline (VS Code Extension)

Add to your Cline MCP settings in VS Code:

{
  "cline.mcp.servers": {
    "prompts-mcp-server": {
      "command": "prompts-mcp-server",
      "env": {
        "PROMPTS_FOLDER_PATH": "/path/to/your/prompts/directory"
      }
    }
  }
}

Continue.dev

In your ~/.continue/config.json:

{
  "mcpServers": [
    {
      "name": "prompts-mcp-server",
      "command": "prompts-mcp-server",
      "env": {
        "PROMPTS_FOLDER_PATH": "/path/to/your/prompts/directory"
      }
    }
  ]
}

Zed Editor

In your Zed settings (~/.config/zed/settings.json):

{
  "assistant": {
    "mcp_servers": {
      "prompts-mcp-server": {
        "command": "prompts-mcp-server",
        "env": {
          "PROMPTS_DIR": "/path/to/your/prompts/directory"
        }
      }
    }
  }
}

Custom MCP Client

For any MCP-compatible application, use these connection details:

  • Protocol: Model Context Protocol (MCP)

  • Transport: stdio

  • Command: prompts-mcp-server

  • Environment Variables:

    • PROMPTS_FOLDER_PATH: Custom directory for storing prompts (optional, defaults to ./prompts)

Development/Testing Setup

For development or testing with the MCP Inspector:

# Install MCP Inspector
npm install -g @modelcontextprotocol/inspector

# Run the server with inspector
npx @modelcontextprotocol/inspector prompts-mcp-server

Docker Configuration

Create a docker-compose.yml for containerized deployment:

version: '3.8'
services:
  prompts-mcp-server:
    build: .
    environment:
      - PROMPTS_FOLDER_PATH=/app/prompts
    volumes:
      - ./prompts:/app/prompts
    stdin_open: true
    tty: true

Server Configuration

  • The server automatically creates the prompts/ directory if it doesn't exist

  • Prompt files are automatically sanitized to use safe filenames (alphanumeric characters, hyphens, and underscores only)

  • File changes are monitored in real-time and cache is updated automatically

  • Prompts directory can be customized via the PROMPTS_FOLDER_PATH environment variable

Environment Variables

Variable

Description

Default

PROMPTS_FOLDER_PATH

Custom directory to store prompt files (overrides default)

(not set)

NODE_ENV

Environment mode

production

Note: If PROMPTS_FOLDER_PATH is set, it will be used as the prompts directory. If not set, the server defaults to ./prompts relative to the server location.

Requirements

  • Node.js 18.0.0 or higher

  • TypeScript 5.0.0 or higher

  • Dependencies:

    • @modelcontextprotocol/sdk ^1.0.0

    • gray-matter ^4.0.3 (YAML frontmatter parsing)

    • chokidar ^3.5.3 (file watching)

Development

The project includes comprehensive tooling for development:

  • TypeScript: Strict type checking and modern ES modules

  • Vitest: Fast testing framework with 95 tests and 84.53% coverage

  • ESLint: Code linting (if configured)

  • File Watching: Real-time cache updates during development

Troubleshooting

Common Issues

"Module not found" errors

# Ensure TypeScript is built
npm run build

# Check that dist/ directory exists and contains .js files
ls dist/

MCP client can't connect

  1. Verify the server starts without errors: npm start

  2. Check the correct path is used in client configuration

  3. Ensure Node.js 18+ is installed: node --version

  4. Test with MCP Inspector: npx @modelcontextprotocol/inspector prompts-mcp-server

Permission errors with prompts directory

# Ensure the prompts directory is writable
mkdir -p ./prompts
chmod 755 ./prompts

File watching not working

  • On Linux: Install inotify-tools

  • On macOS: No additional setup needed

  • On Windows: Ensure Windows Subsystem for Linux (WSL) or native Node.js

Debug Mode

Enable debug logging by setting environment variables:

# Enable debug mode
DEBUG=* node dist/index.js

# Or with specific debug namespace
DEBUG=prompts-mcp:* node dist/index.js

Getting Help

  1. Check the GitHub Issues

  2. Review the test files for usage examples

  3. Use MCP Inspector for debugging client connections

  4. Check your MCP client's documentation for configuration details

Performance Tips

  • The server uses in-memory caching for fast prompt retrieval

  • File watching automatically updates the cache when files change

  • Large prompt collections (1000+ files) work efficiently due to caching

  • Consider using SSD storage for better file I/O performance

Community Variants & Extensions

Project

Maintainer

Extra Features

smart-prompts-mcp

@jezweb

GitHub-hosted prompt libraries, advanced search & composition, richer TypeScript types, etc.

👉 Have you built something cool on top of prompts-mcp-server?
Open an issue or PR to add it here so others can discover your variant!

License

MIT

Available Tools

5 tools
add_promptC

Add a new prompt to the collection

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the prompt
filenameYesEnglish filename for the prompt file (without .md extension)
contentYesContent of the prompt in markdown format

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 implies a write operation ('Add') but doesn't specify permissions, side effects (e.g., overwriting existing prompts), or error handling. This is inadequate for a mutation 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 a single, efficient sentence with no wasted words, clearly stating the tool's action. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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 tool's complexity as a mutation operation with no annotations and no output schema, the description is insufficient. It lacks details on behavior, return values, or error cases, leaving significant gaps for an AI agent to use it correctly.

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 input schema fully documents the three parameters (name, filename, content). The description adds no additional meaning beyond the schema, such as format examples or constraints, resulting in the baseline score for high coverage.

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 ('Add') and resource ('new prompt to the collection'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'create_structured_prompt' which likely serves a similar purpose, preventing 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 'create_structured_prompt' or 'list_prompts', nor does it mention prerequisites or context for adding prompts. It's a basic statement with no usage instructions.

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

create_structured_promptC

Create a new prompt with guided metadata structure

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the prompt
titleYesHuman-readable title for the prompt
descriptionYesBrief description of what the prompt does
categoryNoCategory (e.g., development, writing, analysis)
tagsNoArray of tags for categorization
difficultyNoDifficulty level of the prompt
authorNoAuthor of the prompt
contentYesThe actual prompt content (markdown)

TDQS

C2.9/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 but only states it creates a prompt with metadata. It doesn't disclose behavioral traits such as permissions needed, whether creation is idempotent, error handling, or response format, leaving significant gaps for a mutation tool.

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 action and key feature ('guided metadata structure'). It avoids redundancy and wastes no 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.

Completeness2/5

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

For a mutation tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, error cases, return values, and differentiation from siblings, failing to compensate for the absence of structured metadata.

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 fully documents all 8 parameters. The description adds minimal value by mentioning 'guided metadata structure', which loosely relates to parameters like category and tags, but doesn't provide additional semantics beyond the 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 clearly states the action ('Create') and resource ('new prompt'), specifying it involves 'guided metadata structure'. It distinguishes from siblings like 'add_prompt' by emphasizing structured metadata, but doesn't explicitly contrast with all siblings (e.g., 'get_prompt').

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 on when to use this tool versus alternatives like 'add_prompt' is provided. The description implies creation with metadata, but lacks explicit context, prerequisites, or exclusions for tool selection among siblings.

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

delete_promptC

Delete a prompt by name

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the prompt to delete

TDQS

C2.9/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 states the tool deletes a prompt, implying a destructive mutation, but doesn't cover critical aspects like permissions needed, whether deletion is permanent or reversible, error handling (e.g., if the prompt doesn't exist), or side effects. This leaves significant gaps for a mutation tool.

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 with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy or unnecessary elaboration.

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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permanence, permissions), error scenarios, or what happens post-deletion. Given the complexity of deletion operations and the absence of structured data to compensate, more context is needed to be fully helpful.

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 parameter 'name' fully documented in the schema as 'Name of the prompt to delete'. The description adds no additional meaning beyond this, such as format constraints or examples. Given the high schema coverage, the baseline score of 3 is appropriate as 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 'Delete a prompt by name' clearly states the action (delete) and resource (prompt) with a specific method (by name). It distinguishes from siblings like 'get_prompt' or 'list_prompts' by indicating a destructive operation, though it doesn't explicitly contrast with all siblings like 'add_prompt' or 'create_structured_prompt'. This makes it clear but not fully differentiated.

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., needing an existing prompt), exclusions (e.g., not for structured prompts), or direct comparisons to siblings like 'add_prompt' or 'get_prompt'. Without such context, users must infer usage from the name alone.

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

get_promptC

Retrieve a prompt by name

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the prompt to retrieve

TDQS

C2.9/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. 'Retrieve' implies a read operation, but it doesn't specify permissions needed, error handling (e.g., if the prompt doesn't exist), rate limits, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 with the core action ('retrieve a prompt') and includes the key constraint ('by name'), making it easy to parse quickly. Every word earns its place without redundancy.

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 doesn't explain what 'retrieve' entails (e.g., returns prompt content, metadata, or both), error cases, or how it differs behaviorally from siblings. For a tool in a set with multiple prompt-related operations, 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.

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 'name' fully documented in the schema. The description adds minimal value beyond the schema by implying the parameter is used to identify the prompt, but it doesn't provide additional context like format examples or constraints. 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 ('retrieve') and resource ('prompt'), specifying it's done 'by name'. It distinguishes from siblings like 'list_prompts' (which retrieves multiple) and 'delete_prompt' (which removes). However, it doesn't explicitly differentiate from 'add_prompt' or 'create_structured_prompt' in terms of retrieval vs. creation, though the verb 'retrieve' implies read-only access.

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., needing an existing prompt), exclusions (e.g., not for creating prompts), or direct comparisons to siblings like 'list_prompts' for browsing all prompts. Usage is implied by the action but not explicitly stated.

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

list_promptsB

List all 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. It only states the action ('List all available prompts') without mentioning critical details like whether this is a read-only operation, if it requires specific permissions, how results are returned (e.g., pagination), or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.

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 with no wasted words. It's front-loaded with the core action and resource, making it easy for an agent to parse quickly. Every word earns its place by directly conveying the tool's purpose.

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 tool's simplicity (0 parameters, no output schema), the description is minimal but adequate for basic understanding. However, with no annotations and no output schema, it lacks context about behavioral traits (e.g., safety, return format) and doesn't differentiate from siblings, making it incomplete for optimal agent usage in a multi-tool environment.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, which is efficient and avoids redundancy. A baseline of 4 is justified as the description doesn't need to compensate for any schema gaps.

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 prompts'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_prompt' (which likely retrieves a specific prompt), leaving room for confusion about when to use each.

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 'get_prompt' or 'add_prompt'. It lacks context about prerequisites, such as whether authentication is needed or if there are any filtering options, which could help the agent choose appropriately.

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. 5 tool updates
    • First observedadd_prompt
    • First observedcreate_structured_prompt
    • First observeddelete_prompt
    • First observedget_prompt
    • First observedlist_prompts
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: add_prompt and create_structured_prompt differ in metadata handling, while delete_prompt, get_prompt, and list_prompts each target a specific operation on prompts. An agent can easily distinguish between them.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., add_prompt, delete_prompt, list_prompts). The naming is predictable and uniform throughout the set, making it easy for agents to parse.

Tool Count5/5

With 5 tools, this server is well-scoped for managing prompts, covering core operations (create, read, list, delete) without being too sparse or bloated. Each tool serves a clear purpose in the domain.

Completeness4/5

The toolset provides solid CRUD coverage (add/create, get, list, delete) for prompts, but lacks an update or edit tool, which could be a minor gap for modifying existing prompts. However, agents can work around this by deletion and recreation.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Prompt Registry MCP

    stevengonsalvez
    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.
    6
    7
    MIT

  • mcp-prompt-server

    marcmodin
    A
    license
    A
    quality
    C
    maintenance
    Enables dynamic prompt management by automatically discovering and serving markdown prompt files with YAML frontmatter via the Model Context Protocol.
    1
    1
    MIT

Appeared in Searches