Frontman for WordPress

wp_upload_media

Destructive

Uploads a user-attached media asset into the WordPress Media Library. For chat image attachments, pass image_ref from the Available Image Attachments list; the browser resolves it before WordPress receives the request. Returns an attachment_id and URL for Elementor image widgets, post content, featured images, or custom HTML/CSS.

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_upload_media"
  }
}

Input Schema

Name	Required	Description
`title`	No	Attachment title.
`caption`	No	Attachment caption.
`content`	No	Base64-encoded file content. Usually filled automatically from image_ref by the browser client.
`post_id`	No	Optional post/page ID to attach the media to.
`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.
`alt_text`	No	Image alt text saved as attachment metadata.
`encoding`	No	Content encoding. Must be base64 when content is provided.
`filename`	No	File name to use in the Media Library. If omitted, it is inferred from image_ref when possible.
`image_ref`	No	URI of a user-attached image, for example attachment://att_abc/photo.png. Prefer this when the user attached the asset in chat.
`mime_type`	No	Media MIME type. Usually filled automatically from image_ref.
`description`	No	Attachment description.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4/5.0

Behavior3/5

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

Given destructiveHint=true and openWorldHint=true are already declared, the description does useful work explaining that 'the browser resolves it before WordPress receives the request' and that an attachment_id plus URL come back. But it never explains what the destructive hint covers, e.g. whether re-uploading with an existing filename overwrites prior media, nor any size or type limits. For a write tool flagged destructive, that omission is material.

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?

Three sentences, front-loaded with the action and followed by the attachment workflow and the return value. The trailing list of consumer contexts ('Elementor image widgets, post content, featured images, or custom HTML/CSS') is slightly padded but still serves a routing purpose.

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?

For an 11-parameter mutation tool with no output schema, the description reasonably covers the return values and the image_ref path. However, it leaves unaddressed the safety profile implied by destructiveHint=true and idempotentHint=false, meaning an agent cannot tell whether a repeat upload duplicates or replaces media.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by clarifying the runtime relationship between image_ref and content: the browser resolves the ref before the request reaches WordPress. That workflow detail is not stated in the schema and prevents an agent from hand-encoding base64 unnecessarily.

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 destination resource: 'Uploads a user-attached media asset into the WordPress Media Library.' No sibling tool in the supplied list uploads media, so ambiguity is low even without naming an alternative.

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 concrete routing rule for the main ambiguity in this domain: 'For chat image attachments, pass image_ref from the Available Image Attachments list.' It also states downstream uses (Elementor image widgets, post content, featured images), which frames when to call it. It stops short of explicit exclusions, such as when to prefer an existing attachment over re-uploading.

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.