Skip to main content
Glama
miniOrangeDev

WordPress Code Review MCP Server

by miniOrangeDev
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

WordPress Code Review MCP Server v2.0

A lightweight, configurable MCP (Model Context Protocol) server for development teams. Fetches coding guidelines, security rules, and validation patterns from external sources or URL where you have hosted your custom guidelines.

🚀 Key Features

  • ✅ No hardcoded rules - Fetch guidelines from any URL

  • ✅ Dynamic configuration - Specify source via environment variables

  • ✅ Custom validation - Add your own coding standards and security rules

  • ✅ Lightweight - External guidelines, minimal codebase

Related MCP server: mcp-rules-server

📋 Available Tools

  • get_guidelines - Fetch development guidelines by category

  • validate_code - Validate code against configured standards

  • security_check - Security vulnerability scanning

📋 Prerequisites

  • Node.js installed (v18+)

🛠 Installation & Setup

Step 1: Clone Repository

git clone https://github.com/miniOrangeDev/wp-code-review-mcp-server.git
cd wp-code-review-mcp

Step 2: Install Dependencies & Build

npm install
npm run build

Step 3: Host Your Guidelines

Host the files from sample-guidelines/html/ on your web server and configure your base URL, for example: https://yourdomain.com/guidelines/

The MCP server will fetch:

  • https://yourdomain.com/guidelines/guidelines.md

  • https://yourdomain.com/guidelines/validation-rules.md

  • https://yourdomain.com/guidelines/security-rules.md

Step 4: Configure Cursor

Add to your Cursor settings (Ctrl+Shift+P → "Preferences: Open User Settings (JSON)"):

{
  "mcpServers": {
    "wp-code-review-mcp": {
      "command": "node",
      "args": ["/path/to/wp-code-review-mcp-server/build/index.js"],
      "env": {
        "GUIDELINES_URL": "https://yourdomain.com/guidelines"
      }
    }
  }
}

Replace /path/to/wp-code-review-mcp-server with your actual path (e.g., /home/wp-code-review-mcp-server)

Why the path? Unlike published npm packages, this is a local MCP server. The path tells Cursor exactly where to find your built server file.

If you don't see MCP server connected, restart Cursor and the MCP server will be available.

Guidelines Format

Your guidelines server should serve these files:

  • /guidelines.md - Main development guidelines

  • /validation-rules.md - Code validation rules

  • /security-rules.md - Security scanning rules

Step 5: Test in Cursor

  1. Open any PHP file in Cursor

  2. Ask the AI: "Check this code for security issues: class mo_Test {}"

  3. The AI should detect the short prefix violation!

🔧 Troubleshooting

Having configuration issues? See the Configuration Troubleshooting Guide for common mistakes and solutions.

📝 Customizing Guidelines

Edit the files in sample-guidelines/html/ to add your own:

  • Coding standards

  • Validation rules

  • Security patterns

  • Company-specific guidelines

The MCP server automatically uses updated rules without restart.

📄 License

MIT License

Built for Dynamic, Maintainable Development Guidelines 🛡️

Available Tools

3 tools
get_guidelinesB

Get development guidelines from the configured source

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoOptional category of guidelines to retrieve (e.g., security-rules, validation-rules)

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states 'Get development guidelines' without indicating side effects, access requirements, rate limits, or that it is a read-only operation. This is insufficient for safe invocation.

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

Conciseness4/5

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

The description is a single concise sentence without fluff. It effectively communicates the core action in a front-loaded manner. Minor improvement possible by adding return behavior.

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 simple tool with one optional parameter and no output schema, the description lacks information about the return value format or content. This gap reduces completeness, as agents need to infer what is returned.

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 coverage is 100% with a description for the optional 'category' parameter. The tool description adds no new meaning or context about parameters, so it meets the baseline expectation 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 tool name 'get_guidelines' and description 'Get development guidelines from the configured source' clearly state the verb (Get) and resource (development guidelines). The action is distinct from siblings 'security_check' and 'validate_code', which serve different purposes.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool over alternatives or in what context. The description does not mention prerequisites, exclusions, or preferred scenarios, leaving the agent without decision-support information.

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

security_checkB

Perform security analysis on code using configured security rules

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesThe code to check for security issues

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided, so the description carries full burden. It does not disclose whether the tool is read-only, requires network, or modifies anything. Only states it performs analysis, lacking behavioral details.

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?

Single sentence, no wasted words. Front-loaded with the action and scope. Efficiently communicates the core function.

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 tool with one parameter and no output schema, the description is adequate but incomplete. It fails to mention the format of results (e.g., list of issues, pass/fail), which an agent would need to plan next steps.

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 coverage is 100% with a description for the single parameter 'code'. The description adds 'using configured security rules' but doesn't significantly enhance meaning beyond the schema. Baseline 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 tool analyzes code for security issues using configured rules. It distinguishes itself from sibling tools like 'validate_code' by focusing on security, though it doesn't explicitly differentiate.

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 'get_guidelines' or 'validate_code'. The description provides no context for appropriate use cases or limitations.

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

validate_codeB

Validate code against configured coding standards

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesThe code to validate
languageYesThe programming language of the code

TDQS

B3.1/5.0
Behavior2/5

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

Without annotations, the description carries full responsibility for behavioral disclosure, but it only states what the tool does, not how it behaves (e.g., side effects, return format, errors).

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, very concise. While it could be expanded slightly, it contains no unnecessary words and is well-structured for its brevity.

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

Completeness2/5

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

Given no annotations, no output schema, and only two parameters, the description lacks complete context. It does not explain 'configured coding standards,' how results are returned, or error handling.

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 already describes both parameters fully (100% coverage). The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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 action ('Validate code') and the resource ('against configured coding standards'), effectively distinguishing it from siblings like get_guidelines and security_check.

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 its siblings (get_guidelines, security_check). The description does not mention alternatives or contexts.

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

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

TDQS

A3.6/5.0
Disambiguation5/5

Each tool targets a distinct aspect of code review: fetching guidelines, performing security analysis, and validating coding standards. There is no overlap in their purposes, making them easily distinguishable for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (get_guidelines, security_check, validate_code). The naming is clear and predictable, aiding in tool selection.

Tool Count5/5

Three tools is appropriate for a simple code review server, covering essential tasks without overwhelming the user. The count is well-scoped for the domain.

Completeness4/5

The tools cover core code review operations: retrieving guidelines, security checking, and validation. Minor gaps exist (e.g., no tool for submitting code for full review), but the surface is sufficient for basic automation.

Maintenance

ActivityInactive
ResponsivenessSyncing

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

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/miniOrangeDev/wp-code-review-mcp-server'

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