Skip to main content
Glama
n0zer0d4y

Mercury Spec Ops MCP Server

by n0zer0d4y
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Mercury Spec Ops MCP Server: Prompts and Resources as Tools

TypeScript MCP Registry MCP Dev MCP Server MCP Server with Tools standard-readme compliant License: MIT

The first MCP server to expose dynamic, AI-invocable tools for prompt generation and template assembly.

Transform how AI assistants interact with specialized content. Instead of static prompts and resources, Mercury Spec Ops provides 6 programmable tools that enable AI to dynamically generate technology-specific prompts and comprehensive templates on-demand. Built on a sophisticated modular architecture with 31 technology stacks, 10 analysis dimensions, and 34 template sections—all accessible through simple tool calls.

Features

This MCP server provides a modular, extensible architecture with:

Prompts (Enhanced with Enum Support)

  1. PRD Prompt - Generate Product Requirements Document with modular technology-specific analysis

  2. Codebase Analysis Prompt - Analyze codebases with modular technology/focus-specific analysis

  3. Bug Analysis Prompt - Analyze bugs with modular severity/technology-specific analysis

Resources (Modular Templates)

  1. PRD Template - Modular PRD template with technology-specific sections

  2. Codebase Analysis Template - Modular codebase analysis template with technology/focus-specific sections

  3. Bug Analysis Template - Modular bug analysis template with severity/technology-specific sections

Related MCP server: MCP Probe Kit

Key Capabilities

Enum-Based Input Validation

  • Technology Stack (31 total):

    • Languages (11): JavaScript, TypeScript, Python, Java, Go, Rust, C#, PHP, Ruby, Swift, Kotlin

    • Runtimes (1): Node.js

    • Frontend (3): React, Angular, Vue

    • Backend (7): Express, NestJS, Django, Flask, Spring, Laravel, Rails

    • Databases (4): MongoDB, PostgreSQL, MySQL, Redis

    • Cloud (3): AWS, Azure, GCP

    • DevOps (2): Docker, Kubernetes

  • Analysis Focus (10 total): architecture, security, performance, testing, documentation, maintainability, scalability, reliability, code-quality, dependencies

  • Bug Severity (4 total): low, medium, high, critical

  • Target Audience: developers, business-users, enterprise, startup, healthcare, finance, and more

Programmatic Prompt Assembly

  • Base prompts + 31 technology modules + 10 focus modules + 4 severity modules

  • Automatic module selection based on input parameters

  • Priority-based module ordering

  • Multi-value support: Analyze multiple technologies and focus areas simultaneously

  • Comma-separated input: "node.js,react,postgresql" or "security,performance,code-quality"

  • Custom instruction integration

  • Intelligent fallback to base prompts

Modular Template System

  • Template sections with dependency resolution

  • Technology-specific template sections

  • Focus-specific template sections

  • Custom section support

Installation

Option 1: Local Development

  1. Clone and install dependencies:

git clone https://github.com/n0zer0d4y/mercury-spec-ops.git
cd mercury-spec-ops
npm install
npm run build

  1. Run the server locally:

npm run mcp

Option 2: Install from npm

npm install -g @n0zer0d4y/mercury-spec-ops

Or use directly with npx (no installation required):

npx @n0zer0d4y/mercury-spec-ops

Usage

Integration with MCP Clients

Configure the server in your MCP client (Claude Desktop, Cursor, etc.):

Using npx (Recommended - No Installation)

For Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "mercury-spec-ops": {
      "command": "npx",
      "args": ["-y", "@n0zer0d4y/mercury-spec-ops"]
    }
  }
}

For Cursor (~/.cursor/mcp.json):

{
  "mcpServers": {
    "mercury-spec-ops": {
      "timeout": 60,
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@n0zer0d4y/mercury-spec-ops"]
    }
  }
}

Using Local Installation

For Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "mercury-spec-ops": {
      "command": "node",
      "args": ["/path/to/mercury-spec-ops/dist/src/server.js"]
    }
  }
}

For Cursor (~/.cursor/mcp.json):

{
  "mcpServers": {
    "mercury-spec-ops": {
      "timeout": 60,
      "type": "stdio",
      "command": "node",
      "args": ["/path/to/mercury-spec-ops/dist/src/server.js"]
    }
  }
}

Windows Local Path Example (Cursor):

{
  "mcpServers": {
    "mercury-spec-ops": {
      "timeout": 60,
      "type": "stdio",
      "command": "node",
      "args": [
        "C:\\Development\\Projects\\MCP-Servers\\mercury-spec-ops\\dist\\src\\server.js"
      ]
    }
  }
}

