Skip to main content
Glama

EOL Watch

Get breaking changes of a provider

get_provider_changes
Read-only

Returns what the page of one provider, tool or module shows: the range of releases that is tracked, the summary sentence, the notices and the breaking changes of each release that lists any. Send from with the version in use to get only the releases above it. Read the notices before you call a range clear: they say which releases were not tracked or whose release notes were not read.

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": {
      "provider": "<provider>"
    },
    "name": "get_provider_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
fromNoThe version in use, or a version constraint, of at most 64 characters. Only releases newer than that version are in the answer. For a constraint, that version is the lowest one the constraint allows. Leave it out for every tracked release whose release notes were read and list a breaking change.
providerYesKey of the provider, tool or module, as in the key field of list_providers.

Output Schema

NameRequiredDescriptionDefault
keyYesKey of the entry: the provider key (for example azurerm) or the name of the module. It is the last part of its page address.
urlYesPage of the entry on the site.
fromYesThe version in use that the answer starts from, as plain semver. For a constraint it is the lowest version the constraint allows. Only newer releases are in the answer. Null when no version was given or when the value sent is not a version or a constraint.
kindYesWhat the entry is: a Terraform provider, a tool or language, or a module.
nameYesDisplay name of the entry.
as_ofYesThe UTC day (YYYY-MM-DD) every value that depends on the day was counted for.
cloudYesCloud the entry belongs to.
stateYesHow the answer was chosen. all: no version was given, so every tracked release whose release notes were read and list a breaking change is in it. range: the tracked releases newer than from whose release notes were read and list a breaking change are in it. clear: from is not older than the oldest tracked release, the release notes of every tracked release newer than from were read, and none lists one. partial: among the tracked releases newer than from whose release notes were read, none lists one, but part of the range was not read: from is older than the oldest tracked release, or the release notes of a tracked release newer than from were not read. Such a range is not clear. invalid: the value sent as from is not a version or a constraint, so the answer is the same as for all. In every state, read the notices before you call a range clear.
noticesYesThe sentences that go with the summary: a range that reaches below the oldest tracked release and versions whose release notes were not read, both word for word from the page, and a from value that could not be read. Empty when the summary stands on its own.
subjectYesWhat a module deploys, as the Azure Verified Modules index names it. Null for providers and tools.
summaryYesThe summary sentence of the page for this answer.
json_urlYesThe same page as JSON.
releasesYesThe releases in the answered range whose release notes were read and list a breaking change, newest first.
repo_urlYesThe GitHub repository whose releases are read.
namespaceYesWhere the entry is published: its address in the Terraform Registry, or its GitHub repository when it is not in the registry.
short_urlYesShort address of the page for this answer. It redirects to url.
latest_dateYesDay that release was published (YYYY-MM-DD), or null when it is not known.
markdown_urlYesThe same page as Markdown.
registry_urlYesPage of a module in the Terraform Registry. Null for providers and tools.
counted_sinceYesSet when the tracked releases start less than twelve months before the as_of day: the oldest tracked version, where that count really starts. Null otherwise.
latest_versionYesThe newest tracked stable release, without a leading v. Null when none is loaded.
unread_versionsYesThe versions in the answered range whose release notes were not read, newest first. Nothing is known about breaking changes in them, and they are not in releases.
latest_confirmedYesTrue when the tracked list holds every stable release from oldest_tracked_version on, so latest_version is the latest stable release. False when it is only the newest release tracked here: a newer one may exist.
latest_notes_readYesFalse when the newest release is known from the Terraform Registry only and has no GitHub release: its release notes were not read. Null when no release is loaded.
oldest_tracked_versionYesThe oldest tracked stable release. Releases before it were not read. Null when none is loaded.
breaking_releases_last_12_monthsYesNumber of tracked stable releases published in the twelve months up to the as_of day whose release notes were read and list at least one breaking change.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds a genuinely useful caveat beyond that: the result may be incomplete because some releases were not tracked or their notes not read, so an agent must inspect notices before concluding nothing is breaking. Return shape is not described, but an output schema exists.

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 sentences, front-loaded with the returned content, then the filtering rule, then the caveat in priority order. Some wording is clunky ('what the page ... shows', 'of each release that lists any') but nothing is truly redundant.

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?

With an output schema, annotations, and two fully documented parameters, most of the burden is carried elsewhere, and the description adds the important completeness caveat. It still leaves the agent without guidance on how this differs from sibling change-listing tools or on ordering/scope of the returned range.

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 coverage is 100%, so baseline is 3. The description's note about 'from' (version in use, only newer releases returned) largely restates what the schema's own description for 'from' already says, adding little new meaning for either parameter.

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?

The description names a concrete payload: tracked release range, summary sentence, notices, and breaking changes per release for one provider/tool/module. It also ties the provider key back to list_providers, which orients the agent, but the phrasing 'what the page of one provider ... shows' is roundabout and it never contrasts itself with sibling lookups like recent_changes.

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?

It gives real guidance for the optional 'from' parameter ('send from with the version in use to get only releases above it') and a caution to read notices before declaring a range clear. However it never states when to prefer this tool over alternatives such as recent_changes or search_items, leaving the selection decision to inference.

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