wpxmcp

Find (and optionally update) content by URL

find_content_by_url

Turn any WordPress front-end URL into the content behind it, detect its post type, and optionally update it in one call.

Instructions

Resolve any WordPress front-end URL to the content behind it, detecting the post type from the URL shape (so /documentation/getting-started/ finds the documentation custom post type), then optionally update it in the same call. This is the tool to reach for when a human hands you a link. Detection tries, in order: an explicit ?p= id, the site's own search index, the registered rewrite base, then a slug sweep across every type.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Any URL on the site — permalink, ?p=123, or a pretty CPT URL.
`date`	No	Publish date in site time, ISO 8601 (2026-01-31T09:00:00). With status "future" (or "publish" and a future date) this schedules the post.
`meta`	No	Custom fields, as key/value pairs. A key only writes if it is registered with show_in_rest — use set_content_meta for unregistered keys.
`slug`	No	URL slug. Changing this on published content breaks existing links unless you add a redirect.
`edits`	No	Targeted find/replace edits applied to the existing raw content, so you can change one paragraph without resending the whole document. Edits apply in order. Mutually exclusive with `content`.
`terms`	No	Taxonomy assignments keyed by taxonomy slug or REST base, e.g. {"categories": [3], "tags": ["news"]}. Replaces the item's terms in each taxonomy given. Names that do not exist yet are created.
`title`	No	The title, as plain text.
`author`	No	User ID of the author.
`format`	No	Post format. Only applies to types that support post formats.
`parent`	No	Parent ID, for hierarchical types such as pages. 0 for none.
`status`	No	publish \| future \| draft \| pending \| private \| trash. "future" needs a `date` in the future. "trash" moves the item to the trash (same as delete_content without force).
`sticky`	No	Pin the post to the top of the blog. Posts only.
`update`	No	Apply the supplied changes once the content is found. Off by default, so this tool is safe to use purely for lookup.
`content`	No	Full content body, replacing whatever is there. For the block editor this is block markup (<!-- wp:paragraph --><p>…</p><!-- /wp:paragraph -->); classic content is plain HTML. Use `edits` instead for a small change.
`excerpt`	No	Hand-written excerpt.
`site_id`	No	Which 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.
`password`	No	Password-protect the content. Empty string removes the password.
`template`	No	Page template file, e.g. "templates/full-width.php". Empty string for the default template.
`menu_order`	No	Sort order for hierarchical types.
`ping_status`	No	Whether pingbacks and trackbacks are accepted.
`comment_status`	No	Whether comments are open on this item.
`featured_media`	No	Attachment ID of the featured image, or 0 to remove it. Upload it with create_media first.
`include_content`	No	Return the full body along with the match.

Schema Changelog

Changes observed during successful MCP inspections.

Changed23 schema fields changedv2.0.0Sep 15, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```
addedInput schema / properties / author / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / author / minimum
```
Added value: +-9007199254740991
```

changedInput schema / properties / date / description

Previous value: -"Publish date in site time, ISO 8601 (2026-01-31T09:00:00). With status \"future\" this schedules the post."New value: +"Publish date in site time, ISO 8601 (2026-01-31T09:00:00). With status \"future\" (or \"publish\" and a future date) this schedules the post."

changedInput schema / properties / edits / description

Previous value: -"Targeted find/replace edits applied to the existing content, so you can change one paragraph without resending the whole document. Edits apply in order. Mutually exclusive with `content`."New value: +"Targeted find/replace edits applied to the existing raw content, so you can change one paragraph without resending the whole document. Edits apply in order. Mutually exclusive with `content`."

removedInput schema / properties / edits / items / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / featured_media / description

Previous value: -"Attachment ID of the featured image. Upload it with create_media first."New value: +"Attachment ID of the featured image, or 0 to remove it. Upload it with create_media first."

addedInput schema / properties / featured_media / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / featured_media / minimum
```
Added value: +0
```

changedInput schema / properties / format / description

Previous value: -"Post format: standard, aside, gallery, link, image, quote, status, video, audio, chat."New value: +"Post format. Only applies to types that support post formats."

addedInput schema / properties / format / enum

Added value: +[
+  "standard",
+  "aside",
+  "chat",
+  "gallery",
+  "link",
+  "image",
+  "quote",
+  "status",
+  "video",
+  "audio"
+]

addedInput schema / properties / menu_order / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / menu_order / minimum
```
Added value: +-9007199254740991
```
addedInput schema / properties / meta / propertyNames
```
Added value: +{
+  "type": "string"
+}
```

changedInput schema / properties / parent / description

Previous value: -"Parent ID, for hierarchical types such as pages."New value: +"Parent ID, for hierarchical types such as pages. 0 for none."

addedInput schema / properties / parent / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / parent / minimum
```
Added value: +0
```

changedInput schema / properties / password / description

Previous value: -"Password-protect the content."New value: +"Password-protect the content. Empty string removes the password."

changedInput schema / properties / status / description

Previous value: -"publish | future | draft | pending | private | trash."New value: +"publish | future | draft | pending | private | trash. \"future\" needs a `date` in the future. \"trash\" moves the item to the trash (same as delete_content without force)."

changedInput schema / properties / template / description

Previous value: -"Page template file, e.g. \"templates/full-width.php\"."New value: +"Page template file, e.g. \"templates/full-width.php\". Empty string for the default template."

changedInput schema / properties / terms / description

Previous value: -"Taxonomy assignments keyed by taxonomy REST base, e.g. {\"categories\": [3], \"tags\": [\"news\"]}. Names that do not exist yet are created."New value: +"Taxonomy assignments keyed by taxonomy slug or REST base, e.g. {\"categories\": [3], \"tags\": [\"news\"]}. Replaces the item's terms in each taxonomy given. Names that do not exist yet are created."

addedInput schema / properties / terms / propertyNames
```
Added value: +{
+  "type": "string"
+}
```

First observedv1.0.0Aug 24, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already flag readOnlyHint:false and openWorldHint:true, but the description adds significant behavioral context: it can optionally mutate in the same call, update is off by default making it safe for pure lookup, and it discloses the detection order (explicit ?p=, search index, rewrite base, slug sweep). This goes well beyond what the annotations convey and helps the agent predict side effects.

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 compact, front-loads the core purpose and usage trigger, and every sentence contributes: purpose, example, when-to-use, and detection order. No filler or repetition of schema contents.

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?

For a complex tool with 23 parameters and nested objects, the description provides the necessary mental model — URL resolution, optional update behavior, and the update flag's safety default. It doesn't describe return values or failure modes, but with no output schema and rich parameter docs, what's missing is minor.

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 each of the 23 parameters is already documented in the schema; the description adds no parameter-level detail beyond the url resolution logic and the update flag's default-off behavior. This matches the baseline of 3 where the schema carries the heavy lifting.

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 ('Resolve any WordPress front-end URL to the content behind it') and a clear resource, and distinguishes itself from siblings by the URL-resolution mechanism and optional update capability. The example with /documentation/getting-started/ and the explicit 'This is the tool to reach for when a human hands you a link' makes its purpose unmistakable and differentiates it from slug-based tools like get_content_by_slug.

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 gives a clear when-to-use signal ('when a human hands you a link') and explains the detection order, which helps agents understand what kinds of URLs are valid inputs. However, it stops short of explicitly naming alternatives or stating when not to use it (e.g., 'if you already have a slug, use get_content_by_slug instead'), so it lacks full exclusion guidance.

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

Deploy Server

Find (and optionally update) content by URL

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools