MCP Canary

Synthetic monitoring for MCP servers

Your MCP server says 200. Your tools are broken.

MCP Canary calls a real tool on a schedule, checks the answer, and emails you when it breaks.

Set up by your coding agent in one command. No signup, no dashboard.

$ curl -fsSL https://mcpcanary.com/install.sh | sh

One ~8 MB native binary, open source on GitHub. macOS, Linux, Windows. 7-day trial, no card. Or test your server in the browser first.

$ canary inspect https://api.acme.dev/mcp
https://api.acme.dev/mcp: PASSED (412 ms)
TOOL             SIDE EFFECTS
search_customer  read_only
create_invoice   explicitly_mutating

# the agent picks the read-only tool

Give this to your coding agent

Set up continuous external monitoring for the production MCP endpoint in this repository with MCP Canary (https://mcpcanary.com/llms.txt). Choose a safe deterministic canary, keep the configuration in the repository, show me the dry run before you enable it, and verify that it works.

Uptime checks see a 200. Your users' agents see a broken tool.

Many MCP servers answer tools/list from code, so the server looks fine while the database behind the tool is dead. MCP Canary checks at three levels.

What brokeL1 handshake + toolsL2 tool callL3 call + assertions
Server down, DNS, TLS, 5xx caught caught caught
Protocol or transport broken caught caught caught
Tool removed or schema changed caught caught caught
Backend dead: database down, upstream key expired missed caught caught
Tool answers with wrong data missed missed caught

From "monitor this" to a running check in four commands

  1. 01

    Install

    One native binary from https://mcpcanary.com/install.sh. No Node, Python, .NET, or Docker.

    curl … | sh
  2. 02

    Inspect

    The agent lists the tools and their safety hints, and picks one marked read-only.

    canary inspect URL
  3. 03

    Preview, then set

    --dry-run shows the exact tool, arguments, assertions, and schedule, and saves nothing. The same line without it creates or updates by name, so it goes into your deploy workflow.

    canary monitor set NAME … --dry-run
  4. 04

    Gate

    Run a check after each deploy. Exit 0 passes the pipeline; anything else fails it with JSON evidence.

    canary monitor test NAME

Between deploys, scheduled checks run on your interval (as often as every 30 seconds). An incident opens only after a confirming re-check and resolves on the next passing check. A CI test never pages anyone. An email (canary email add [email protected]) or a signed webhook tells you, or your agent, what changed.

Built for the agent in your terminal

JSON everywhere

Every command takes --json and prints only the API's JSON, errors included. Nothing else on stdout.

Stable exit codes

0 passed, 3 target unhealthy, 31 target unreachable, 40 payment needed. A CI step needs no parsing.

Never calls a risky tool

A tool without readOnlyHint is never called unless you pass --allow-side-effects. Silence is not consent.

Evidence with every failure

A failed assertion returns the path, the expected value, and what the tool really returned.

Contract change alerts

Tool added, argument removed, type changed: each check diffs the tool schemas against the last one.

Secrets stay secret

Target tokens come from environment variables or an OAuth sign-in, are encrypted at rest, and are never returned.

Errors that say what to do

Every error has a stable code, a message with the fix, and retryable: true or false.

No account needed

The first monitor creates an anonymous workspace and saves its token. There is no signup step.

Everything is an API

Anything the CLI does is an HTTP call. The OpenAPI document is public.

See it before it runs

--dry-run shows the tool, its safety class, the arguments, the assertions, and the schedule. Nothing is saved, no trial starts, and the tool is not called.

Known fixture, right environment

Assert several fields of a record that exists only in production. Valid JSON from staging, a stale replica, or an empty table fails the check.

Open-source CLI

Read what the binary does with your tokens, or build it yourself. MIT license, and each release tag points at its source. Source on GitHub

Pricing

The first monitor starts a 7-day trial of the real product. After it, a human pays from a link that the agent hands over. Nothing is deleted when access ends; checks pause until someone pays.

Trial

The real product for 7 days. No card.

$0 for 7 days

  • 3 monitors
  • Checks every 5 minutes
  • 7 days of incidents and failed checks
  • 50 on-demand checks per day
  • 1 alert email, 1 webhook

starts with canary monitor set

Solo

One person, a few production MCP servers.

$24 / month

  • 10 monitors
  • Checks every minute
  • 30 days of incidents and failed checks
  • 500 on-demand checks per day
  • 3 alert emails, 5 webhooks

canary billing upgrade --plan solo

Pro

A team that ships MCP servers every week.

$49 / month

  • 50 monitors
  • Checks every 30 seconds
  • 90 days of incidents and failed checks
  • 5,000 on-demand checks per day
  • 10 alert emails, 20 webhooks

canary billing upgrade --plan pro

Prices in USD, monthly, cancel any time. Payments by Polar, merchant of record.

Questions

Can I see what the agent sets up before it is enabled?

Yes. canary monitor set … --dry-run prints the tool and its safety class, the arguments, the assertions, the schedule, and what applying would do (create a workspace, start the trial, or change named fields). It saves nothing and does not call the tool. Ask your agent to show you the dry run first.

Will a check change data on my server?

Not unless you allow it. MCP Canary calls only tools that declare readOnlyHint: true. Any other tool needs --allow-side-effects, and the rule is checked again on every check, because a server can change its hints.

Which MCP servers can it check?

Public HTTPS endpoints with Streamable HTTP or the legacy HTTP+SSE transport, open or behind auth: a bearer token, custom headers, or an OAuth sign-in. Private and local addresses are blocked.

My server asks users to sign in with OAuth. Can it be monitored?

Yes. canary auth login NAME prints a sign-in link; a human opens it on any device and signs in once. MCP Canary registers itself when the server allows it (client ID metadata document or dynamic client registration), stores the tokens encrypted, and renews them. A server without self-registration, such as GitHub, needs your own OAuth app: pass it with --client-id. If a token cannot be renewed, checks fail with TARGET_AUTH_EXPIRED, which opens an incident like any failure, and you sign in again.

How do I get alerts?

By email: canary email add [email protected]. The address gets a confirm link first, and alerts start after a click. Emails go out when an incident opens or resolves and before access ends; never for single checks. Every email has a one-click unsubscribe. For automation, add a signed webhook.

Where do checks run from?

From one region today. Multi-region checks are on the roadmap.

Where is the configuration?

On the server, which is the one source of truth. Keep the canary monitor set line in your deploy workflow: it is idempotent, so each deploy re-applies the same monitor. canary monitor list --json shows the true state.

What happens when the trial ends?

You get an email 2 days before, with payment links. Then checks and alerts pause, and writes answer 402 with payment links. Your monitors, history, webhooks, and alert emails stay. A payment restores everything at once.

Which platforms does the CLI support?

macOS (Apple Silicon and Intel), Linux x64 and arm64 (glibc 2.34 or later), and Windows x64. Binaries are on GitHub Releases with SHA-256 checksums. The source is in the same repository, MIT licensed.

Put a canary in front of your MCP server

Install, then ask your agent to set it up. Or read the docs first.

curl -fsSL https://mcpcanary.com/install.sh | sh