---
title: 'Monitoring for the Agentic Web'
description: 'MCP server checks that speak the real protocol: initialize handshake, tool catalog, tool-call assertions, and schema-drift detection.'
canonical_url: 'https://yorkermonitoring.com/agentic-web'
---

# Monitoring for the agentic web

Your MCP server has users that never open a browser. They initialize a session, read your tool catalog, and call your tools. Yorker monitors that the same way it monitors your site: on a schedule, from real locations, speaking the real protocol.

Every run executes the full MCP session over Streamable HTTP:

```
# 1. initialize → protocolVersion + capabilities
# 2. notifications/initialized
# 3. tools/list → assert expected tools
# 4. tools/call → assert output
# 5. schema hash + diff vs previous run
```

## The failures a ping never sees

MCP servers fail in their own ways, and the failures do not move the HTTP status code. The process stays up and keeps answering 200 while everything an agent needs is broken behind it.

**Broken handshake.** Every MCP session starts with an initialize exchange that has to return a protocol version and the server's capabilities. If a deploy breaks it, no client gets past the first request, but the server still answers HTTP and looks healthy from the outside. Yorker sends a real initialize on every run and fails the check at that phase when the response is wrong.

**Missing tool.** Clients plan against the catalog your server advertises in tools/list. When a tool your integrations use drops out, nothing errors on your side; requests for it just stop working somewhere downstream. List the tools you expect in the check config and the check fails the moment one goes missing.

**Changed schema.** The tool exists and the server is up, but the input schema changed and callers built against the old shape now send arguments the server rejects. Yorker hashes each tool's input schema on every run and diffs it against the previous run, so a schema change becomes a reported diff instead of a slow trickle of client errors.

**Wrong output.** A tool can answer quickly and still be wrong. Test calls invoke a tool with arguments you choose and assert the output contains what you expect: a contract test that runs on a schedule.

## Schema drift, caught on schedule

Every run hashes each tool's input schema and diffs it against the previous run. A tool that was added, removed, or changed shape shows up as a diff you can alert on, with a structured event forwarded to your OTLP backend naming the affected tools.

Failures name the phase that broke. Results carry per-phase timing for the handshake, the catalog read, and each tool call, as standard OTLP into the backend you already run.

[How MCP monitoring works](/features/mcp-monitoring)

## A monitor, not a new tool

MCP checks are ordinary monitors in Yorker: same alert rules, same locations, same YAML config, same OTLP export as your HTTP and browser checks. If you already monitor your site with Yorker, adding your MCP server is a few lines of config.

```yaml
monitors:
  - name: Docs MCP Server
    type: mcp
    endpoint: https://mcp.example.com/mcp
    frequency: 5m
    expectedTools:
      - search_docs
      - get_page
    testCalls:
      - toolName: search_docs
        arguments: { query: pricing }
        expectedOutputContains: "Plans"
    detectSchemaDrift: true
```

An MCP session bills as one run at the HTTP rate: 10,000 HTTP + MCP runs a month free, unlimited on the paid plan.

[Setup guide](/docs/guides/monitor-mcp-servers)

## Coming soon: see your site the way an agent sees it

Browser checks that run from an AI agent's perspective: the user agent of the crawlers and agents you want to let through, on a schedule, from multiple regions, with the filmstrip showing exactly where a bot wall got in the way.

## Start free

The free tier includes 10,000 HTTP + MCP checks and 1,500 browser checks per month. No credit card required.

[Start free](https://yorkermonitoring.com/sign-up) or spin up from the terminal:

```
npx @yorker/cli init
```