Skip to main content
Glama
ugmurthy

PromptDB MCP Server

by ugmurthy
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

PromptDB MCP Server

A Model Context Protocol (MCP) server that provides prompt storage and retrieval functionality. Store, version, and manage your prompts with rich metadata and caching for optimal performance.

Features

  • Prompt Storage: Store prompts as individual JSON files with rich metadata

  • Version Management: Automatic versioning with history preservation

  • Caching: In-memory LRU cache for performance optimization

  • Rich Metadata: Tags, descriptions, timestamps, and version tracking

  • MCP Integration: Full compatibility with MCP-enabled applications

  • Dual Transport Support: Both stdio and SSE (Server-Sent Events) transports

  • Cloud Deployment: Ready for deployment to Vercel, Netlify, and other cloud platforms

Related MCP server: Think MCP Server

Pre-populated Prompts

The server comes with a set of pre-populated prompts ready for immediate use. You can retrieve them using the getPrompt tool with the following task names:

  • assistant

  • code-review

  • documentation

  • summarise-paper

  • to-flash-cards

Installation

Global Installation

# Using pnpm (recommended)
pnpm add -g promptdb-mcp-server

# Using npm
npm install -g promptdb-mcp-server

Local Development

# Clone and install dependencies
git clone <repository-url>
cd promptdb-mcp-server
pnpm install

# Build the project
pnpm build

# Start the server
pnpm start

Transport Options

The PromptDB MCP Server supports two transport methods:

1. Stdio Transport (Default)

For local development and MCP clients that support process communication:

# Default stdio transport
promptdb-mcp-server
# or explicitly
promptdb-mcp-server --transport stdio

2. SSE Transport (Server-Sent Events)

For web applications and cloud deployment:

# SSE transport on port 3000
promptdb-mcp-server --transport sse --port 3000

# Using environment variables
export TRANSPORT_TYPE=sse
export PORT=3000
promptdb-mcp-server

MCP Configuration

Stdio Transport Configuration

Add to your MCP client configuration:

{
  "mcpServers": {
    "promptdb": {
      "command": "promptdb-mcp-server",
      "args": []
    }
  }
}

SSE Transport Configuration

For MCP clients that support HTTP/SSE transport:

{
  "mcpServers": {
    "promptdb": {
      "transport": "sse",
      "url": "http://localhost:3000/sse"
    }
  }
}

Cloud Deployment

Vercel Deployment

# Build and deploy
pnpm build
vercel deploy

# Set environment variables in Vercel dashboard:
# TRANSPORT_TYPE=sse
# PORT=3000

Netlify Deployment

# Build and deploy
pnpm build
netlify deploy --prod --dir=dist

# Set TRANSPORT_TYPE=sse in Netlify dashboard

SSE Endpoints

When running in SSE mode, the server provides:

  • SSE Endpoint: http://localhost:3000/sse - MCP communication

  • Health Check: http://localhost:3000/health - Server status

  • Server Info: http://localhost:3000/ - Server metadata

Tools

listPrompts

List all available prompts with their content and versions.

Parameters: None

Returns: Array of prompts with taskname, content, and version

getPrompt

Retrieve a specific prompt by task name.

Parameters:

  • taskname (required): The task name identifier

  • version (optional): Specific version (defaults to latest)

Returns: Full prompt metadata including content, timestamps, tags, and description

setPrompt

Create or update a prompt for a task.

Parameters:

  • taskname (required): The task name identifier

  • content (required): The prompt content

  • description (optional): Human-readable description

  • tags (optional): Array of searchable tags

Returns: Confirmation with version information

Data Model

Prompt Structure

interface PromptMetadata {
  content: string;      // The prompt content
  created: string;      // ISO timestamp of creation
  updated: string;      // ISO timestamp of last update
  version: string;      // Semantic version (1.0, 1.1, etc.)
  tags: string[];       // Searchable tags
  description: string;  // Human-readable description
}

File Organization

  • Latest version: prompts/{taskname}.json

  • Historical versions: prompts/{taskname}_v{version}.json

  • Automatic archiving of previous versions

Version Management

  • New prompts start at version 1.0

  • Content updates increment minor version (1.0 → 1.1 → 1.2)

  • Previous versions are automatically archived

  • Latest version is always accessible without specifying version

Usage Examples

