local-wp-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation4/5
Most tools target distinct resources (sites, WP-CLI, database, files). The main overlap is wp_active_plugins vs wp_cli_run 'plugin list', but descriptions clarify the direct database query vs CLI execution. Otherwise, each tool serves a clear purpose.
Naming Consistency4/5
Tools use clear prefixes for domains (wp_*, mysql_*) and consistent verb_noun for file operations (read_site_file, write_site_file). Minor inconsistency: wp_cli_run is noun_verb rather than verb_noun, and file operations lack a prefix, but the pattern is still predictable.
Tool Count5/5
10 tools is well-scoped for a local WordPress development server covering sites, WP-CLI, database, and file operations. Each tool earns its place without feeling redundant or excessive.
Completeness4/5
The surface covers core workflows: read/write files, query database, run WP-CLI, list sites, and inspect schema. A minor gap is the lack of a tool to switch the 'current site' referenced by wp_site_info, but overall the lifecycle is adequately covered.
Average 4.2/5 across 10 of 10 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the context that the tool queries the database 'directly', implying a direct DB access rather than a WP-CLI call. However, it does not disclose return format, performance implications, or any other 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?
The description is a single concise sentence, front-loaded with the action and object. Every word adds value and there is no redundancy or embellishment.
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?
Given the tool's low complexity (one optional parameter, clear intent) and good annotations, the description is nearly complete. The absence of an output schema means the description could specify the return format, but the purpose is transparent 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for its single parameter 'site', with a clear description. The tool description does not add any additional parameter semantics beyond what the schema already 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.
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 function: 'Query the database directly to get the list of active WordPress plugins.' The verb 'get' and resource 'active WordPress plugins' are specific, and the addition of 'directly to database' distinguishes it from sibling tools like wp_cli_run.
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 such as mysql_query or wp_cli_run. The description gives no context for choosing this tool, no exclusions, and no mention of alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the conditional behavior (list all vs. column details), but much of that is already present in the input schema's table parameter description. It doesn't add information about return format, site resolution (env var fallback), or potential edge cases, making this a baseline score.
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?
Two sentences, front-loaded with the main purpose and followed by concise conditional behavior. Every word contributes meaning; no filler or redundancy.
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?
Given the tool's simplicity, two parameters, and read-only annotations, the description adequately covers the main behavior. The only gap is the absence of return format details, but with no output schema, this is not critical. The description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description largely restates the table parameter behavior ('With a table name, shows column details') without adding new semantics beyond what the schema provides. Thus, the description adds minimal value over the structured 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 uses a specific verb ('Get') and clearly identifies the resource ('the schema of the WordPress database'), which distinguishes it from sibling tools like mysql_query (queries) and wp_site_info (site metadata). It also communicates two distinct behaviors based on the table parameter, reinforcing its purpose.
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 explicitly explains when to use each mode: without a table name, list all tables; with a table name, show column details. This provides clear context for using the tool effectively, though it does not explicitly exclude alternatives or compare to sibling tools. That nuance keeps it at a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's read-only nature is clear. The description adds transparency by specifying exactly which site details are returned, giving the agent expectation of output.
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 one well-crafted sentence that frontloads the action and resource, then lists concrete examples of returned data. No filler or redundancy.
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?
For a read-only info tool with one optional parameter and annotations covering safety, this description is complete. It clearly states the tool's purpose, what it retrieves, and the source (Local by Flywheel WordPress site), which is sufficient for an agent to select and invoke 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?
The single parameter 'site' is fully described in the schema ('Site name, ID, or domain. Uses env var if not specified.'). The description does not add information about parameter formatting or defaults beyond what the schema provides, so it relies on 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 uses the specific verb 'Get' and names the resource as 'detailed information about the current Local by Flywheel WordPress site', enumerating key fields (URL, version, theme, PHP). This clearly distinguishes it from sibling tools like wp_list_sites (which lists sites) and mysql_query (which queries database).
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 retrieving site details but does not explicitly state when to choose it over alternatives such as wp_cli_run or mysql_query. There is no mention of exclusions or alternative contexts, leaving room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict these. It adds useful behavioral details: returns file names, types, and sizes, and clarifies that the path is relative to the site root, which goes beyond the annotations.
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 concise and front-loaded with the primary action in the first sentence. Each sentence adds value (scope, path constraint, return types), with no unnecessary words.
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 listing tool with detailed annotations and schema, the description covers the essential behavior: listing, path, and return contents. It lacks specifics like recursion depth or error handling, but overall it is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both parameters have descriptions. The tool description only restates that the path is relative (already in the schema) and doesn't add new parameter-specific meaning, so the baseline 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 tool's function: 'List files and directories in a Local by Flywheel site directory.' The verb 'List' and resource are specific, and it distinguishes itself from siblings like read_site_file (reads a single file) and search_site_files (searches) by focusing on directory listing.
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 provides clear context on when to use the tool: to enumerate files/directories with a path relative to the site root. It does not explicitly mention alternatives or exclusions, but the scope is well-defined and the example path guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=false, indicating writes are possible. The description adds the specific condition (MYSQL_ALLOW_WRITES=true) and lists the always-allowed query types, which is valuable behavioral context beyond the annotations. It does not mention result format or side effects, but the write permission gating is a key disclosure.
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 two sentences, front-loaded with the main purpose and followed by a constraint. Every sentence contributes essential information without redundancy or fluff.
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?
Given the tool's complexity (arbitrary SQL execution) and lack of output schema, the description covers the core purpose and critical permission constraints. Some details like return format or handling of non-listed DDL queries are omitted, but the description is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (site and query) with 100% coverage, including an example for query. The description does not add meaning beyond the schema; it only repeats that it executes a SQL query, so the baseline 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 'Execute a SQL query against the WordPress database', using the specific verb 'Execute' and identifying the resource. It also enumerates allowed query types (SELECT, SHOW, DESCRIBE, EXPLAIN) and write conditions, which distinguishes this tool from siblings like wp_cli_run (WP-CLI commands) and mysql_schema (schema browsing).
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 provides clear context on when the tool can be used: read-only queries are always allowed, while write operations (INSERT, UPDATE, DELETE) are gated behind MYSQL_ALLOW_WRITES=true. It does not explicitly name alternative tools or exclusions, but it gives sufficient guidance for safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details beyond annotations: it searches recursively to a maximum depth of 10 levels, returns at most 100 results, and skips common directories (node_modules, vendor) and dotfiles. This gives the agent a clear picture of outcome limitations and filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that front-loads the core purpose and then immediately lists key constraints (recursive depth, result limit, exclusions). Every clause earns its place with no filler or repetition.
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 search tool with 3 parameters and no output schema, the description covers the essential behavior: what is searched, how deep, result cap, and exclusions. It does not explicitly state what the return value looks like (e.g., list of file paths), but given the tool's simplicity and the clarity of the operation, this is a minor gap. The description is sufficiently complete for an agent to select and invoke the tool confidently.
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 all three parameters (pattern, path, site). The description does not add additional parameter-level meaning beyond what the schema provides. It references 'name pattern' in the description, aligning with the pattern parameter, but no further semantics are added. Baseline 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 tool's function: searching for files by name pattern within the site directory. It specifies the resource ('files'), the action ('search'), and the scope ('Local site directory'), while also differentiating from sibling tools by noting recursive search, depth limit, and exclusions.
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 this tool (when you need to find files by name pattern) but does not explicitly mention alternatives or exclusions. For example, it does not say 'Use list_site_directory to browse files' or 'Use search_site_files when you need to locate a file by pattern.' The usage context is clear from the description but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds meaningful behavioral context by specifying the FS_ALLOW_WRITES environment requirement and the core directory restrictions, which are not fully captured by the annotations. No contradiction exists.
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 three short sentences that front-load the primary action and then compactly list requirements and restrictions. Every word earns its place, with no fluff or repetition.
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 write tool without an output schema, the description covers the key prerequisites (FS_ALLOW_WRITES), restrictions (wp-admin/ and wp-includes/), and path semantics. It doesn't mention overwrite behavior or error responses, but given the tool's simplicity and the annotation coverage, it is adequately complete.
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 all three parameters (path, site, content) fully described in the input schema. The description's note that path is relative to site root is redundant with the schema's path description, so it adds no additional 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 clearly states the tool writes content to a file in the Local by Flywheel site directory, using a specific verb and resource. It distinguishes itself from sibling tools like read_site_file by specifying the write operation and includes constraints on wp-admin/ and wp-includes/, which further clarifies its purpose.
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 provides clear context by requiring FS_ALLOW_WRITES=true and explicitly stating cannot-write-to conditions for wp-admin/ and wp-includes/. While it doesn't name alternative tools directly, the write-vs-read distinction relative to read_site_file and file-related siblings is implied through the tool's purpose and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the return content (names, domains, IDs, service versions), but does not disclose other behaviors like pagination or performance. This aligns with the calibration example where read-only tools with some added context score 3.
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, front-loaded sentence that is concise and informative. It includes all necessary details without redundancy or filler.
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?
For a simple zero-parameter list tool with no output schema, the description adequately covers what the tool does and what information it returns. No additional context is needed for an agent to select and invoke it correctly.
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 is 4. The description doesn't need to add parameter meaning; it focuses on the output, which is appropriate. No parameter information is missing.
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 'List', the resource 'WordPress sites configured in Local by Flywheel', and the included output fields (names, domains, IDs, service versions). It distinguishes itself from sibling tools like wp_site_info, which likely targets a single site.
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 gives clear context: it lists all sites, implying use when an overview of configured sites is needed. It does not explicitly mention when not to use or name alternatives, but the scope is obvious given the tool 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that arbitrary WP-CLI commands can be executed with constraints: writes require an environment variable and certain commands are blocked for security. This adds significant behavioral context beyond the generic annotations (readOnlyHint=false, destructiveHint=false). No contradiction is present.
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?
Three sentences, each carrying essential information: purpose, allowed commands, and write/security constraints. No wasted words and effectively front-loaded.
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?
Covers the key aspects of the tool: allowed commands, write gate, and blocked commands. With no output schema, a note about return value would improve completeness, but the description is adequate for a command runner with well-documented parameters.
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 already describes all 4 parameters (100% coverage), giving a baseline of 3. The description enriches parameter understanding by specifying allowed command examples and warning that format should not be used with write commands, adding 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 clearly states 'Execute a WP-CLI command against a Local by Flywheel WordPress site', specifying both the verb and resource. It also lists example commands and security restrictions, which distinguishes it from sibling tools like wp_list_sites or mysql_query.
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?
Provides clear context: read-only commands are always allowed, write commands require WPCLI_ALLOW_WRITES=true, and eval/eval-file/shell are blocked. However, it does not explicitly name alternative tools for the blocked cases, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable constraints beyond annotations: 512KB file size limit and path validation against the site directory, which inform potential failure modes. No contradictions.
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 two sentences: first states the purpose, second conveys constraints. Every word earns its place; no redundancy or fluff.
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?
For a simple read operation with full schema coverage and read-only annotations, the description covers all necessary behavioral aspects: path semantics, size cap, and validation. Siblings are clearly distinct, so 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?
Schema coverage is 100% and both parameters have descriptions. The description reinforces the relative path semantics with a concrete example ('app/public/wp-config.php') and adds practical constraints (size limit), providing value beyond the schema alone.
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 'read' with a clear resource ('a file from the Local by Flywheel site directory') and provides a concrete path example. This distinguishes it from sibling tools like write_site_file, list_site_directory, and search_site_files.
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 gives practical usage context: path is relative to site root, files limited to 512KB, and paths are validated. It does not explicitly name alternative tools, but the sibling names make the intended use obvious. Lacks explicit 'when not to use' guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![local-wp-mcp MCP server](https://glama.ai/mcp/servers/teamchrisfromthelc/local-wp-mcp/badges/card.svg)](https://glama.ai/mcp/servers/teamchrisfromthelc/local-wp-mcp)

Score Badge

Copy to your README.md:

[![local-wp-mcp MCP server](https://glama.ai/mcp/servers/teamchrisfromthelc/local-wp-mcp/badges/score.svg)](https://glama.ai/mcp/servers/teamchrisfromthelc/local-wp-mcp)

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/teamchrisfromthelc/local-wp-mcp'

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