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

API Change Monitor MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

API Change Monitor MCP Server

Glama score MCP Registry npm version npm downloads license mcpservers.org

An MCP server for the Mamba Labs API Change Monitor actor on Apify. Give it API vendors or URLs. Each run compares every source with the state saved by the last run and returns only what changed.

What's Inside

Related MCP server: FluxProof

What it does

  • Changelogs: new entries from the vendor's changelog feed or page, tagged deprecation_notice or breaking_change when the wording says so, with the first sunset_date named.

  • Status: new incidents and status changes from the vendor's status history feed.

  • OpenAPI: operations added, removed, or deprecated, and the API version, from a published OpenAPI JSON document.

  • Headers: Sunset and Deprecation response headers on API endpoints you list.

  • One row per source per run: source_baseline on the first check under a state_key, then source_check with changes_found, or a free no_change row when nothing moved.

All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.

Quick start

You need Node.js 18 or newer and an Apify account with an API token.

Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:

{
  "mcpServers": {
    "mamba-api-change-monitor": {
      "command": "npx",
      "args": [
        "-y",
        "@mambalabsdev/mcp-api-change-monitor"
      ],
      "env": {
        "APIFY_TOKEN": "your-apify-token"
      }
    }
  }
}

Restart the client. The monitor_api_changes tool appears.

Prerequisites

Example prompts

  • "Did GitHub or OpenAI announce any deprecations or breaking changes since last week?"

  • "Watch the Stripe and GitHub OpenAPI documents and tell me which operations were removed or deprecated."

  • "Has any incident been opened on the Cloudflare or Vercel status pages since yesterday?"

Tool

monitor_api_changes. One tool. Example arguments:

{
  "vendors": [
    "github",
    "openai"
  ],
  "state_key": "api-watch-daily"
}

Inputs

Every buyer facing input of the actor, unchanged. Omitted inputs take the actor's own defaults. Numbers and booleans are sent as strings.

Input

Type

Description

vendors

array

API 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

sources

array

Any 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

endpoint_urls

array

API 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

watch

array

For 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

keywords

array

Return only change rows whose title, summary, categories, or operation contains one of these words. Every change still updates the saved state

only_deprecations_and_breaking

string

true 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

max_changes_per_source

string

Change rows returned per source per run, 1 to 1000. The rest are counted in changes_found Default 100

include_snapshot

string

true 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

state_key

string

Names the saved state, so separate schedules keep separate baselines. Runs with the same state key and source compare against each other

reset_state

string

true to ignore the saved state and record a new baseline for every source Default false

max_charge_usd

string

Optional. The run stops before it would charge more than this

proxy_mode

string

How sources are fetched Default auto

Pricing

Pay per event on Apify, billed to your Apify account. Prices in USD.

Event

Free plan

Bronze

Silver

Gold

change-row, one change on a watched source since the last run: a new changelog entry, deprecation notice, or breaking change, a new or updated status incident, an OpenAPI operation added, removed, or deprecated, an API version change, or a Sunset or Deprecation header change

$0.0035

$0.003325

$0.00315

$0.002975

source-check, one source read and compared with its saved state: the first check of a source, which records the baseline, or a later check that finds at least one change. A source where nothing moved returns a free no_change row, and a source that cannot be read is free

$0.003

$0.00285

$0.0027

$0.00255

snapshot-row, one current entry, incident, or operation on the first check of a source, returned only when include_snapshot is on

$0.001

$0.00095

$0.0009

$0.00085

apify-actor-start, per run start

$0.001

$0.001

$0.001

$0.001

A source where nothing moved returns a free no_change row, sources that cannot be read are free, and so is the one row a refused input returns.

Your keys

The actor needs no key. It reads public changelogs, feeds, status history, and OpenAPI documents, and calls the endpoints you list without credentials. It holds no key of any kind. Proxy traffic adds nothing to your price: Mamba Labs pays the platform costs of the run.

Full actor documentation

apify.com/mambalabs/api-change-monitor

License

MIT. See LICENSE.

Available Tools

1 tool
monitor_api_changesMonitor API changelogs, deprecations, status, and OpenAPIA
Read-only

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.

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.

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedmonitor_api_changes
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.3/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there are no competing tools to confuse; an agent has a single unambiguous entry point for all monitoring tasks.

Naming Consistency5/5

The sole tool name monitor_api_changes follows a clear verb_noun convention and accurately reflects its purpose.

Tool Count3/5

A single tool is thin for a server covering many source types and row types; while the monitoring purpose is focused, there is no separate operation for state management, source listing, or run history, making the surface borderline.

Completeness3/5

The tool covers change detection across changelogs, status pages, and OpenAPI specs well, but lacks explicit operations for managing monitors, resetting or inspecting state_key history, or retrieving past runs, creating notable lifecycle gaps.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • company-change-event-feed

    mambalabsdev
    A
    license
    A
    quality
    A
    maintenance
    Monitors a company domain for changes in hiring, tech stack, funding, firmographics, and social presence, returning only the deltas as typed change events.
    1
    114 npm
    MIT

  • FluxProof

    equinoxaifinance-rgb
    A
    license
    B
    quality
    A
    maintenance
    Enables evidence-bearing change monitoring for public text pages, providing normalized diffing, SHA-256 hashing, and signed webhook notifications.
    6
    MIT

  • Career Change Signal Engine

    mambalabsdev
    A
    license
    A
    quality
    B
    maintenance
    Enables an AI client to track a watch list of contacts and retrieve only what changed since the last run — departures, new employers, replacements, and new hires after a role closed — each row carrying match evidence, source dates, and ready-to-use outreach payloads. It runs the analysis on Apify using the caller's own provider keys, supports stored or caller-held state, and can push results to a signed webhook.
    1
    110 npm
    MIT