Storing a Prompt

{
  "tool": "setPrompt",
  "arguments": {
    "taskname": "code-review",
    "content": "Review this code for best practices, security issues, and performance optimizations...",
    "description": "Comprehensive code review prompt",
    "tags": ["code", "review", "security", "performance"]
  }
}

Retrieving a Prompt

{
  "tool": "getPrompt",
  "arguments": {
    "taskname": "code-review"
  }
}

Listing All Prompts

{
  "tool": "listPrompts",
  "arguments": {}
}

Development

Project Structure

promptdb-mcp-server/
├── src/
│   ├── index.ts              # Main entry point
│   ├── server.ts             # MCP server setup
│   ├── tools/                # Tool implementations
│   ├── storage/              # File system operations
│   ├── cache/                # In-memory caching
│   └── utils/                # Validation helpers
├── prompts/                  # Prompt storage directory
├── package.json
├── tsconfig.json
└── vite.config.ts

Development Commands

# Install dependencies
pnpm install

# Build project
pnpm build

# Development with watch mode
pnpm dev

# Start server (stdio transport)
pnpm start

# Start with SSE transport
pnpm start:sse

# Development with SSE transport
pnpm dev:sse

# Clean build artifacts
pnpm clean

Testing

Use the MCP Inspector or any MCP-compatible client to test the server:

  1. Start the server: pnpm start

  2. Connect via MCP Inspector

  3. Test the available tools

Performance

Caching Strategy

  • Cache Hit: Immediate return from memory

  • Cache Miss: Load from file system, cache result

  • Cache Invalidation: Automatic on prompt updates

  • Memory Management: LRU eviction at 100 items

File System Optimization

  • Asynchronous file operations throughout

  • On-demand directory creation

  • Robust error handling

  • Concurrent access safety

Error Handling

The server handles various error conditions gracefully:

  • File system permission errors

  • Invalid JSON parsing

  • Concurrent access conflicts

  • Cache consistency issues

  • Input validation errors

Troubleshooting

Common Issues

  1. Server not starting: Check Node.js version (18+) and dependencies

  2. Tool not found: Verify server is properly connected to MCP client

  3. Directory creation errors:

    • Error: ENOENT: no such file or directory, mkdir '/prompts'

    • Solution: The server creates a prompts directory in the current working directory. Ensure the MCP client has write permissions to the directory where it's running.

    • Alternative: The server will automatically create the directory with proper permissions

  4. File permissions: Ensure write access to prompts directory

  5. JSON parsing errors: Validate prompt file format

SSE Transport Issues

  1. Port already in use:

    # Find process using port
lsof -i :3000
# Kill process
kill -9 <PID>

  2. CORS errors: The server includes CORS headers by default for cross-origin requests

  3. Connection timeout: Check firewall settings and ensure the port is accessible

  4. Build errors: Ensure all dependencies are installed with pnpm install

  5. Cloud deployment issues:

    • Verify environment variables are set correctly

    • Check build logs for errors

    • Ensure dist/ directory is included in deployment

Testing SSE Transport

# Test health endpoint
curl http://localhost:3000/health

# Test server info
curl http://localhost:3000/

# Test SSE connection
curl -N http://localhost:3000/sse

Directory Configuration

The server creates prompts in the current working directory by default:

  • When run locally: ./prompts/ in the project directory

  • When installed globally: ./prompts/ in the directory where the MCP client runs

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

Validation Errors

  • Task names must be alphanumeric with hyphens/underscores only

  • Content cannot be empty

  • Version format must be X.Y (e.g., 1.0, 2.1)

License

MIT License - see LICENSE file for details

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if applicable

  5. Submit a pull request

Support

For issues and questions:

  • Create an issue on GitHub

  • Check the documentation

  • Review the implementation plan

Available Tools

3 tools
getPromptGet PromptA

Retrieve a prompt by task name

ParametersJSON Schema
NameRequiredDescriptionDefault
versionNoSpecific version (defaults to latest)
tasknameYesThe task name identifier

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, 'Retrieve' is the main behavioral disclosure, indicating a read-only operation without side effects. The description does not mention return shape, error behavior, or version-resolution behavior beyond what the schema already states, leaving some assumptions to the agent.

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 six-word sentence with the verb and resource front-loaded. Every word earns its place and there is no redundant or filler content.

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

