On this page
When a website starts returning errors, vendor status is one useful piece of the investigation. Statusfield’s MCP server lets a compatible AI assistant read your monitoring records without asking you to copy them into chat.
Use it for questions such as “Which of my monitored services are reporting problems?” or “Does Statusfield have this vendor in its catalog?” Keep application logs and endpoint checks alongside the answer: vendor status does not establish the cause of an application error.
What the MCP server exposes
Three read-only tools use the same workspace API key:
| Tool | What it does |
|---|---|
list_my_down_services | Lists active workspace monitors with non-operational states |
get_service_status | Reads recorded status for a service your workspace actively monitors |
search_services | Searches catalog metadata by name |
Catalog search is available without monitoring each search result. Status lookups require an active monitor in the key’s workspace. For your full active monitor list, including operational records, use the REST GET /api/v2/monitors endpoint.
Connect Claude Code
On Starter, Pro or Team, including eligible trials, create a key in Integrations → API Keys. Copy it when it is created; it is shown only once.
claude mcp add --transport http statusfield https://statusfield.com/api/mcp \
--header "Authorization: Bearer sf_your_key_here"Replace the placeholder with your key. This uses the Claude Code HTTP connection syntax. Keep the key out of prompts and shared files.
Use /mcp in Claude Code to inspect the connection. If a request fails, check the key, workspace plan and request limits in the MCP guide.
Connect another client
Your client must support a remote Streamable HTTP server with an Authorization header:
- Server URL:
https://statusfield.com/api/mcp - Header:
Authorization: Bearer sf_your_key_here
Use the client’s documented remote-server settings. A field that accepts only a URL is not enough for Statusfield’s Bearer authentication. The MCP guide describes the server requirements; client-specific setup can differ.
Questions to use during an investigation
These examples are illustrative. The actual answer depends on the records returned and how your assistant uses them.
A checkout starts failing
Ask: “Which of my monitored services are reporting problems that could affect checkout?”
If the result contains a payment-provider incident, compare it with your application errors and the provider’s incident details. It is a lead to investigate, not proof that your code is working correctly. A provider can also report operational while your account or endpoint fails.
You are preparing a deployment
Ask: “Check the recorded status of our monitored dependencies before this deployment.”
A reported incident may be a reason to investigate or postpone. An empty problem list does not approve the deployment: continue your normal tests and release checks. The MCP tools do not block or run deployments.
You want to monitor a new vendor
Ask: “Find Resend in the Statusfield catalog.”
search_services can return its catalog entry. Add the vendor to your workspace in Statusfield before requesting its status through get_service_status. The assistant cannot create the monitor through these tools.
You are preparing a team update
Ask: “List our monitors reporting problems and separate those observations from anything we still need to investigate.”
Use the answer as a starting point for the team’s review. The MCP problem-list output provides names and states; it does not provide incident start times or a complete incident narrative. Do not ask the assistant to fill those gaps by guessing.
Reading the answer correctly
The tools read existing records. They do not launch fresh probes, identify the cause of an outage, or prove that every user workflow succeeds.
An empty problem list means no matching records were returned. It does not cover dependencies you have not added. MCP status text does not include observation timestamps; use the REST API or service detail page when freshness matters.
Vendor status, endpoint checks and job check-ins answer different questions:
- Vendor monitoring follows what providers report about their services.
- Uptime monitoring checks responses from your own public HTTPS URLs.
- Heartbeat monitoring watches for expected check-ins from scheduled jobs. See the product page for access and setup requirements.
Choose the monitor that matches the failure you need to notice, then use the API or assistant to read the resulting context.
Set up your first query
- Choose a plan with MCP access.
- Add the vendor services you want to query to your workspace.
- Create a key in Integrations → API Keys and connect your client.
- Ask about one monitored service and compare the returned scope with its detail page.
The API and MCP server are read-only. They cannot create monitors, change settings or send alerts. Configure alert destinations separately when you need updates delivered without asking an assistant.
See the MCP documentation for connection details and the REST API reference for scripts and internal dashboards.
Keep your vendors in view.
Choose from 7,000+ services, follow the components you use, and configure alerts for your team.
Try any paid plan for 30 days, no credit card required. Free trial for first-time customers.