Skip to main content
Glama

Set SEO metadata

set_seo_meta
Destructive

Preview and apply SEO metadata for WordPress content: set title, meta description, focus keyword, canonical URL, and robots noindex/nofollow with a confirm step before writing.

Instructions

Set the SEO title, meta description, focus keyword, canonical URL and robots noindex/nofollow for one content item, written the way the active SEO plugin expects: its own REST route where one exists (Rank Math updateMeta, AIOSEO, SEOPress), otherwise its post meta keys via core REST (when registered) or the companion plugin's meta route. Always previews first: the initial call shows before → after and returns a confirm_token; re-run with the token to write. Refuses when no SEO plugin is active, because WordPress core would ignore the values.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesContent ID to update.
typeNoContent type of the id. Omit to search post, page and then other types.
titleNoSEO title. Plugin template variables (%%title%% for Yoast, %title% for Rank Math) are passed through. Empty string clears the override.
pluginNoForce the target plugin when detection misses it. Writing a plugin's keys while that plugin is inactive has no visible effect.
noindexNotrue asks search engines not to index this item; false explicitly allows indexing.
site_idNoWhich configured WordPress site to act on. Optional — with a single site configured it is used automatically; with several, the default site is used unless you name one. Run list_sites for valid ids.
nofollowNotrue asks search engines not to follow links on this item.
canonicalNoAbsolute canonical URL. Empty string clears the override so the plugin's default applies.
descriptionNoMeta description; ~140–160 characters reads best in results. Empty string clears the override.
confirm_tokenNoToken from the preview call. Omit to preview; pass it back unchanged with identical arguments to apply.
focus_keywordNoFocus keyphrase used by the plugin's content analysis. Not supported by The SEO Framework.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses a two-step write flow: the initial call returns a confirm_token and only a re-run with that token writes. It also details plugin-specific routing and the no-plugin refusal, adding significant behavioral context that annotations do not convey.

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, front-loaded with the action and field list, then the two-step mechanism and refusal condition. Every sentence carries unique information and the length is justified by the tool's complexity.

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?

The description covers the multi-plugin routing, mandatory preview/confirm sequence, and no-plugin failure mode, which are the non-obvious requirements. It does not describe the return payload of the write call, but given the preview behavior is stated and there is no output schema, this is a minor 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?

Schema coverage is 100% and the parameter descriptions already explain empty-string clearing, plugin template variables, and the confirm_token contract. The description echoes the field list but adds no per-parameter meaning beyond what the schema provides, so 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 opens with a specific verb and resource: 'Set the SEO title, meta description, focus keyword, canonical URL and robots noindex/nofollow for one content item.' It explicitly enumerates the fields and the plugin-aware routing distinguishes it from generic setters like set_content_meta.

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 preview-then-confirm workflow and the refusal condition when no plugin is active are clearly explained, which tells the agent how and when not to call it. However, it never names sibling alternatives such as set_content_meta or update_content, so guidance on choosing this tool over alternatives 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