Completeness4/5

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

For a simple two-parameter read tool with no output schema, the description plus schema is mostly sufficient: the agent knows the required taskname and the optional version. It would be slightly stronger with an explicit statement of what is returned, but nothing essential is missing for a basic invocation.

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%, with both taskname and version already documented, including the 'defaults to latest' note. The tool description adds no additional parameter semantics beyond what the schema provides, so 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 identifies a specific verb ('Retrieve') and resource ('a prompt') with a clear key qualifier ('by task name'), so an agent can tell this fetches one prompt rather than performing a write. It does not explicitly contrast with listPrompts or setPrompt, so it misses the highest level of sibling differentiation.

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?

'By task name' implies the tool is used when you know the task identifier and need its prompt, but the description never states when to prefer this over listPrompts or setPrompt. There are no explicit when/when-not conditions or alternatives, so the agent must infer usage from the name and sibling context.

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

listPromptsList PromptsA

List all available prompts with their content and versions

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It communicates that the tool returns prompt content and versions and implies a read-only list operation, but it does not disclose ordering, pagination, or whether all versions are returned for each prompt.

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?

A single, information-dense sentence with no wasted words. The primary action (List all) is front-loaded, and content/versions are specified as the result payload.

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

Completeness4/5

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

For a zero-parameter list tool, the description specifies scope and returned data sufficiently for an agent to select and call it. It could add detail about response shape or limits, but the tool is simple enough that this is not a critical gap.

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 is empty, so there are no parameters to document. The 100% schema coverage baseline for zero-parameter tools applies, and the description introduces no param-related ambiguity.

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 a specific action (List), the target resource (all available prompts), and the included payload (content and versions). Its all-encompassing scope clearly distinguishes it from the single-item getPrompt and mutating setPrompt siblings.

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 intended use for enumeration is implied by 'List all available prompts', but the description provides no explicit when-to-use guidance or references to alternative tools. An agent can infer the distinction from sibling names, but the description itself doesn't state it.

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

setPromptSet PromptA

Create or update a prompt for a task

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoOptional tags
contentYesThe prompt content
tasknameYesThe task name identifier
descriptionNoOptional description

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'Create or update' usefully signals upsert-like behavior, but it does not clarify whether updating replaces the entire prompt or only provided fields, nor does it mention side effects or prerequisites.

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 communicates the core purpose without filler. Every word contributes meaning, and the main action is 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?

For a simple four-parameter tool with no output schema, the description is mostly adequate and the schema covers parameter details. However, it omits the exact update semantics and return behavior, which an agent may need to invoke the tool with confidence.

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 all four parameters are already documented. The description adds only the conceptual relationship between 'prompt' and 'task', which is helpful but does not substantially extend the schema's parameter explanations.

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 names a specific action, 'Create or update', and a specific resource, 'a prompt for a task'. This clearly distinguishes setPrompt from its read-only siblings listPrompts and getPrompt, which do not create or update.

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: call this when you want to create or update a prompt for a task. However, it does not explicitly state when not to use it or mention alternatives such as getPrompt for retrieval, leaving some guidance implicit.

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. 3 tool updatesv0.0.5
    • First observedgetPrompt
    • First observedlistPrompts
    • First observedsetPrompt
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a clearly distinct role: listPrompts returns all prompts, getPrompt retrieves a single prompt by task name, and setPrompt creates or updates a prompt. There is no meaningful overlap or ambiguity between these operations.

Naming Consistency5/5

All three tool names follow a consistent camelCase verb-noun pattern: listPrompts, getPrompt, setPrompt. The naming makes each tool's behavior predictable and easy to infer.

Tool Count5/5

Three tools is well-scoped for a focused prompt management server. Each tool covers a core operation and none feel redundant or unnecessary.

Completeness3/5

The set covers listing, reading, and creating/updating prompts, but there is no delete operation, which leaves the CRUD lifecycle incomplete. Version information is mentioned in listPrompts but there is no dedicated tool for managing or retrieving specific versions.

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

  • promptflow-mcp

    RozuniFix72
    A
    license
    Not graded
    quality
    C
    maintenance
    A Model Context Protocol server for prompt template management, enabling storage, versioning, search, and rendering of prompt templates via MCP tools.
    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/ugmurthy/prompt-mcp-server'

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