Frontman for WordPress

wp_get_site_info

Read-onlyIdempotent

Returns site information including WordPress version, active theme, active plugins, public post types with archive URLs and rewrite settings, taxonomies, and SEO capabilities. CPT archives are generated routes, not backing pages/posts. Inspect seo_capabilities.targets and the advertised tools before selecting archive SEO tools. If the target is unsupported, use authorized admin forms instead; do not write arbitrary Yoast options. Set include_installation_paths to true only for a user-requested installation-location check. Paths describe the PHP runtime, not a unique site identity or necessarily the public document root.

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": {
      "site_id": "<site_id>"
    },
    "name": "wp_get_site_info"
  }
}

Input Schema

Name	Required	Description	Default
`site_id`	Yes	The connected site's id returned by list_sites. Call list_sites first; do not use a URL or WordPress post ID.
`include_installation_paths`	No	Include configured and resolved WordPress root paths. These private hosting details can enter model context and task history. Omitted by default.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well past the annotations (readOnly, idempotent, non-destructive, closed-world) by disclosing interpretation traps: CPT archives are generated routes rather than backing pages/posts, and returned paths describe the PHP runtime rather than a unique site identity or the public document root. It also warns that installation paths are private hosting details that can enter model context and task history, plus a prohibition on writing arbitrary Yoast options.

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?

Front-loads the payload list, then moves to SEO routing guidance and finally the optional-parameter caveat, so the most important information comes first. Five dense sentences with no filler, though the SEO and path-warning clauses sit close together and could be split for faster scanning.

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?

No output schema exists, so the description must characterize the return value, and it does by enumerating the returned sections plus the shape of post-type/archive data. Combined with the parameter caveat and the SEO follow-up routing, an agent has everything needed to call this correctly and interpret the result.

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

Parameters5/5

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

Schema coverage is already 100%, so the baseline is 3; the description earns more by adding a usage constraint the schema does not state ('only for a user-requested installation-location check') and a semantic caveat about what the paths mean. It also reinforces the site_id requirement indirectly through the list_sites prerequisite already carried 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?

Names a specific verb and resource ('Returns site information') and then enumerates the exact payload: WordPress version, active theme, active plugins, post types with archive URLs and rewrite settings, taxonomies, SEO capabilities. That enumeration distinguishes it from the sibling getters (wp_get_option, wp_get_custom_css, Elementor and WooCommerce getters), which each return a single narrower artifact.

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?

Gives concrete when-to-use branches around SEO work: inspect seo_capabilities.targets before selecting archive SEO tools, and fall back to authorized admin forms when the target is unsupported. It also gates include_installation_paths on a user-requested installation-location check. What it lacks is an explicit general statement of the task that should route an agent here rather than to wp_get_option for site-level facts.

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

All Frontman for WordPress tools Inspect

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.