Skip to main content
Glama
Sign In

Royally

by io.royally
OverviewDiscussionsAdmin

mcp-wordpress-com__describe

Read-only

Explains the inputs, effects, and results of one to five exact abilities discovered through search, such as creating a website, publishing a post, changing a theme, or inspecting site statistics. Returns each ability's complete description, input schema with required and optional fields, instructions, annotations, and approval requirements; declared output schemas are optional. Results follow request order and share one target site. Remote: contracts come from that site. This reads contracts without running the abilities. An unavailable name fails the entire request. Through Royally: its server marks it read-only, so it runs straight away.

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": {
      "names": "<names>"
    },
    "name": "mcp-wordpress-com__describe"
  }
}

Input Schema

NameRequiredDescriptionDefault
namesYesOne to five unique name values returned by search, including the full namespace, for example "wpcom-mcp/site-create-from-spec" or "wpcom/user-sites". These are ability names, not labels or search terms. Names beginning with "remote:" require the wpcom_site where they were discovered. All names in this request share that site context.
site_idNoSite to run this tool on: 1484d0f5-e153-4114-b09b-6d03462b465a (https://public-api.wordpress.com/wpcom/v2/mcp/v1)
wpcom_siteNoExisting target site: a site ID encoded as a string, a domain, or a full site URL. Site IDs and URLs are returned by wpcom/user-sites. Sets the site context for discovery or execution and is required for remote: abilities. Without a site, discovery covers only WordPress.com-defined abilities; account operations and creation of a new website need no existing site. Any site selector also present in the ability input must identify the same site.
include_output_schemaNoAdds the declared output_schema for each ability, describing its result fields and types. False (the default) still includes the full input schema and approval requirements.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, it discloses the returned payload (descriptions, input schema, instructions, annotations, approval requirements), optional output schemas, result ordering, shared site context, remote contract source, and the all-or-nothing failure mode for unavailable names. This is substantial behavioral information beyond readOnlyHint and related annotations.

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 front-loaded with the core purpose and then layers on output contents and constraints. It is mostly efficient, though some phrasing is dense and the Royally-specific sentence is less broadly useful than the rest.

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 describe tool with four parameters and no output schema, the description covers purpose, return contents, site scoping, remote behavior, failure semantics, and the fact that it does not execute abilities. Nothing essential is missing for an agent to call 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%, so parameter meaning is already well supplied by the input schema. The description adds only minor clarifications such as one-to-five scope and shared site context, while most parameter details such as exact names, maxItems, and include_output_schema are already documented in 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 gives a specific verb and resource: it explains the inputs, effects, and results of named abilities. It clearly distinguishes from execution by stating that it reads contracts without running the abilities, which lets an agent separate it from execute-style siblings.

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?

It states that abilities are discovered through search and that this tool inspects them rather than running them, which establishes a clear prerequisite and use context. It does not explicitly name or exclude the closest sibling alternatives such as docs or execute, so it stops short of fully explicit routing guidance.

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

All Royally toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources