Sentinel: API schema drift tools for agents

An MCP server that answers one question agents keep needing mid-task: "did this API change shape, and will it break me?"

Sentinel infers JSON Schemas from live responses, diffs them structurally, and ranks every change by what it will do to a consumer:

Severity	Meaning	Examples
breaking	existing consumers can crash	field removed, type replaced (number → string)
risky	consumers may crash on some payloads	field newly optional, newly nullable, type broadened, new value in a declared enum
additive	safe for existing consumers	new field, type narrowed, any value dropped from an enum, any change to an inferred enum candidate set

2 breaking, 0 risky, 2 additive change(s).
[breaking] data.items[].price changed type number → string;
[breaking] data.items[].sku was removed;
[additive] data.items[].status no longer includes value(s) "archived";
[additive] data.items[].currency is a new field.

Tools

Tool	What it does	Cost
infer_schema(json | url)	Infer a JSON Schema — types, required vs optional fields (learned across array items), and small string sets as enum candidates	free
save_baseline(name, schema)	Store a schema under a name for later comparison	free
diff_schemas(before, after)	Severity-ranked structural diff; each argument is an inline schema or a saved baseline name	charged per call
check_endpoint(url, baseline)	Fetch → infer → diff in one call. First call creates the baseline; later calls detect drift	charged per call

Connect

This Actor runs in Standby mode and speaks MCP over Streamable HTTP. Point any MCP client at the Actor's Standby URL with /mcp appended and your Apify token:

https://daneli--sentinel-schema-drift-mcp.apify.actor/mcp?token=<APIFY_TOKEN>

Claude Code:

$claude mcp add --transport http sentinel "https://daneli--sentinel-schema-drift-mcp.apify.actor/mcp?token=<APIFY_TOKEN>"

Baselines persist in the Actor's key-value store, so a schema saved in one session is still there in the next.

When an agent calls this

Before building an integration. A coding agent is about to write code against a vendor API. It calls infer_schema(url) to see the real shape (not the docs' claimed shape), writes the client, then save_baseline("vendor-orders", schema) so future sessions can verify nothing moved.

Gating a deploy. A CI agent runs check_endpoint(staging_url, "orders-api") before promoting a build. Verdict breaking fails the pipeline with a machine-readable change list; additive passes with a note.

Watching a dependency. A scheduled monitoring agent checks three vendor endpoints nightly. The first run saved baselines; every later run is one check_endpoint call per endpoint, and the agent only wakes a human when the verdict is breaking or risky — with the exact paths that changed (data.items[].price changed type number → string), not a wall of JSON.

How it behaves

• Optionality is learned, not guessed: a field is required only if it appeared in every sampled object. One sample of one object means everything looks required — point infer_schema at list endpoints for real signal.
• Enum candidates are a guess, so they never gate: a value appearing in a hand-written enum is risky, but any change to an inferred candidate set is additive. Values shaped like identifiers (URLs, timestamps, UUIDs, digests, emails, opaque tokens, numeric strings) are never treated as enum candidates.
• diff_schemas also accepts hand-written JSON Schema (the subset type, properties, required, items, enum), so you can diff a live response against a spec, not just against a saved baseline.

Security

infer_schema(url) and check_endpoint(url) fetch caller-supplied URLs, so this Actor guards against SSRF: http/https only, hostnames are DNS-resolved and private/reserved addresses (loopback, RFC 1918, link-local/cloud-metadata, CGNAT, unique-local IPv6) are refused, and redirects are followed manually with the same check on every hop. It only reaches public endpoints — it cannot be pointed at internal infrastructure.

Limitations (v0.1)

• JSON only. No XML, no multipart, no auth headers on fetches yet.
• The diff understands the schema subset infer_schema emits; anyOf/allOf in foreign schemas are not resolved.
• Baselines live in one key-value store per Actor — fine for one team, not yet multi-tenant.

MIT.