Important Notes:

  • npx: Automatically fetches the latest version from npm (recommended for most users)

  • Local: Replace the path with your actual project location and run npm run build first

  • Restart: Restart your MCP client after configuration changes

Workflow Examples

Example 1: Enhanced Codebase Analysis

  1. User Prompt: "Analyze this Node.js/TypeScript codebase focusing on security and performance"

  2. Claude Desktop Action:

    • Calls the codebase-analysis-prompt with technology_stack: "node.js,typescript" and analysis_focus: "security,performance"

    • System programmatically assembles: base prompt + Node.js module + TypeScript module + security module + performance module

    • The prompt instructs Claude to first read the resource://codebase-analysis-template

    • Template builder assembles: base template + Node.js sections + TypeScript sections + security sections + performance sections

    • Claude reads the dynamically assembled template

    • Claude analyzes the codebase and generates a comprehensive technology-specific report

Example 2: Enhanced Bug Analysis

  1. User Prompt: "Analyze this critical security bug in React application"

  2. Claude Desktop Action:

    • Calls the bug-analysis-prompt with technology_stack: "react", severity_level: "critical", and bug_type: "security"

    • System assembles: base prompt + React module + security module + critical severity module

    • Template includes: general sections + React-specific + security-specific + critical-severity sections

    • Claude reads the bug analysis template

    • Claude analyzes the bug and generates a comprehensive technology and severity-specific report

Example 3: PRD Generation with Technology Support

  1. User Prompt: "Help me create a PRD for a React-based task management application"

  2. Claude Desktop Action:

    • Calls the prd-prompt with project details and technology_stack: "react"

    • System assembles: base prompt + React module

    • Template builder includes: base PRD template + React-specific considerations

    • Claude reads the technology-enhanced PRD template

    • Claude generates a comprehensive PRD with React-specific sections

Prompt Details

PRD Prompt

  • Name: prd-prompt

  • Arguments:

    • project_name (required): Name of the software project

    • project_description (required): Brief description of the project

    • target_audience (optional): Target audience for the product (enum values)

    • project_type (optional): Type of project (enum values)

    • key_features (optional): Key features to include in the PRD

    • technology_stack (optional): Technology stack to be used (enum values)

    • custom_instructions (optional): Custom instructions for PRD generation

Codebase Analysis Prompt

  • Name: codebase-analysis-prompt

  • Arguments:

    • repository_path (required): Path to the repository to analyze

    • technology_stack (required): Technology stack used in the codebase (enum values)

    • analysis_focus (optional): Focus areas for analysis (enum values)

    • custom_instructions (optional): Custom instructions for codebase analysis

Bug Analysis Prompt

  • Name: bug-analysis-prompt

  • Arguments:

    • repository_path (required): Path to the repository with bugs to analyze

    • bug_description (required): Description of the bug or issue to analyze

    • affected_components (optional): Components affected by the bug

    • severity_level (optional): Severity level of the bug (enum values)

    • bug_type (optional): Type of bug (enum values)

    • technology_stack (optional): Technology stack used in the affected components (enum values)

    • custom_instructions (optional): Custom instructions for bug analysis

Resource Details

PRD Template

  • URI: resource://prd-template

  • Format: Markdown

  • Content: Modular PRD template with technology-specific sections that dynamically assemble based on input parameters

Codebase Analysis Template

  • URI: resource://codebase-analysis-template

  • Format: Markdown

  • Content: Modular codebase analysis template with technology and focus-specific sections that assemble based on analysis parameters

Bug Analysis Template

  • URI: resource://bug-analysis-template

  • Format: Markdown

  • Content: Modular bug analysis template with severity and technology-specific sections that assemble based on bug parameters

Development

Project Structure

src/
├── server.ts                    # Main MCP server implementation
├── types/
│   ├── enums.ts                 # All enum definitions (31 tech + 10 focus)
│   └── index.ts                 # Type definitions and exports
├── prompts/
│   ├── modules/                 # 45 modular prompt components
│   │   ├── technology/          # 31 technology-specific modules
│   │   │   ├── languages/       # 11 language modules
│   │   │   ├── runtimes/        # 1 runtime module
│   │   │   ├── frameworks/      # 10 framework modules (3 frontend, 7 backend)
│   │   │   ├── databases/       # 4 database modules
│   │   │   ├── cloud/           # 3 cloud platform modules
│   │   │   └── tools/           # 2 DevOps tool modules
│   │   ├── analysis-focus/      # 10 focus-area modules
│   │   └── bug-severity/        # 4 severity-specific modules
│   ├── base-prompts/            # Base prompt templates
│   └── prompt-builder.ts        # Programmatic prompt assembly
├── resources/
│   ├── templates/               # Modular template components
│   │   ├── prd/                 # 10 PRD template modules
│   │   ├── codebase-analysis/   # 8 codebase analysis modules
│   │   └── bug-analysis/        # 4 bug analysis modules
│   └── template-builder.ts      # Programmatic template assembly
└── __tests__/                   # Comprehensive test suite (66 tests)
    ├── utils/                   # Utility function tests (enum parser)
    ├── prompts/                 # Prompt builder tests
    ├── resources/               # Template builder tests
    └── types/                   # Enum and type tests

