Skip to main content
Glama
ArsNovaSingers

ars-nova-wordpress-mcp

Official

Upload File to WordPress Media Library

wp_upload_media

Upload a local file to the WordPress media library as a new attachment, returning the created media item with metadata.

Instructions

Upload a local file to the WP media library as a new attachment. Reads the file from file_path on the MCP host machine, sends as multipart/form-data, and returns the created media item.

Args:

  • file_path (string): Absolute path to the file on disk. Required.

  • title (string): Optional title (defaults to filename).

  • alt_text (string): Optional alt text.

  • caption (string): Optional caption.

  • description (string): Optional description.

  • post (number): Optional post/page ID to attach the media to (0 = unattached).

  • response_format (enum): markdown | json. Default 'markdown'.

Returns: The newly-created WPMediaItem with id, source_url, dimensions, etc.

Notes:

  • The MCP host process must have read access to file_path.

  • For best SEO, always pass alt_text on image uploads.

  • WP MIME-sniffs the file; the upload will be rejected if the extension is on WP's disallowed list (e.g. executables).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
postNoAttach this media to a specific post/page ID. 0 (default) = unattached.
titleNoTitle for the media item. Defaults to the filename minus extension.
captionNoCaption shown beneath the image in some themes.
alt_textNoAlt text for accessibility. Strongly recommended for images.
file_pathYesAbsolute path to a local file to upload. Must be readable by the MCP process. (For files in your workspace folder, use the full Windows path.)
descriptionNoLonger description (rendered on the attachment page).
response_formatNoOutput format: 'markdown' for human-readable, 'json' for machine-readable.markdown
Behavior4/5

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

The description discloses that the file is read from the MCP host machine, sent as multipart/form-data, and that WordPress MIME-sniffs the file. It also notes the host must have read access and recommends alt_text for SEO. These go beyond the annotation flags (readOnlyHint=false, destructiveHint=false) and provide useful operational context.

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 well-structured with a clear opening sentence, an Args section, a Returns section, and useful Notes. Every sentence adds value: the opening states the action, the Args list is compact, and the Notes cover access, SEO, and MIME rejection—all without fluff.

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?

Although there is no output schema, the description specifies the return type (WPMediaItem with id, source_url, dimensions) and covers potential rejection due to MIME restrictions. Combined with 100% parameter schema coverage and practical notes on permissions and alt text, the description gives an agent a complete understanding of what the tool does and what to expect.

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 the schema already documents all seven parameters. The description largely repeats the parameter list and defaults (title defaults to filename, post 0 = unattached), which are also in the schema. It adds minimal new semantic detail beyond what the schema provides, so the 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 uses a specific verb ('Upload'), identifies the resource ('WP media library'), and clarifies it creates a new attachment. This distinguishes it clearly from sibling tools like wp_update_media, wp_delete_media, and wp_list_media.

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?

The description clearly implies when to use this tool: to upload a local file as a new media item. It does not explicitly name alternatives or provide exclusion criteria, but the notes give practical context (file access, MIME restrictions, alt-text recommendation) that helps an agent decide. No explicit 'when not to use' is present, but the context is unambiguous.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ArsNovaSingers/ars-nova-wordpress-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server