Skip to main content
Glama
Sign In
mcp-wordpress

mcp-wordpress

by leonardobora
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

wp_get_block_pattern

Retrieve a registered WordPress block pattern by exact namespace/name, optionally including content. Ideal for reading pattern details without editing.

Instructions

Get one registered read-only pattern by its exact namespace/name.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "wp_get_block_pattern"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
include_contentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A3.8/5.0
Behavior4/5

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

Since no annotations are provided, the description carries the full burden and it explicitly labels the operation 'read-only', which signals no mutation. It does not cover not-found behavior or response shape, but for a simple getter the read-only disclosure provides the most important safety-relevant 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?

One short sentence with no filler and the essential scoping ('exact namespace/name') is front-loaded. Every word earns its place.

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

Completeness3/5

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

The core call intent is clear and the read-only nature is disclosed, but with no output schema and no annotations, the description still leaves include_content unexplained and gives no indication of behavior when the pattern does not exist. This is minimally adequate for a simple getter, not fully complete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It explains that the required 'name' parameter is an exact namespace/name, but it completely omits 'include_content', leaving one of two parameters undocumented. The semantics are therefore only partially conveyed.

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 states a specific verb ('Get'), a bounded resource ('one registered read-only pattern'), and the addressing scheme ('exact namespace/name'). This distinguishes it clearly from sibling listing and synced-pattern getter tools even without naming them.

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 phrase 'exact namespace/name' implies the tool is for callers who already know the precise identifier, but it never explicitly states when to prefer this over wp_get_synced_pattern or wp_list_block_patterns. No alternatives or exclusions are given, so usage context is only implied.

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

Deploy Server

Other Tools