Skip to main content
Glama
Sign In
Official Porkbun MCP Server

Official Porkbun MCP Server

by oborseth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Wordpress Upload Media

wordpress_upload_media

Upload an image or file to a Cloud for WordPress site's media library from a public URL or base64 data, returning the attachment ID and URL for use as featured media or in page content.

Instructions

Add an image (or other file) to a Cloud for WordPress site's media library, from a public URL (WordPress downloads it) or from base64 data with a filename. Returns the attachment id (use as featured_media on a post or page via wordpress_request) and its url (use in page content). Set alt_text to describe the image for accessibility. Up to about 10 MB.

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": {
      "domain": "<domain>"
    },
    "name": "wordpress_upload_media"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoPublic https:// address of the file. Use this or data.
dataNoThe file as base64 (a data: URL works). Use this or url.
titleNoMedia title.
domainYesThe domain of the Cloud for WordPress site.
captionNoCaption.
post_idNoAttach it to this post or page id.
alt_textNoAlt text describing the image.
filenameNoFile name with extension, e.g. `storefront.jpg`. Required with data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.62.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-destructive, non-idempotent, open-world behavior; the description adds genuinely new facts on top: the ~10 MB ceiling, that WordPress itself fetches the remote URL, and the shape of the return payload. It does not mention auth/permission requirements or whether re-uploading the same file duplicates the attachment, which is the main remaining behavioral gap for a non-idempotent write.

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 tight sentences: action and location first, input modes second, return values and their use third, with the size limit as a closing constraint. Every sentence carries information an agent needs; nothing is restated from the title.

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?

For an eight-parameter write tool with no output schema, the description covers the input alternatives, the size constraint, the return values, and how those values feed into wordpress_request. Nothing essential to a correct first call is missing.

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 adds cross-parameter meaning beyond the schema: the url/data mutual exclusivity paired with the filename requirement, the accessibility rationale for alt_text, and the downstream semantics of the returned id. It leaves post_id, title, and caption to the schema alone, which is acceptable.

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?

States a specific verb and resource ('Add an image (or other file) to a Cloud for WordPress site's media library') and names the two input modes (public URL vs base64 data). It also distinguishes itself from the downstream sibling by naming wordpress_request as the consumer of the returned id, so an agent can place it in a workflow without opening the schema.

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?

Clear guidance on which input path to take (public https URL, where WordPress performs the download, or base64 data that requires a filename) and what to do with the result (id as featured_media via wordpress_request, url in page content). It stops short of explicit when-not-to-use cases, e.g. no guidance on what to do if a media item already exists or how to handle files over the size limit.

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