Skip to content
Fixter Docs
↑↓ Select⏎ OpenEsc Close

Creating your first test

This page gets one test running. The example monitors Fixter’s own MCP server at https://mcp.fixter.dev, so you can follow it before you have a server of your own; swap in your URL at any point.

Before you start

Section titled “Before you start”
  • A URL reachable from the public internet. Private and internal addresses are refused; see Addresses Fixter will not test.
  • A credential, if the target needs one. mcp.fixter.dev does: create a key under Settings > API keys (the value is shown once) and store it as a Bearer token credential; see Credentials.
  • A Slack channel, if you want notifications anywhere but email. Connect it first; see Notifications.

With your agent

Section titled “With your agent”

Ask in plain language:

Monitor https://mcp.fixter.dev every minute with my Fixter API key and tell me if it stops answering.

The agent works in five steps:

  1. Detect the protocol with detect_mcp_protocol, giving mcpUrl and, for a server that needs one, mcpCredentialId. It reads outcome (DETECTED, NONE or RATE_LIMITED) and newestSupported, the newest revision the server speaks. A detection is not a run and saves nothing.
  2. Store the credential with create_api_test_credential: type BEARER, token set to the API key. It reads the returned id and passes it as mcpCredentialId (httpCredentialId for an HTTP test).
  3. Create the test with create_api_test: type MCP, mcpUrl, mcpCredentialId, mcpTier HANDSHAKE, intervalSeconds 60. Saving runs the test once first. A passing save returns the test with its id and the run as trialRun. A refused one saves nothing and comes back as an error: a sentence starting Not created: that says what failed and ends The test was not saved; fix its configuration and call create_api_test again.
  4. Read the runs with get_api_test_runs, giving the test’s apiTestId. It reads each run’s outcome, timing, assertion failures and traceId, and calls correlate on that traceId to find what happened inside the target, when the target reports to Fixter.
  5. Choose channels with set_api_test_destinations, giving the apiTestId and channelIds from list_alert_channels. Without it, the test follows the API tests source; see Notifications.

Two things differ over MCP from the app: get_api_test_runs does not return a run’s recorded request and response (open the run in the app for those), and update_api_test replaces the test’s whole configuration, so the agent passes every field it wants to keep.

In the app

Section titled “In the app”

  1. Create the credential. Open the API Tests page, click Credentials, then New credential. Name it Fixter API key, set Type to Bearer token, paste the key into Token, and click Create credential.

  2. Create the test. Click New API test. Set Name to Fixter MCP, Type to MCP server, paste https://mcp.fixter.dev into URL, and pick Fixter API key under Credential. The editor shows Detecting protocol…, then sets Protocol revision to Newest supported with currently <revision> beside it, and lists each revision as Supported or Not supported. Under Passing means, leave Check depth at Handshake. Leave Schedule at its defaults: check every 60 seconds, give up after 10 seconds, no retries, down after 3 failed runs.

  3. Save it, which runs it once. Click Create API test. The button reads Running test… while Fixter runs the test once, with one attempt and no retries. When it passes, the test is saved and the app says It passed its trial run in <latency> and will run on the schedule you set. When it fails, nothing is saved: the editor stays open, headed Trial run failed, with the cause, the failed assertions and the request and response. Fix what it names and click Create API test again. See The trial run on save.

  4. Watch the first scheduled run. Open the test from the API Tests page. The trial run is not in the run history, so the history starts with the first scheduled run. Before it, the page shows Protocol: Newest supported (not run yet); after it, the run is listed as Success, the test is Up, and the page shows Protocol: Newest supported (currently <revision>).

  5. Open the run. It shows the run message and any failed assertions, the trace id with Open in Logs and View trace, the Request and the Response. What each part means is on What a run records.

Next steps

Section titled “Next steps”
  • Go deeper than the handshake: set Check depth to Tools list with the tools your server must advertise, or Tool call to call one. See MCP tests.
  • Monitor an HTTP endpoint: set Type to HTTP endpoint and choose a status pattern, latency, header and body assertions. See HTTP tests.
  • Send a different value on every run with request variables.

Still stuck? Email info@fixter.dev and one of our founders will help you fix your problem asap.