BOIM WordPress Stack MCP

by JTruax

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting different WordPress development tasks (e.g., block generation, hooks, REST endpoints), but there is some overlap between 'format_for_wpcodebox' and 'format_wpcodebox_snippet' which could cause confusion as both handle WPCodebox formatting. The 'generate_gb_block' and 'generate_gutenberg_block' tools are clearly separated by targeting different block systems (GenerateBlocks vs core Gutenberg).
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with all tools using 'generate_', 'get_', 'format_', or 'validate_' prefixes followed by specific nouns (e.g., 'generate_block_pattern', 'get_gutenberg_standards'). There are no deviations in naming conventions, making the set predictable and easy to navigate.
Tool Count4/5
With 16 tools, the count is slightly high but reasonable for the WordPress development scope, covering multiple frameworks (Gutenberg, GenerateBlocks, WPCodebox) and code types (blocks, hooks, functions, endpoints). It might feel a bit heavy, but each tool appears to serve a specific niche in this specialized domain without obvious redundancy beyond the WPCodebox formatting overlap.
Completeness5/5
The toolset provides comprehensive coverage for WordPress development tasks, including code generation for blocks, hooks, functions, REST endpoints, and shortcodes, plus formatting/validation for WPCodebox and guides for best practices. There are no apparent gaps; agents can handle full workflows from creation to validation across supported frameworks.
Average 2.9/5 across 16 of 16 tools scored. Lowest: 2.2/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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates code, implying a creation operation, but does not specify whether this is a read-only or mutative action, what permissions might be required, or any side effects like file creation or API calls. The description is too vague to inform the agent about behavioral traits beyond the basic action.
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 that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, though it could benefit from more detail to improve clarity. The brevity is appropriate but borders on under-specification given the lack of additional context.
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 complexity of generating code templates and the absence of annotations and output schema, the description is insufficient. It does not explain what the generated output looks like (e.g., code format, structure), nor does it provide behavioral context or usage guidelines. For a tool with 3 parameters and no structured output information, more descriptive detail is needed to guide the agent effectively.
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% description coverage, clearly documenting parameters like 'name', 'description', and 'blocks' with their types and purposes. The description adds no additional semantic context beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate GenerateBlocks template code' is a tautology that essentially restates the tool name with minimal elaboration. It specifies the action ('Generate') and resource ('GenerateBlocks template code'), but lacks specificity about what a 'template' entails or how it differs from similar tools like 'generate_block_pattern' or 'generate_gb_block'. The purpose is clear at a basic level but fails to distinguish from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'generate_block_pattern', 'generate_gb_block', and 'generate_gutenberg_block', there is no indication of context, prerequisites, or exclusions. This leaves the agent without direction on selecting the appropriate tool for the task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states 'generate' which implies a creation/write operation, but doesn't specify what happens after generation (e.g., where the pattern is saved, if it requires specific permissions, or if it's idempotent). For a tool with no annotations and likely mutation behavior, this is a significant gap in transparency.
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 zero waste. It's appropriately sized for a tool with good schema coverage and gets straight to the point without unnecessary elaboration, making it easy to parse quickly.
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 complexity (a generation tool likely involving mutation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances. For a tool with 5 parameters and no structured safety hints, more context is needed to guide 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 description coverage is 100%, with all 5 parameters well-documented in the schema itself. The description adds no additional meaning about parameters beyond what's in the schema (e.g., no examples, format details, or constraints). Baseline 3 is appropriate when the schema does the heavy lifting, but the description doesn't compensate or enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate a Gutenberg block pattern' states the basic action (generate) and resource (Gutenberg block pattern), but it's vague about what this actually produces. It doesn't distinguish from sibling tools like 'generate_gutenberg_block' or 'generate_gb_template', leaving ambiguity about what specifically differentiates a 'block pattern' from other Gutenberg-related outputs.
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. With multiple sibling tools for Gutenberg/generation (e.g., generate_gutenberg_block, generate_gb_template, generate_block_variation), the description offers no context about appropriate use cases, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral information. It doesn't disclose whether this creates permanent changes, requires specific permissions, has rate limits, or what happens when a variation is generated. The description only states what the tool does, not how it behaves.
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 that states the core purpose without unnecessary words. It's appropriately sized for a tool with good schema documentation and gets straight to the point.
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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a Gutenberg block variation is, what the tool returns, or provide any context about the WordPress/Gutenberg ecosystem. Users need more information to understand what they're creating and what to expect.
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 4 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. This meets the baseline of 3 when schema coverage is high, but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool generates a Gutenberg block variation, which is a clear verb+resource combination. However, it doesn't differentiate from siblings like 'generate_gutenberg_block' or 'generate_gb_block' - these might create full blocks while this creates variations of existing blocks, but the description doesn't clarify this distinction.
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 provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to Gutenberg block generation (generate_gutenberg_block, generate_gb_block, generate_block_pattern), there's no indication of when this variation generator is appropriate versus creating a full block or pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action of generation without details on output format, error handling, permissions, or side effects. This is inadequate for a tool that likely produces code, requiring more context on its 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, efficient sentence with no wasted words. It is front-loaded and clear, making it easy to parse quickly, though it could benefit from more 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 no annotations, no output schema, and a tool that generates code (a complex operation), the description is incomplete. It lacks information on output format, error cases, or integration with GenerateBlocks, leaving significant gaps for an agent to use it effectively.
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 fully documents parameters like 'type' with enum values, 'attributes', and 'innerBlocks'. The description adds no additional meaning beyond the schema, such as examples or constraints, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool generates GenerateBlocks-compatible block code, which provides a general purpose. However, it lacks specificity about what 'compatible block code' entails (e.g., markup, JSON, or PHP) and does not clearly differentiate from sibling tools like 'generate_gutenberg_block' or 'generate_block_pattern', making it somewhat vague.
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. It does not mention prerequisites, context for use, or compare to siblings such as 'generate_gutenberg_block' or 'generate_block_variation', leaving the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates SCSS for compilation to CSS, implying a read-only or generation operation, but it doesn't cover critical aspects like whether it modifies existing files, requires specific permissions, handles errors, or has rate limits. For a tool with three parameters and no annotations, this is a significant gap in 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, efficient sentence that front-loads the core purpose ('Generate GenerateBlocks-specific SCSS') and adds a clarifying note ('compile to CSS for production'). There's no wasted text, making it appropriately concise for the tool's complexity.
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 three parameters, no annotations, and no output schema, the description is incomplete. It adequately explains the purpose but lacks usage guidelines, behavioral details (e.g., side effects, error handling), and output information. For a generation tool with multiple inputs, this leaves the agent with insufficient context to use it effectively.
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 parameters (blockType, selector, styles) with clear descriptions. The description adds no additional meaning beyond implying the styles parameter is formatted as SCSS, which is somewhat redundant with the schema's 'SCSS properties and values' note. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Generate') and target ('GenerateBlocks-specific SCSS'), specifying it's for compilation to CSS in production. It distinguishes from siblings like 'generate_gb_block' or 'generate_gutenberg_block' by focusing on SCSS generation rather than block or template creation. However, it doesn't explicitly differentiate from all siblings, such as 'format_for_wpcodebox', which might involve similar code generation.
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 mentions 'compile to CSS for production', implying a production context, but it doesn't specify prerequisites, exclusions, or direct comparisons to siblings like 'generate_gb_block' or 'generate_gutenberg_block'. This leaves the agent without clear decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates code but doesn't specify output format (e.g., PHP snippet, full file), whether it validates inputs, or any side effects like saving to a file. For a code-generation tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence: 'Generate WordPress action or filter hook code'. It's front-loaded with the core purpose, has zero waste, and is appropriately sized for a straightforward tool. Every word earns its place without 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?
Given the complexity of a code-generation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the generated output looks like (e.g., PHP code snippet), how to use it in WordPress, or any dependencies. This leaves users guessing about the tool's full context and utility.
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 6 parameters with descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting, but no extra value is provided.
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's purpose: 'Generate WordPress action or filter hook code'. It specifies the verb ('Generate') and resource ('WordPress action or filter hook code'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like generate_php_function or generate_shortcode, which also generate code for WordPress components.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for WordPress development, or how it differs from sibling tools such as generate_php_function or generate_shortcode. Without this, users must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'following coding standards' which hints at quality constraints, but doesn't disclose critical behavioral traits: whether this creates actual files or just returns code, what happens if inputs are invalid, if there are rate limits, authentication needs, or what the output format looks like. For a code generation tool with zero annotation coverage, this is inadequate.
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 zero wasted words. It's front-loaded with the core purpose and includes the key constraint about coding standards. Every word earns its place without redundancy or unnecessary elaboration.
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 code generation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (raw code, formatted output, file creation?), doesn't cover error conditions or validation rules, and provides minimal behavioral context. The 'coding standards' hint is insufficient for the tool's complexity.
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 6 parameters thoroughly. The description adds no additional meaning about parameters beyond implying they relate to PHP function generation. With high schema coverage, baseline 3 is appropriate as the description doesn't enhance parameter understanding beyond what the schema provides.
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 'Generate' and the resource 'WordPress PHP function', specifying it follows 'coding standards'. It distinguishes from some siblings like 'generate_hook' or 'generate_shortcode' by focusing on PHP functions, but doesn't explicitly differentiate from all code-generation siblings like 'generate_gutenberg_block'.
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. With many sibling tools for generating various WordPress code elements (blocks, hooks, endpoints, etc.), the description lacks any context about appropriate use cases, prerequisites, or comparisons to similar tools like 'generate_hook' or 'generate_rest_endpoint'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral information. It states what the tool does but doesn't disclose whether this generates code, modifies files, requires specific permissions, has side effects, or what format the output takes. For a code generation tool with zero annotation coverage, this is inadequate.
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 that states the core purpose without unnecessary words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point.
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 code generation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what gets generated (code snippet, file, configuration), where it goes, or what the agent should expect as a result. The schema handles parameter documentation well, but the overall context is incomplete.
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 6 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify usage patterns. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose as generating a WordPress REST API endpoint, specifying both the action (generate) and resource (endpoint). It distinguishes from most siblings focused on code generation for WordPress, but doesn't explicitly differentiate from other REST-related tools since none exist in the sibling list.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare with sibling tools like generate_php_function or generate_hook that might serve similar purposes in WordPress development.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool generates a shortcode implementation but doesn't disclose behavioral traits like whether it outputs code, modifies files, requires authentication, handles errors, or has rate limits. This leaves significant gaps for an agent to understand how to invoke it effectively.
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. It's front-loaded and directly states the tool's purpose, making it easy for an agent to parse quickly.
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 complexity of a code-generation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., code snippet, file), potential side effects, or error handling, leaving the agent with insufficient context for reliable 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 description coverage is 100%, so the input schema fully documents the parameters (tag, description, attributes, body). The description adds no additional meaning beyond the schema, such as examples or constraints, which is acceptable given the high coverage, resulting in a baseline score of 3.
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's purpose as 'Generate WordPress shortcode implementation,' which specifies the action (generate) and resource (WordPress shortcode). It distinguishes from most siblings that focus on blocks, hooks, or validation, though it doesn't explicitly differentiate from format_for_wpcodebox or format_wpcodebox_snippet, which are related but not identical.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as when to choose this over generate_gutenberg_block or other code-generation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the tool validates structure, but doesn't disclose what validation entails (e.g., syntax checks, scope compatibility, error handling), whether it's read-only or has side effects, or what happens on failure. This is inadequate for a tool with 5 parameters and no output schema.
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 that front-loads the core purpose ('validate a snippet structure') without unnecessary words. It earns its place by specifying the target ('against WPCodebox requirements'), making it appropriately sized and structured.
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's complexity (5 parameters, validation logic) and lack of annotations and output schema, the description is incomplete. It doesn't explain what validation checks are performed, what the return value indicates (e.g., success/failure, error details), or behavioral traits. This leaves significant gaps for an AI agent to understand tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional meaning beyond implying validation involves these parameters. This meets the baseline of 3, as the schema handles the heavy lifting without needing extra detail in the description.
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 'validate' and the resource 'snippet structure', specifying it's against 'WPCodebox requirements'. It distinguishes from siblings like 'format_wpcodebox_snippet' by focusing on validation rather than formatting. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_wpcodebox_guidelines'), keeping it at 4 instead of 5.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when validation is needed (e.g., before saving or deploying snippets) or refer to sibling tools like 'format_wpcodebox_snippet' for complementary actions. This lack of context leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does ('format'), but doesn't explain what formatting entails, whether it validates input, what the output looks like, or any error conditions. For a tool with 5 parameters and no annotations, this is insufficient behavioral context.
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 that gets straight to the point. It wastes no words and communicates the core function immediately. This is an excellent example of conciseness with appropriate structure.
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?
Given 5 parameters, no annotations, and no output schema, the description is minimally adequate but has clear gaps. It states what the tool does but doesn't explain the formatting process, output format, or behavioral characteristics. For a formatting tool with multiple parameters, more context about what the formatting entails 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?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
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's purpose: 'Format any generated code for WPCodebox snippet structure.' It specifies the verb ('format') and resource ('generated code'), and indicates the target format ('WPCodebox snippet structure'). However, it doesn't explicitly differentiate from its closest sibling 'format_wpcodebox_snippet' or other formatting/generation tools in the list.
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 provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'format_wpcodebox_snippet', 'generate_php_function', and 'validate_wpcodebox_snippet', there's no indication of when this specific formatting tool is appropriate versus when to use other generation or validation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions formatting with 'proper structure and metadata,' which implies a transformation or creation process, but doesn't disclose behavioral traits like whether this creates a new snippet, modifies existing ones, requires specific permissions, or has side effects. For a tool with no annotations, this leaves significant gaps.
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 that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for its 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?
Given no annotations and no output schema, the description is minimal but covers the basic purpose. For a tool with 7 parameters and no structured behavioral hints, it should do more to explain usage context and outcomes, but it's adequate as a starting point.
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 fully documents all 7 parameters. The description adds no additional meaning beyond implying formatting involves these parameters, but doesn't explain their interactions or provide context beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Format a code snippet') and target ('for WPCodebox plugin'), with specific details about structure and metadata. However, it doesn't explicitly differentiate from sibling tools like 'format_for_wpcodebox' or 'validate_wpcodebox_snippet', which appear related.
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 doesn't mention when to choose this over sibling tools like 'format_for_wpcodebox' or 'validate_wpcodebox_snippet', nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates code but doesn't clarify whether this is a read-only operation, if it requires specific permissions, what the output format looks like (e.g., file structure, code snippets), or any potential side effects like file creation. For a code generation tool with zero annotation coverage, 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, efficient sentence that front-loads the key action and output details without unnecessary words. It directly states what the tool does ('Generate complete Gutenberg block code') and specifies the components included, making it easy to parse quickly.
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?
Given the tool's complexity (generating multiple code components) and lack of annotations or output schema, the description is somewhat incomplete. It mentions the output includes 'block.json, PHP registration, and React components' but doesn't detail the behavior, format, or any constraints. However, the high schema coverage for parameters provides some compensation, making it minimally adequate but with clear gaps.
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 description coverage is 100%, with all 6 parameters clearly documented in the input schema (e.g., name, title, category). The description doesn't add any additional meaning or context beyond what the schema provides, such as explaining how parameters influence the generated code. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate complete Gutenberg block code including block.json, PHP registration, and React components.' It specifies the verb 'generate' and the resource 'Gutenberg block code' with details about the output components. However, it doesn't explicitly differentiate from sibling tools like 'generate_gb_block' or 'generate_block_pattern', which might have overlapping functionality.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'generate_gb_block' or 'generate_block_pattern', leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('Get... guide and best practices'), without revealing any behavioral traits such as whether it's a read-only operation, if it requires authentication, rate limits, or what the output format might be. This is a significant gap for a tool with zero 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, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple tool with no parameters, making it highly concise and well-structured.
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's simplicity (0 parameters, no output schema, no annotations), the description is minimal but adequate for basic understanding. However, it lacks completeness in terms of behavioral context (e.g., output format, any side effects) and usage guidelines, which are important even for simple tools to ensure correct agent invocation.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids mentioning any. A baseline score of 4 is assigned as it handles the lack of parameters correctly without introducing confusion.
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 the resource 'GenerateBlocks development guide and best practices', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_gutenberg_standards' or 'get_wpcodebox_guidelines', which also retrieve documentation/guidelines, so it misses full sibling distinction.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves standards but doesn't describe the return format, potential limitations, or any behavioral traits like rate limits or authentication needs. This leaves the agent with incomplete information about how the tool behaves.
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, clear sentence that efficiently conveys the tool's purpose without any wasted words. It's front-loaded with the essential information, making it highly concise and well-structured.
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 annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., text, structured data, or a reference), which is critical for a retrieval tool. This gap reduces its usefulness for an agent in understanding the full context.
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 schema description coverage is 100%, so there's no need for parameter details in the description. The description appropriately focuses on the tool's purpose without redundant parameter information, earning a high baseline score.
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's purpose with a specific verb ('Get') and resource ('Gutenberg block development standards and best practices'), making it immediately understandable. It doesn't explicitly distinguish from sibling tools, but since siblings are mostly about generating or formatting code rather than retrieving standards, the distinction is somewhat inherent.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or exclusions, leaving the agent to infer usage based on the purpose alone. This is a significant gap for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves guidelines and best practices, implying a read-only operation, but doesn't specify whether it returns structured data, text, or other formats, or if there are any limitations like rate constraints or authentication requirements. This leaves significant gaps for a tool with zero 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, efficient sentence that directly states the tool's function without any wasted words. It's front-loaded with the core action and resource, making it easy to parse and understand quickly.
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?
Given the tool has no parameters and no output schema, the description adequately covers the basic purpose. However, without annotations or details on return format, it lacks completeness for guiding an agent on what to expect from the output, which could be important for a tool that provides guidelines and best practices.
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 has 100% description coverage (though empty). The description doesn't need to add parameter details, as there are none to explain. It appropriately focuses on the tool's purpose without redundant information, meeting the baseline for a parameterless tool.
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's purpose with a specific verb ('Get') and resource ('WPCodebox usage guidelines and best practices'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_generateblocks_guide' or 'get_gutenberg_standards', which appear to serve similar informational purposes but for different topics.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, nor does it reference sibling tools that might be relevant for related information needs, leaving the agent to infer usage based on tool names alone.
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:

[![BOIM-WP-MCP MCP server](https://glama.ai/mcp/servers/JTruax/BOIM-WP-MCP/badges/card.svg)](https://glama.ai/mcp/servers/JTruax/BOIM-WP-MCP)

Score Badge

Copy to your README.md:

[![BOIM-WP-MCP MCP server](https://glama.ai/mcp/servers/JTruax/BOIM-WP-MCP/badges/score.svg)](https://glama.ai/mcp/servers/JTruax/BOIM-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/JTruax/BOIM-WP-MCP'

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