Skip to main content
Glama
Sign In
API Change Monitor MCP Server

API Change Monitor MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Monitor API changelogs, deprecations, status, and OpenAPI

monitor_api_changes
Read-only

Monitor APIs and public sources for changelog, status, deprecation, and OpenAPI changes, returning only what changed since the last run to catch breaking updates early.

Instructions

Watch third party APIs and return only what changed since the last run with the same state_key. Give vendors (github, stripe, shopify, hubspot, openai, anthropic, google-ads, twilio, slack, notion, atlassian, cloudflare, vercel, plaid), any changelog, feed, deprecation page, status page, or OpenAPI JSON URL in sources, and API endpoints in endpoint_urls. Every source gets one row per run (source_baseline on the first check, then source_check with changes_found), plus one row per change: changelog_entry, deprecation_notice, breaking_change, incident_new, incident_update, incident_resolved, openapi_operation_added, openapi_operation_removed, openapi_operation_deprecated, openapi_version_change, sunset_header, or deprecation_header, each with is_deprecation, is_breaking, and sunset_date. Unreadable sources come back free with a row_status saying so. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per change row and per source check that is a first check or finds a change; an unchanged source is free.

Input Schema

NameRequiredDescriptionDefault
watchNoFor vendor presets, any of: changelog, deprecations, status, headers, openapi. Empty means changelog, deprecations, status, and headers. openapi reads the vendor's OpenAPI document (up to 14 MB) and reports operations added, removed, or deprecated. Without changelog, changelog sources return only deprecations and breaking changes. URLs you list in Source URLs are always read.
sourcesNoAny other public URLs to watch, one per line: a changelog or release notes page, an RSS or Atom feed, a deprecation or sunset dates page, a Statuspage site or its history.rss feed, or an OpenAPI or Swagger JSON document. The kind is detected from what the URL returns.
vendorsNoAPI vendors to watch, one per line. Each expands to the public sources read for it: changelog, deprecation page, status history, and OpenAPI document where one is published. Available: github, stripe, shopify, hubspot, openai, anthropic, google-ads, twilio, slack, notion, atlassian, cloudflare, vercel, plaid.
keywordsNoReturn only change rows whose title, summary, categories, or operation contains one of these words. Every change still updates the saved state.
state_keyNoNames the saved state, so separate schedules keep separate baselines. Runs with the same state key and source compare against each other.
proxy_modeNoHow sources are fetched. Default auto.
reset_stateNotrue to ignore the saved state and record a new baseline for every source. Default false.
endpoint_urlsNoAPI endpoints to call without credentials, one per line. The response headers are read for Sunset (RFC 8594), Deprecation (RFC 9745), and Link relations deprecation, sunset, and successor-version. Only GET requests are sent.
max_charge_usdNoOptional. The run stops before it would charge more than this.
include_snapshotNotrue to also return the current entries, incidents, or operations of a source on its first check, up to Max change rows per source. Each snapshot row is billed as a snapshot row. Default false.
max_changes_per_sourceNoChange rows returned per source per run, 1 to 1000. The rest are counted in changes_found. Default 100.
only_deprecations_and_breakingNotrue to return only change rows tagged as a deprecation or breaking change, OpenAPI operations removed or deprecated, and header changes. Incidents and plain changelog entries are left out. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the read-only annotation, the description discloses APIFY_TOKEN requirements, billing behavior per change row and source check, that unchanged and unreadable sources are free, how run failures are returned, and how source rows versus change rows are produced. This is rich operational context that an agent could not infer 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 front-loaded with the core purpose and state_key behavior, and nearly every sentence carries useful information about inputs, outputs, or billing. It is a single dense paragraph and enumerates many row types, so it is slightly overstuffed but not wasteful.

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?

For a 12-parameter, complex monitoring tool with no output schema, the description is unusually complete: it explains input modes, incremental state, return row structure, failure behavior, and cost implications. An agent has enough information to invoke it correctly and understand the result shape.

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 documents all 12 parameters thoroughly. The description reiterates key parameters like sources, vendors, endpoint_urls, and state_key but adds little parameter-level syntax or constraint detail beyond what the schema provides, making 3 the appropriate baseline.

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: watch third-party APIs and return only changes since the last run with the same state_key. It clearly identifies the kinds of sources and outputs, so an agent can understand the tool without opening its schema.

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

Usage Guidelines4/5

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

It gives clear usage context: supply vendor presets, arbitrary sources, or endpoint_urls; reuse state_key for incremental comparison; use reset_state to rebaseline. There are no sibling tools to distinguish against, and it does not explicitly state when not to use it, keeping this below a 5.

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