Skip to main content
Glama

Get Plugins With Updates

get_plugins_with_updates

Retrieves Jenkins plugins that have available updates so you can identify which installed plugins need upgrading.

Instructions

Get plugins that have available updates

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_plugins_with_updates"
  }
}

Input Schema

NameRequiredDescriptionDefault
depthNoThe depth of the information to retrieve. Default is 0.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.6.0+microtech.5

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden, yet it only implies a read operation via the verb "Get." It says nothing about whether this triggers a check against the remote update site (a potentially slow, network-dependent operation), whether results are cached, what counts as an "available update," or what the returned data looks like.

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?

A single front-loaded sentence with zero padding — nothing wasted. Brevity is not the problem; the content is simply thin rather than verbose.

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?

The tool is structurally simple (one optional param, output schema present so return values need no explanation), which lowers the bar considerably. Still, with no annotations and no routing guidance among four sibling plugin-listing tools, the definition leaves more inference to the agent than it should.

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?

There is a single optional parameter (depth) with 100% schema description coverage, so the schema already documents it and the baseline is 3. The description adds no further meaning about what depth values yield or why an agent would raise it, but no compensation is required here.

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

Purpose2/5

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

The description is essentially the tool name expanded into a sentence: "Get plugins that have available updates" restates get_plugins_with_updates with no added specificity. It does implicitly separate the tool from get_all_plugins and get_plugins_with_problems, but only because the name already does that work, not because the description contributes anything.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of alternatives such as get_all_plugins, get_plugins_with_problems, or get_plugins_with_backup, and no stated preconditions. The agent must infer the selection criteria from the tool name alone.

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