Testing

The project includes a comprehensive test suite with 88% coverage:

# Run all tests
npm test

# Run tests in watch mode
npm run test:watch

# Run tests with coverage report
npm run test:coverage

# Run tests with interactive UI
npm run test:ui

# Test MCP integration
npm run test:mcp

Test Statistics:

  • 66 tests (100% passing)

  • 88.48% overall coverage

  • Statement coverage: 88.48%

  • Line coverage: 88.70%

Building for Production

npm run build

Linting

npm run lint

Extending the System

Adding New Technology Modules

  1. Add the technology to the TechnologyStack enum in src/types/enums.ts

  2. Create a new module file in the appropriate category:

    • Languages: src/prompts/modules/technology/languages/

    • Frameworks: src/prompts/modules/technology/frameworks/frontend/ or backend/

    • Databases: src/prompts/modules/technology/databases/

    • Cloud: src/prompts/modules/technology/cloud/

    • Tools: src/prompts/modules/technology/tools/

  3. Implement the TechnologyPromptModule interface

  4. Export from the category's index.ts

  5. Register it in prompt-builder.ts

  6. Add corresponding template sections in src/resources/templates/

  7. Write tests in src/__tests__/

Adding New Focus Areas

  1. Add the focus area to the AnalysisFocus enum in src/types/enums.ts

  2. Create a new module file in src/prompts/modules/analysis-focus/

  3. Implement the AnalysisFocusPromptModule interface

  4. Export from analysis-focus/index.ts

  5. Register it in prompt-builder.ts

  6. Add corresponding template sections

  7. Write tests

Adding New Severity Levels

  1. Add the severity to the BugSeverity enum in src/types/enums.ts

  2. Create a new module file in src/prompts/modules/bug-severity/

  3. Implement the BugSeverityPromptModule interface

  4. Register it in the prompt builder

  5. Add corresponding template sections

  6. Write tests

Contributing

Contributions are welcome! Please follow these guidelines:

  • Fork the repository and create a feature branch

  • Follow existing code patterns and maintain test coverage above 85%

  • Use Conventional Commits format (feat, fix, docs, test, chore)

  • Ensure all tests pass before submitting a pull request

  • See Extending the System for adding new modules

Report issues on GitHub Issues with clear reproduction steps.

License

This project is licensed under the MIT License - see LICENSE file for details.

Available Tools

6 tools
generate_bug_analysis_promptC

Generate an assembled bug analysis prompt with specified technology stacks and severity level

ParametersJSON Schema
NameRequiredDescriptionDefault
severityYesBug severity level
bug_contextNoOptional bug description or context
technology_stackYesTechnology stacks involved in the bug

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 must disclose behavior, but it only says 'generate' without explaining what happens (e.g., returns a prompt string, whether it calls an LLM, or any side effects). The term 'assembled' is ambiguous and not elaborated.

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

Conciseness4/5

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

The description is a single sentence with no wasted words, front-loading the core purpose. However, it could have been slightly more informative without becoming verbose, so it doesn't reach the 'zero waste plus added value' level of a 5.

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

Completeness2/5

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

The tool has no output schema and no annotations, and the description does not specify what the generated prompt looks like or what the caller should do with it. For a simple tool, this is still a notable gap that an agent would need to infer.

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 parameters. The description mentions technology_stack and severity, reinforcing the schema, but adds no extra meaning for the optional bug_context parameter.

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 a specific action ('Generate an assembled bug analysis prompt') and identifies the key inputs ('specified technology stacks and severity level'). While this distinguishes it from the sibling tools by name, it does not explicitly contrast with generate_codebase_analysis_prompt or generate_prd_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 is provided on when to use this tool versus alternatives like generate_codebase_analysis_prompt or get_bug_analysis_template. The description only states what it does, not the appropriate context or exclusions.

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

generate_codebase_analysis_promptA

Generate an assembled codebase analysis prompt with specified technology stacks and analysis focus areas

ParametersJSON Schema
NameRequiredDescriptionDefault
analysis_focusYesAreas to focus analysis on
technology_stackYesTechnology stacks to analyze

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says the tool 'generates an assembled prompt' but does not explain the output format, side effects, or how the assembly works. This leaves significant ambiguity about what the tool actually returns or does.

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 front-loads the verb and resource, with no filler or redundant content. It is appropriately sized for the tool's purpose.

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

Completeness3/5

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

The tool is simple and the schema covers parameters, but there is no output schema or description of what the generated prompt looks like. While the description is minimal, it is adequate for basic understanding, though it leaves room for more detail about the assembled prompt's content or return value.

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

Parameters3/5

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

The input schema has descriptions for both parameters (technology_stack and analysis_focus), providing 100% coverage. The description merely echoes these parameter names without adding new semantic detail, so it meets the baseline but does not exceed it.

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

Purpose5/5

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

The description clearly states the tool's action ('Generate') and resource ('codebase analysis prompt'), with qualifiers 'assembled', 'specified technology stacks', and 'analysis focus areas' that distinguish it from sibling prompt generators like generate_prd_prompt or generate_bug_analysis_prompt.

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 context (when you need a codebase analysis prompt) but does not explicitly mention when to use this tool over alternatives. Sibling tools exist but are not referenced, so the guidance is only implicit.

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

generate_prd_promptB

Generate an assembled Product Requirements Document prompt with specified technology stacks and analysis focus areas

ParametersJSON Schema
NameRequiredDescriptionDefault
analysis_focusNoAnalysis focus areas for the PRD
project_contextNoOptional project context or background information
technology_stackYesTechnology stacks to include in prompt assembly

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description should disclose behavioral traits. It only states the action of generating a prompt but does not mention whether it is a pure read-only operation, what the output looks like, or any side effects. This is a gap for a tool with no 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 sentence that front-loads the key information ('Generate an assembled Product Requirements Document prompt') and then specifies the inputs. Every word contributes to the 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?

The tool is simple, but with no output schema and no annotations, the description should at least state what the tool returns. It does not mention the output format or how the prompt is 'assembled', leaving the agent with uncertainties about the tool's behavior beyond the parameters.

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 already provides descriptions for all three parameters, so the baseline is 3. The description's mention of 'specified technology stacks and analysis focus areas' aligns with the parameters but does not add significant meaning beyond what the schema already states.

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

Purpose5/5

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

The description uses the specific verb 'generate' and identifies the resource as an 'assembled Product Requirements Document prompt'. It mentions the key inputs (technology stacks and analysis focus areas), clearly distinguishing this from sibling tools like generate_codebase_analysis_prompt or get_prd_template by specifying the PRD context.

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 when to use the tool (when needing an assembled PRD prompt with specified stacks and focus areas) but does not explicitly state when not to use it or name alternatives like get_prd_template for simple templates. There is no guidance on selecting between this and the sibling prompt-generating tools.

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

get_bug_analysis_templateA

Fetch a comprehensive bug analysis markdown template with all standard sections (8 sections total)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It does convey that this is a fetch operation (implying read-only) and mentions the template has 8 sections, which adds some transparency. However, it doesn't describe the return format, any limitations, or what the template actually includes beyond the section count. For a simple template retrieval, this is adequate but not rich.

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 front-loads the verb and resource, includes a meaningful detail ('8 sections total'), and contains no fluff or redundant information. It is perfectly sized for a simple tool with no parameters.

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 low-complexity tool with no parameters and no output schema, the description covers the essential purpose and content. It could be improved by noting that this is a static template versus the dynamic generation provided by generate_bug_analysis_prompt, which would help the agent choose correctly, but the given description is still sufficiently complete for the tool's simplicity.

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

Parameters4/5

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

The tool has zero parameters, and the input schema is an empty object, so there are no parameter semantics to explain. The baseline for 0 params is 4, and the description adds useful context about the output (8 sections) without being parameter-related.

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

Purpose5/5

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

The description uses a specific verb 'Fetch' and names the exact resource 'comprehensive bug analysis markdown template.' The added detail '8 sections total' gives specificity and differentiates it from sibling template tools like get_prd_template and get_codebase_analysis_template, as well as from generate_bug_analysis_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?

The description offers no guidance on when to use this tool versus alternatives such as generate_bug_analysis_prompt. It does not state that this is a static template for standard use, nor does it mention that a custom prompt would require the sibling tool. This lack of context leaves the agent to infer usage without explicit direction.

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

get_codebase_analysis_templateA

Fetch a comprehensive codebase analysis markdown template with all standard sections (12 sections total)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/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 burden. The verb 'Fetch' implies a read-only operation, and the detail about 12 sections gives some expectation of the return. However, it does not disclose potential side effects, prerequisites, or whether the template is static or dynamically generated. This is acceptable for a simple getter but not rich.

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?

