Upgrade Brief

by dev.workers.shopttyass-85f.upgrade-brief

github action breaking changes

github_action_breaking_changes

Read-onlyIdempotent

GitHub Actions upgrade brief between two versions of an action (e.g. actions/checkout v3 to v4): breaking changes from release notes and migration docs, action.yml input/output diff (removed, renamed, new required inputs, changed defaults), Node runtime change (node16/node20 removed, node24), deprecations, concrete workflow edits with SHA pin, and sources. Paid: $0.005 USDC per call via x402.

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": {
      "action": "<action>",
      "from": "<from>"
    },
    "name": "github_action_breaking_changes"
  }
}

Input Schema

Name	Required	Description
`to`	No	Target: major tag ('v4' = newest v4.x.y, what @v4 runs), exact tag, or latest (default)
`from`	Yes	Ref used now: major tag ('v3'), exact tag ('v3.6.0') or pinned commit SHA
`with`	No	Optional comma-separated input names your step passes in with:, to flag removed/changed ones
`action`	Yes	GitHub Action as in 'uses:', owner/repo[/path], e.g. 'actions/checkout', 'github/codeql-action/init'
`prereleases`	No	Include prerelease tags

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, and the description adds genuinely new behavioral facts: the call is metered at $0.005 USDC per call via x402, and it details the report contents (release notes, action.yml input/output diff, Node runtime change, workflow edits with SHA pin, sources). It doesn't cover failure behavior for unknown actions or the default for `prereleases`.

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 dense sentence that front-loads the core purpose before the enumerated report contents and pricing. Every clause carries information, though the parenthetical lists make it a run-on that is slightly harder to scan than a structured breakdown.

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?

With no output schema, the description does the work of describing the return payload (breaking changes, action.yml diff, runtime change, workflow edits, sources) and discloses the per-call cost. Minor gaps remain around error cases and the prerelease default, but an agent has enough to call it correctly.

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 description coverage is 100%, so the schema already explains `from`, `to`, `action`, `with`, and `prereleases` in detail. The description's only addition is the usage example 'v3 to v4', which illustrates but does not extend the parameter semantics beyond what the schema provides. Baseline 3 applies.

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: an upgrade brief for a GitHub Action between two versions, with a concrete example (actions/checkout v3 to v4) and an enumeration of what the brief contains. The 'GitHub Actions' scope separates it cleanly from the npm_/pypi_breaking_changes siblings without needing to name them.

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?

The upgrade-review context is clear from 'upgrade brief between two versions of an action', and the v3→v4 example implies the use case. However, with eight siblings present (dependency_upgrade_plan, npm_/pypi_ variants), it never states when to prefer this tool over them, nor any exclusions or prerequisites.

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

All Upgrade Brief tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?