MCP Monitors

Availability

MCP monitors are available in organization projects. In other projects, the Monitors page has no Add MCP Monitor button; contact support to turn MCP monitors on.

An MCP Monitor tests an AI tool or agent that exposes the Model Context Protocol (MCP). Instead of making a plain HTTP request, APIContext connects to an MCP server, calls one of its tools or resources, and asserts on the response, so you can verify on a schedule that your AI-powered services stay reliable and correct.

When to use

Use an MCP monitor when you want to:

• Verify that an MCP server responds to tool calls within acceptable latency bounds
• Assert on the structure or content of tool outputs (e.g., a code-generation tool returns valid JSON)
• Alert on regressions in AI service availability or response quality

How it works

1. APIContext connects to your MCP server over the configured transport (HTTP, SSE, or stdio).
2. It issues a tool call or resource request with your configured parameters.
3. The response is evaluated against your assertions (status, schema, content checks).
4. Results are recorded (latency, pass/fail, raw response) and available in the project dashboard.

Setup

Step 1: Create an MCP monitor

1. In the sidebar, under Configure Monitoring, click Monitors.
2. Click + Add MCP Monitor.

Step 2: Configure the connection

The Create MCP Monitor panel opens. Fill in the fields:

Field	Description
URL	The URL of your MCP server, for example https://mcp.example.com
Name	Optional. If you leave it empty, the monitor is named after the URL
Timeout (ms)	Maximum time to wait for a response before marking the result as failed. The default is 30000 (30 seconds)
Auth setting and Token	Optional. The authentication setting and token the monitor uses to connect to the server
MCP Steps Configuration	The steps to run in one session, in order. Each step has a type: List Tools, Call Tool, List Resources, List Resource Templates, Read Resource, List Prompts, Get Prompt, or Wait for Server Responses. A Call Tool step takes a Tool Name

Then click Create and Edit. Every step type and its fields are in the configuration reference.

Step 3: Set input parameters

In a Call Tool step, under Parameters, provide the tool's input in JSON format. Use APIContext variables (%%VAR%%) for values that change between runs.

Step 4: Add assertions

Use the Assertions tab to check the response:

• Status: the tool returned a result (not an error)
• Schema: the response matches a JSON schema
• Content: a JSON path value equals, contains, or matches a pattern

Step 5: Add to a schedule

Add the monitor to a schedule to run automatically.

Result types

MCP monitor results distinguish two kinds of error:

• MCP Transport Error: a problem communicating with the MCP server.
• MCP server returned an error: the server was reached but returned an error of its own.

What the monitor sends

A monitor makes the requests you configure and nothing else: it does not fuzz inputs, scan for other endpoints, or try requests you did not set up. If Retry on failure is on, a retry repeats the same request. What each kind of monitor sends besides your own settings:

API monitors, including API monitors run as workflow steps, send one request to the URL you give, with these additions:

• User-Agent: APImetrics/<version> followed by the HTTP library versions, when the monitor sets no User-Agent of its own. The versions change, so match the APImetrics/ prefix.
• traceparent: a W3C Trace Context header, when the monitor sets none.
• X-APIContext-Agent: true: when Use APIContext Standard Headers is on, on the monitor's Advanced tab. It is on for new monitors.
• Cookie: in a workflow, the cookies that earlier steps sent and received, unless the step sets its own Cookie header.
• Standard HTTP headers the client adds: Host, Accept: */* when no Accept header is set, and Content-Length when there is a body. New monitors start with an Accept: application/json header, which you can change.

New monitors do not follow redirects. If you turn on Follow redirects, the monitor also requests the address a redirect points to, as a browser would.

Browser monitors open the page in a real browser, so the browser also requests whatever the page loads (scripts, images, and the API calls the page makes), as a visitor's browser would. When Use APIContext Standard Headers is on, those requests carry X-APIContext-Agent: true.

MCP monitors open an MCP session with your server, then run only the steps you configure, such as listing tools or calling a tool. A tool call runs that tool with the arguments you set, so choose tools that are safe to run on a schedule. Requests carry a User-Agent that begins APImetrics-MCP/ unless the monitor sets its own, and a traceparent header when none is set.

To allow monitor traffic through a firewall or bot manager, see Identify and allow-list APIContext monitor traffic.

See also

• MCP monitor configuration reference: the fields, step types, and limits the API and CLI accept
• AI monitoring on the APIContext website
• Set conditions on a monitor
• Authentication in a workflow
• Monitor types overview