One single sentence, front-loaded with the action and resource, and every word earns its place. No fluff or repetition.

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

Completeness5/5

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

With zero parameters and no output schema, the description fully conveys the tool's output (a comprehensive template with 12 standard sections) and is sufficient for an agent to invoke it correctly. No additional context is needed.

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 schema has zero parameters, so there is nothing to document. The description adds no parameter-specific meaning, but the baseline of 4 applies for seamlessly handling the no-parameter case.

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?

Uses the specific verb 'Fetch' and names the resource 'comprehensive codebase analysis markdown template', with a concrete detail (12 sections total). This clearly distinguishes it from sibling template tools for PRDs or bug analysis and from the prompt-generation tools.

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 states what the tool does but gives no explicit guidance on when to choose it over the sibling generate_codebase_analysis_prompt or other template getters. There is no mention of alternatives or exclusions, so the agent is left to 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_prd_templateA

Fetch a comprehensive Product Requirements Document markdown template with all standard sections (14 sections total)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the transparency burden. It clearly communicates a read-only 'Fetch' operation (implying no side effects) and discloses the output format (markdown) and content scope (all standard sections, 14 total). This is sufficient behavioral context for a simple template retrieval 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, well-structured sentence that front-loads the action and resource. Every element adds value: 'comprehensive', 'markdown template', 'all standard sections (14 sections total)'. There is no redundancy or extraneous information.

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, no-output-schema tool, the description is nearly complete: it specifies the resource (PRD template), the format (markdown), and the scope (14 sections). It could optionally mention return type or safety, but these are either implied or available after invocation. The description fully covers the tool's purpose.

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

Parameters4/5

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

The tool has zero parameters, so the baseline score is 4. The description adds no parameter-specific details (as none exist) but mentions content characteristics ('14 sections total'), which is appropriate given there is nothing else to document.

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

Purpose5/5

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

The description uses a specific verb ('Fetch') and resource ('Product Requirements Document markdown template'), and explicitly mentions '14 sections total' to define scope. It clearly distinguishes itself from sibling tools like get_codebase_analysis_template and get_bug_analysis_template by focusing specifically on PRD templates.

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

Usage Guidelines4/5

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

The description implies usage: users should call this tool when they need a PRD markdown template. The resource is explicitly identified, providing clear context without naming alternatives. It does not explicitly state when not to use it, but the distinction from sibling tools is implicit through the PRD-specific wording.

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. 6 tool updatesv0.1.2
    • First observedgenerate_bug_analysis_prompt
    • First observedgenerate_codebase_analysis_prompt
    • First observedgenerate_prd_prompt
    • First observedget_bug_analysis_template
    • First observedget_codebase_analysis_template
    • First observedget_prd_template
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored across 6 tools

Disambiguation5/5

Each tool is clearly tied to a specific domain (PRD, codebase analysis, bug analysis) and a specific action (generate prompt or fetch template). There is no overlap between the six tools, so an agent can reliably select the correct one.

Naming Consistency5/5

All tool names follow the consistent pattern generate_<domain>_prompt or get_<domain>_template. The distinction between 'prompt' and 'template' is meaningful and matches the tool function, and the domain segment is consistent throughout.

Tool Count5/5

Six tools is well-scoped for a prompt/template serving server. Each tool serves a distinct purpose, and the count is large enough to be useful without being bloated.

Completeness5/5

For each of the three domains, there is both a prompt generator and a template fetcher, covering the full lifecycle of using these resources. There are no obvious missing operations within the stated purpose of the server.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Smart Code Reviewer

    renjismzy
    A
    license
    A
    quality
    D
    maintenance
    Enables comprehensive code analysis including quality assessment, security vulnerability detection, refactoring suggestions, complexity calculations, and automatic documentation generation for multiple programming languages.
    5
    7
    MIT

  • MCP Probe Kit

    mybolide
    A
    license
    A
    quality
    A
    maintenance
    A comprehensive development toolkit with 23 tools covering code quality analysis, development efficiency, and project management. Enables AI-assisted code review, test generation, performance analysis, SQL generation, UI component creation, and automated project documentation.
    24
    96
    36
    MIT

  • Code-MCP

    millsydotdev
    F
    license
    B
    quality
    Not graded
    maintenance
    Turns AI assistants into full-stack software engineers with 36 tools for cognitive reasoning, code validation, project scaffolding, and AI/IDE configuration generation across 130+ programming languages, databases, and frameworks.
    35
    9
    -