Skip to main content
Glama

wp_update_radar_check_many

Read-onlyIdempotent

Answers: which of this site's plugin updates are risky right now? Prefer this over the single check whenever there is more than one plugin to look at — a whole site's plugin list costs one call here instead of one call each. Same five verdicts as the single check (known-bad, wait, update-now, too-new, insufficient-data), per item and independent: a plugin that is not indexed reports its own error and the rest still answer. Returns a count of each verdict, so the risky ones can be found without reading every row. Up to 25 plugins per call; more than that is reported, not silently cut. insufficient-data means this service does not know, which is not the same as safe. Not a security advisory and not a CVE lookup: it reports what other site owners are saying, which is a different question from whether a release is vulnerable. wordpress.org plugins only — premium plugins have no public forum to read, and themes are out of scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pluginsYesThe plugins and the exact versions in use

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countsYesverdict -> count, plus `error` for items that could not be judged
resultsYes
skippedYes
examinedYeshow many were actually judged, after the per-call cap
requestedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • addedOutput schema / properties / results / items / properties / attribution
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "how many threads were tied to this release and to its baseline, by the same function",
      +  "properties": {
      +    "baseline": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "attributed": {
      +          "type": "integer"
      +        },
      +        "explicit": {
      +          "type": "integer"
      +        },
      +        "mean": {
      +          "type": "number"
      +        },
      +        "releases": {
      +          "type": "integer"
      +        },
      +        "window": {
      +          "type": "integer"
      +        }
      +      },
      +      "required": [
      +        "releases",
      +        "explicit",
      +        "window",
      +        "attributed",
      +        "mean"
      +      ],
      +      "type": "object"
      +    },
      +    "current": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "attributed": {
      +          "type": "integer"
      +        },
      +        "explicit": {
      +          "type": "integer"
      +        },
      +        "window": {
      +          "type": "integer"
      +        }
      +      },
      +      "required": [
      +        "explicit",
      +        "window",
      +        "attributed"
      +      ],
      +      "type": "object"
      +    },
      +    "sameFunction": {
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "current",
      +    "baseline",
      +    "sameFunction"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / results / items / properties / coverage
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "how much of this plugin's forum could be attributed at all",
      +  "properties": {
      +    "ambiguous": {
      +      "type": "integer"
      +    },
      +    "attributedRate": {
      +      "type": "number"
      +    },
      +    "directMappingRate": {
      +      "type": "number"
      +    },
      +    "explicit": {
      +      "type": "integer"
      +    },
      +    "postTimeUnknown": {
      +      "type": "integer"
      +    },
      +    "threadsTotal": {
      +      "type": "integer"
      +    },
      +    "unattributed": {
      +      "type": "integer"
      +    },
      +    "window": {
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "threadsTotal",
      +    "explicit",
      +    "window",
      +    "unattributed",
      +    "ambiguous",
      +    "directMappingRate",
      +    "attributedRate",
      +    "postTimeUnknown"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / results / items / properties / freshness
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "ageHours": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "lastCheckedAt": {
      +      "type": "integer"
      +    },
      +    "stale": {
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "lastCheckedAt",
      +    "ageHours",
      +    "stale"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / results / items / properties / reasonCodes
      Added value: +{
      +  "description": "finite reasons for the state",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / results / items / properties / signal
      Added value: +{
      +  "description": "what the public forum showed. NO_OBSERVATION means nothing was comparable, which is not the same as nothing being wrong.",
      +  "enum": [
      +    "ELEVATED_PUBLIC_SIGNAL",
      +    "NO_ELEVATED_PUBLIC_SIGNAL",
      +    "NO_OBSERVATION"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / results / items / properties / state
      Added value: +{
      +  "description": "what to do. Separate from `signal`, which is only what was observed.",
      +  "enum": [
      +    "GUARDED_ROLLOUT",
      +    "WAIT",
      +    "HOLD",
      +    "NOT_ENOUGH_EVIDENCE"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / properties / results / items / properties / threads / items / properties / thread_time / description
      Previous value: -"epoch ms the thread was posted"New value: +"epoch ms of the timestamp identified by timeBasis"
    • addedOutput schema / properties / results / items / properties / threads / items / properties / timeBasis
      Added value: +{
      +  "description": "whether thread_time is the topic creation time or only its last activity time",
      +  "enum": [
      +    "TOPIC_CREATED",
      +    "LAST_ACTIVITY"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / properties / results / items / properties / threads / items / required
      Previous value: -[
      -  "title",
      -  "url",
      -  "thread_time",
      -  "version"
      -]New value: +[
      +  "title",
      +  "url",
      +  "thread_time",
      +  "version",
      +  "timeBasis"
      +]
    • addedOutput schema / properties / results / items / properties / unknowns
      Added value: +{
      +  "description": "what this answer does not know. Never empty.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description discloses meaningful runtime behavior: per-item independence with its own error, verdict counts returned, a 25-item ceiling with 'more than that is reported, not silently cut', the non-safety meaning of insufficient-data, and the non-CVE/non-advisory nature. These are substantive behaviors not inferable from annotations alone.

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?

The description is longer than the average MCP tool, but every sentence contributes essential guidance: use case, batching rationale, verdict semantics, per-item failure, counting, limit behavior, definition of insufficient-data, scope boundary, and CVE distinction. It is front-loaded with the core answer and then expands into necessary nuance, so it earns its length without being bloated.

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?

Given that an output schema exists (so return format is covered structurally), the description covers all critical call-time context: what the tool does, when to use it, how to batch plugins, behavior on bad items, verdict meanings, scope restrictions, and the distinction from CVE advisories. No information an agent needs to decide to call or format the input is missing.

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?

The input schema already fully documents the single `plugins` parameter, including item shape and examples for `plugin` and `version` (schema coverage is 100%). The description adds context like 'a whole site's plugin list' and 'exact versions in use' and explains the 25-item limit behavior, but these are more usage guidelines than parameter semantics. Since the schema carries the meaning, the baseline 3 is appropriate; the description adds limited new semantic value.

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 and resource: 'Answers: which of this site's plugin updates are risky right now?' and explicitly differentiates from the sibling tool with 'Prefer this over the single check whenever there is more than one plugin.' This allows an agent to distinguish the batch variant from wp_update_radar_check without needing other context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says exactly when to choose this tool over the single check: 'Prefer this over the single check whenever there is more than one plugin to look at' and gives a practical cost rationale. It also scopes usage by stating wordpress.org plugins only and excludes premium plugins and themes. This is clear, actionable guidance with no ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources