Which integrations are available for this server?

Allows searching, downloading, extracting, and comparing WordPress.org plugins with local plugins, including detailed diffs and file analysis.

How do I use WordPress Plugin Directory MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WordPress Plugin Directory MCP Server Search for form builder plugins" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

WordPress Plugin Directory MCP Server

by juanma-wp

Overview Schema Related Servers Score Discussions

TypeScript

Local

WordPress Plugin Directory MCP Server

Tests

npm version npm downloads

A Model Context Protocol (MCP) server that enables Claude Code to analyze, download, and compare WordPress.org plugins with your local plugins.

🔗 Repository: https://github.com/juanma-wp/wordpress-org-mcp

Features

Search plugins on WordPress.org by keyword
Download plugins directly from WordPress.org
Extract and analyze plugin files
Compare local plugins with WordPress.org versions
Generate detailed diffs between plugin versions
Browse plugin file structures

Related MCP server: WordPress MCP Server

Installation & Setup

# Register with Claude CLI
claude mcp add wordpress-org npx wordpress-org-mcp-server

# Verify registration
claude mcp list

Available Tools

`search_plugins`

Search for WordPress.org plugins by keyword.

Parameters:

query (string): Search query
limit (number, optional): Maximum results (default: 10)

Example:

Search for "jwt authentication" plugins

`get_plugin_info`

Get detailed information about a specific plugin.

Parameters:

slug (string): Plugin slug

Example:

Get info for plugin "jwt-authentication-for-wp-rest-api"

`download_plugin`

Download a plugin from WordPress.org.

Parameters:

slug (string): Plugin slug
version (string, optional): Version (default: "latest")

`extract_plugin`

Extract a downloaded plugin ZIP file.

Parameters:

slug (string): Plugin slug
zip_path (string, optional): Path to ZIP file

`list_plugin_files`

List files in an extracted plugin.

Parameters:

slug (string): Plugin slug
extension (string, optional): Filter by extension (.php, .js, etc.)

`read_plugin_file`

Read contents of a specific plugin file.

Parameters:

slug (string): Plugin slug
file_path (string): Relative path to file

`compare_plugins`

Compare local plugin with WordPress.org version.

Parameters:

local_path (string): Path to local plugin directory
wp_org_slug (string): WordPress.org plugin slug
format (string, optional): "summary" or "detailed" (default: "summary")

Example:

Compare my local plugin with WordPress.org version:
- local_path: "/absolute/path/to/rest-auth-jwt"
- wp_org_slug: "jwt-authentication-for-wp-rest-api"

`get_file_diff`

Get detailed diff for a specific file.

Parameters:

local_path (string): Path to local plugin
wp_org_slug (string): WordPress.org plugin slug
file_path (string): Relative path to file

Example Workflow

Search for similar plugins:

Search for JWT authentication plugins to see what's available

Get plugin details:

Get detailed info for "jwt-authentication-for-wp-rest-api"

Compare with your local plugin:

Compare my local plugin at "/path/to/my/plugin" with "jwt-authentication-for-wp-rest-api"

Examine specific differences:

Show me the diff for "includes/class-auth.php" between my plugin and "jwt-authentication-for-wp-rest-api"

Plugin Storage Locations

The server stores downloaded and extracted plugins in system directories to avoid cluttering your project workspace:

Default Locations

macOS:

Cache (downloads): ~/Library/Caches/wordpress-org-mcp/
Extractions: /tmp/wordpress-org-mcp-extractions/

Linux:

Cache (downloads): ~/.cache/wordpress-org-mcp/ (or $XDG_CACHE_HOME/wordpress-org-mcp/)
Extractions: /tmp/wordpress-org-mcp-extractions/

Windows:

Cache (downloads): %LOCALAPPDATA%\wordpress-org-mcp\Cache\
Extractions: %TEMP%\wordpress-org-mcp-extractions\

Customizing Storage Locations

Set these environment variables before registering the MCP server:

# Set custom paths
export WP_MCP_CACHE_DIR="/path/to/custom/cache"
export WP_MCP_EXTRACT_DIR="/path/to/custom/extractions"

