# Creating your first test > Set up a first API or MCP test, from an agent or in the app, see the save run it once, and read its first scheduled run; the worked example monitors Fixter's own MCP server. 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 - **A URL reachable from the public internet.** Private and internal addresses are refused; see [Addresses Fixter will not test](/api-testing/runs-and-uptime/#addresses-fixter-will-not-test). - **A credential, if the target needs one.** `mcp.fixter.dev` does: create a key under [Settings > API keys](https://app.fixter.dev/settings/api-keys) (the value is shown once) and store it as a `Bearer token` credential; see [Credentials](/api-testing/credentials/). - **A Slack channel, if you want notifications anywhere but email.** Connect it first; see [Notifications](/api-testing/notifications/). ## With your agent Ask in plain language: ```text 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`](/reference/mcp/tools/#api-tests-and-uptime), 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`](/reference/mcp/tools/#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`](/reference/mcp/tools/#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`](/reference/mcp/tools/#get_api_test_runs), giving the test's `apiTestId`. It reads each run's outcome, timing, assertion failures and `traceId`, and calls [`correlate`](/reference/mcp/tools/#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`](/reference/mcp/tools/#set_api_test_destinations), giving the `apiTestId` and `channelIds` from [`list_alert_channels`](/reference/mcp/tools/#list_alert_channels). Without it, the test follows the **API tests** source; see [Notifications](/api-testing/notifications/#choose-channels-with-your-agent). 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 1. **Create the credential.** Open the [API Tests page](https://app.fixter.dev/api-tests), 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 ` 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 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](/api-testing/runs-and-uptime/#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 )`. 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](/api-testing/runs-and-uptime/#what-a-run-records). ## 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](/api-testing/mcp-tests/). - Monitor an HTTP endpoint: set `Type` to `HTTP endpoint` and choose a status pattern, latency, header and body assertions. See [HTTP tests](/api-testing/http-tests/). - Send a different value on every run with [request variables](/api-testing/request-variables/). Still stuck? Email [info@fixter.dev](mailto:info@fixter.dev) and one of our founders will help you fix your problem asap.