Skip to main content
Glama
Sign In
MCP Hub

MCP Hub

by airano-ir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

WordPress: Probe upload limits

wordpress_probe_upload_limits
Read-only

Probe a WordPress site's effective upload limits (file size, post size, memory, input time, WP max upload) to diagnose upload failures before they occur.

Instructions

[UNIFIED] Probe a WordPress site for its effective upload limits (upload_max_filesize, post_max_size, memory_limit, max_input_time, wp_max_upload_size). Uses the airano-mcp-bridge companion plugin if present, else best-effort from the WP REST index. Cached 24 h per site.

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": "<site>"
    },
    "name": "wordpress_probe_upload_limits"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.13.1

TDQS

A3.5/5.0
Behavior4/5

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

The readOnlyHint annotation already establishes this is a safe read, and the description adds genuinely useful behavior: results may come from a companion plugin or degrade to a best-effort value from the REST index, and values are cached for 24 hours per site. What is not disclosed is behavior when neither source yields a value (error vs. partial/absent fields), which is the main residual uncertainty for a fallback-based tool.

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 dense sentences, front-loaded with the purpose and the enumerated limits, then the sourcing/fallback, then the caching note. The '[UNIFIED]' prefix is unexplained noise that does not help the agent decide or invoke, but the remainder has essentially no wasted words.

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 one-parameter read-only probe with no output schema, the description supplies the key facts: what is measured, how it is sourced, its reliability profile, and its staleness window. Only the 'site' identifier format and the failure-mode behavior are missing, which are meaningful but secondary gaps.

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

Parameters2/5

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

The single required parameter 'site' has 0% schema description coverage, so the description carries the full burden and does not meet it: nothing clarifies whether 'site' is a URL, a slug, a site ID, or a stored connection key. The mention of 'per site' caching implies it is an identifying key, but the accepted format remains a guess.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Probe') and resource ('a WordPress site for its effective upload limits') and enumerates the exact limits returned (upload_max_filesize, post_max_size, memory_limit, max_input_time, wp_max_upload_size), so the agent knows precisely what data comes back. It does not explicitly distinguish itself from the nearby wordpress_probe_capabilities tool, leaving that separation to the agent's inference.

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?

Usage is only implied: an agent must infer that this is the pre-flight check to run before choosing between direct upload, base64, or chunked upload paths. There is no explicit 'when to use' or 'when not to use' statement, and no sibling alternative is named for comparison, though the described pre-upload intent is reasonably evident.

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