# Register the MCP server (will use custom paths)
claude mcp add wordpress-org npx wordpress-org-mcp-server

**Persistent Setup:**
Add the environment variables to your shell profile (`.bashrc`, `.zshrc`, `.bash_profile`, etc.):

```bash
echo 'export WP_MCP_CACHE_DIR="/path/to/custom/cache"' >> ~/.zshrc
echo 'export WP_MCP_EXTRACT_DIR="/path/to/custom/extractions"' >> ~/.zshrc
source ~/.zshrc

Environment Variables:

WP_MCP_CACHE_DIR: Custom directory for downloaded ZIP files
WP_MCP_EXTRACT_DIR: Custom directory for extracted plugin files

Why System Directories?

No Git conflicts: Downloaded plugins won't appear in your project's version control
Cross-platform compatibility: Uses appropriate directories for each operating system
Easy cleanup: Temporary extractions are automatically cleaned up on system restart

Development

# Watch mode for development
npm run dev

# Build for production
npm run build

# Start the server
npm start

Troubleshooting

"Plugin not found" errors: Verify the plugin slug is correct on WordPress.org
Download failures: Check internet connection and WordPress.org availability
Extraction errors: Ensure sufficient disk space and file permissions

Supported File Types

PHP files (.php)
JavaScript files (.js)
CSS files (.css)
Text files (.txt, .md)
Configuration files (.json, .xml, .yml)

Binary files are compared by size only.

Available Tools

8 tools

compare_pluginsB

Compare a local plugin with a WordPress.org plugin

ParametersJSON Schema

Name	Required	Description	Default
`local_path`	Yes	Path to local plugin directory
`wp_org_slug`	Yes	WordPress.org plugin slug to compare against
`format`	No	Output format (default: "summary")	summary

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description is too brief to disclose behavioral traits. It does not state whether the comparison involves network requests, what aspects are compared (versions, files, etc.), or any side effects. The description carries the full burden but fails to provide meaningful transparency.

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 with no wasted words. For such a short description, it is efficient, though it could benefit from more structure or detail.

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 has 3 parameters and no output schema, the description is insufficient. It omits return value details, comparison scope, prerequisites (e.g., both plugins must be accessible), and any limitations. This would leave an AI agent uncertain about how to interpret results.

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%, so the schema already documents parameters fully. The description adds no extra meaning beyond what the schema offers, which meets the baseline for high coverage. However, it does not elaborate on how parameters affect the comparison.

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?

Description clearly states the tool compares a local plugin with a WordPress.org plugin. It uses a specific verb and resource, and the sibling tools (download, extract, get info, etc.) do not overlap in function, so it is distinct.

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 vs. alternatives. The description does not mention scenarios, exclusions, or prerequisites. A tool for comparison should specify context, but it does not.

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

download_pluginC

Download a plugin from WordPress.org

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Plugin slug to download
`version`	No	Plugin version (default: "latest")	latest

TDQS

C2.8/5.0

Behavior1/5

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

With no annotations and no output schema, the description fails to disclose what the tool returns (e.g., file content, binary data, or a link) or any side effects, leaving the agent uninformed about behavior.

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 fluff, achieving concise communication, though it could be slightly more structured.

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

Completeness1/5

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

Given no output schema, the description should explain return formats or error handling; it does not, making the tool incomplete for 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?

Schema coverage is 100% with descriptions for both parameters, so the description adds no extra meaning beyond the schema, resulting in a baseline score.

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 verb 'Download' and the resource 'plugin from WordPress.org', which distinguishes it from sibling tools like search_plugins or get_plugin_info, which have 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 on when to use this tool versus alternatives such as search_plugins or get_plugin_info, nor any prerequisites (e.g., need for a plugin slug from search).

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

extract_pluginC

Extract a downloaded plugin ZIP file

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Plugin slug to extract
`zip_path`	No	Path to the plugin ZIP file (optional if already downloaded)

TDQS

C2.9/5.0

Behavior2/5

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

Without annotations, the description should disclose behavioral details (e.g., overwriting, destination, side effects). It only states the action, leaving significant opacity.

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 with no superfluous words, though it lacks structural formatting like headings or bullet points.

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 2 parameters and no output schema, the description omits operational details (e.g., extraction location, error handling, undo capability), making it insufficient.

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%; the description adds minor context (e.g., 'optional if already downloaded') but does not significantly enhance understanding 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 ('Extract') and the resource ('a downloaded plugin ZIP file'), distinguishing it from siblings like download_plugin or compare_plugins.

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 (e.g., download_plugin, list_plugin_files), nor are prerequisites or exclusions mentioned.

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

get_file_diffB

Get detailed diff for a specific file between local and WordPress.org plugin

ParametersJSON Schema

Name	Required	Description
`local_path`	Yes	Path to local plugin directory
`wp_org_slug`	Yes	WordPress.org plugin slug
`file_path`	Yes	Relative path to the file to diff

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and description lacks behavioral details such as output format, side effects, or permissions required.

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 of 11 words, front-loaded with key action and resource, no 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?

Missing output format details (what a diff looks like) and usage context; incomplete for a diff tool with no output schema.

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 covers 100% of parameters with descriptions; description adds no extra semantic value beyond the schema.

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 'Get detailed diff for a specific file between local and WordPress.org plugin' uses specific verb and resource, clearly distinguishes from sibling tools like compare_plugins and read_plugin_file.

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; does not mention conditions or exclusions.

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

get_plugin_infoC

Get detailed information about a specific plugin

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Plugin slug (e.g., "jwt-authentication-for-wp-rest-api")

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 fully disclose behavioral traits. It only states 'get detailed information', omitting specifics like permissions, side effects, or what constitutes 'detailed information'. This is insufficient.

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, efficient sentence with no unnecessary words. It is appropriately sized but could include more context without becoming verbose.

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 output schema and annotations, the description is too minimal. It does not explain what the tool returns, leaving the agent without enough context to correctly use it.

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% as the single parameter 'slug' is described. The description does not add extra meaning beyond what the schema already provides, meeting the baseline 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 verb 'Get' and resource 'detailed information about a specific plugin', making the basic purpose understandable. However, it does not differentiate from sibling tools like 'compare_plugins' or 'read_plugin_file', leaving room for ambiguity.

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. The description does not mention any prerequisites, exclusions, or specific contexts.

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

list_plugin_filesC

List files in an extracted plugin

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Plugin slug
`extension`	No	Filter by file extension (e.g., ".php", ".js")

TDQS

C2.9/5.0

Behavior2/5

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

Without annotations, the description carries full responsibility. It only says 'list files' without specifying output format, recursion depth, or whether it returns full paths. Minimal behavioral disclosure.

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 short sentence, which is efficient and easy to read. It could include more detail without being verbose, but it is appropriately concise.

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 two parameters and no output schema. The description does not explain what is returned (e.g., file names, paths, recursive listing) or how the extension filter works. Lacks completeness for a list operation.

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 explains both parameters. The tool description does not add extra meaning beyond what is in 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 (list) and the resource (files in an extracted plugin). It is distinct from sibling tools like read_plugin_file or get_plugin_info, though it does not 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 is provided on when to use this tool versus alternatives. The description implies usage after extraction but lacks explicit context or exclusions.

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

read_plugin_fileB

Read the contents of a specific file from an extracted plugin

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Plugin slug
`file_path`	Yes	Relative path to the file within the plugin

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits like read-only nature, error handling (e.g., file not found), or size limits, but only states 'Read the contents'.

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, making it highly concise and easy to parse.

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 description omits key context: the necessity of prior plugin extraction, the output format (e.g., raw text), and error behavior, leaving the agent underinformed.

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 provides clear descriptions for both parameters ('Plugin slug' and 'Relative path'), and the tool description adds no extra meaning beyond that.

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 'Read the contents' and the resource 'a specific file from an extracted plugin', distinguishing it from sibling tools that list files, compare plugins, or get plugin info.

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, nor does it mention prerequisites like the plugin needing to be extracted first.

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

search_pluginsA

Search for WordPress.org plugins by keyword

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query for plugins
`limit`	No	Maximum number of results (default: 10)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It mentions 'search by keyword' but omits details like result format, pagination (if any), whether the search is case-sensitive, or any authentication requirements. For a public API tool, this is a significant gap.

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-formed sentence that uses active voice and is free of unnecessary words. It efficiently conveys the core purpose without redundancy.

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 keyword search tool with two parameters, the description is adequate but minimal. It does not explain the return value (e.g., list of plugin names, slugs, or full objects), nor does it address edge cases like empty results or rate limits. Given the lack of an output schema, more detail would be 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 already covers both parameters (query and limit) with descriptions. The description adds minimal value by confirming 'query' is a keyword search. With 100% schema coverage, baseline is 3, and the description does not significantly enhance understanding beyond what the schema provides.

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 ('Search') and the resource ('WordPress.org plugins'), with a specific method ('by keyword'). This effectively distinguishes it from sibling tools like 'get_plugin_info' (which retrieves details for a known plugin) or 'compare_plugins'.

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 the tool is for finding plugins based on keywords, but it does not explicitly state when to use it over alternatives (e.g., when you have a specific plugin name, use 'get_plugin_info'). No guidance on when not to use it or what to do if the search is too broad.

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.

8 tool updatesv1.0.5May 30, 2026
- First observedcompare_plugins
- First observeddownload_plugin
- First observedextract_plugin
- First observedget_file_diff
- First observedget_plugin_info
- First observedlist_plugin_files
- First observedread_plugin_file
- First observedsearch_plugins

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 operation: search, get info, download, extract, list files, read file, compare, and diff. No two tools overlap in purpose; agents can easily distinguish them.

Naming Consistency5/5

All tool names follow the verb_noun snake_case pattern consistently (e.g., search_plugins, get_plugin_info, list_plugin_files). No deviations or mixed conventions.

Tool Count5/5

With 8 tools, the set is well-scoped for a plugin directory server. It covers the essential workflow (search, get info, download, extract, browse files) without being bloated or sparse.

Completeness5/5

The tools cover the full lifecycle of interacting with WordPress.org plugins: searching, retrieving info, downloading, extracting, inspecting files, and comparing with local plugins. No obvious gaps for the intended domain.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
com.googleapis.stitch
Interact with the Stitch API using natural language commands.
Search App Automation
152
Astravue MCPOAuth
com.astravue
Manage projects, tasks, time tracking, and team collaboration through natural language.
Project Management Workplace & Productivity
312
Sigistry Plugin & Skill Catalog A
com.sigistry
Search verified Claude Code plugins and skills; fetch portable SKILL.md sources. Read-only.
Developer Tools
61
GitHubOAuth
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1232,723

Related MCP Servers

WordPress MCP Server
Content Management Systems App Automation
gaupoit
A
license
A
quality
D
maintenance
Enables AI assistants to manage WordPress sites through natural conversation, supporting post creation, content updates, site queries, and draft-to-publish workflows via the WordPress REST API.
Updated 8 months ago (2026-01-03 04:47 UTC)
9
MIT
WordPress MCP Server
Content Management Systems E-commerce & Retail
c-sakel
A
license
C
quality
C
maintenance
Enables AI assistants to manage WordPress content, design, SEO, WooCommerce, and more through natural language commands.
Updated 8 months ago (2026-01-03 15:56 UTC)
100
32
3
MIT
WordPress MCP Server
Content Management Systems Developer Tools
InstaWP
A
license
Not graded
quality
A
maintenance
Enables interaction with WordPress sites through the WordPress REST API via natural language, supporting single and multi-site management, content and taxonomy operations, media uploads, and more.
Updated 18 days ago (2026-08-19 09:16 UTC)
364
98
GPL 3.0
WordPress Developer MCP Server
Content Management Systems Developer Tools Command Line
nightnei
A
license
Not graded
quality
B
maintenance
Enables creating, customizing, managing, and sharing local WordPress sites through natural language, leveraging WP-CLI and AI integration.
Updated 2 months ago (2026-07-03 11:24 UTC)
65
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/juanma-wp/wordpress-org-mcp'

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