MCP tools
All tools are served through the single endpoint described in MCP. Your agent sees every tool your role allows; tools marked admin return a clear “requires the ADMIN role” message to other callers.
Telemetry
Section titled “Telemetry”Query your monitoring data: the same surface as the Logs and Metrics pages, tool-shaped.
| Tool | What it does |
|---|---|
logs | search logs with filters (service, level, trace id, time range, text) and cursor pagination |
get_log | fetch one complete log record by its log_id |
get_log_neighbors | the logs immediately before/after a given log, for context around a suspicious line |
spans | search spans (service, operation name, status, kind, minimum duration, trace id, time range) |
get_trace | every span of one trace, plus a summary |
aggregate_spans | request count, error rate, and latency percentiles, grouped by service or operation |
list_metrics | discover which metrics exist per service |
metrics | query one metric’s time series (with step, grouping, filters) |
correlate | one-shot pivot for a trace id: its spans, its logs, and related metric exemplars |
describe_schema | what’s queryable: fixed fields and your own dynamic attribute keys, per table |
run_sql | run a read-only QuerySQL statement |
run_sql and metrics return an explorerUrl alongside their results: a link that
opens the same query in the app, so an agent’s answer can be handed to a person.
A run_sql statement whose WHERE clause carries no lower bound on timestamp is
limited to the last 7 days. Add timestamp >= '<iso instant>' or
timestamp >= now() - INTERVAL n DAY to look further back. A statement that bounds
itself is left alone.
Dashboards
Section titled “Dashboards”Compose a dashboard from queries and get back a stable link. See Debugging for when to reach for one.
| Tool | What it does |
|---|---|
describe_dashboards | the composition guide: the definition format, the panel kinds, how to pick a chart form from the measure, grid layout, units, and what mint_dashboard validates. Call it once before composing |
mint_dashboard | validate a definition, run every panel against your live data, store it, and return the link and id. Errors block the link; warnings ship with it |
update_dashboard | replace the definition behind an existing dashboard. Same id, same link, so everyone holding it sees the new version |
get_dashboard | the stored definition, for editing and handing straight back to update_dashboard |
list_dashboards | dashboards stored for your account, newest first, with ids and links; filterable by titleContains |
delete_dashboard | remove a stored dashboard. The link stops working for everyone holding it |
mint_dashboard refuses a title that already exists, so two dashboards cannot end up
answering the same question. Links are https://app.fixter.dev/chart/<id>; the
definition lives server-side, not in the URL.
Issues
Section titled “Issues”Read tracked exceptions and their investigation briefs: the tool shape of the Issues page. See Issues for what an issue is.
| Tool | What it does |
|---|---|
list_issues | list issues, filtered by status (NEW, ONGOING, REGRESSED, RESOLVED), service, kind (EXCEPTION or LOG), or free text; sorted by EVENTS or LAST_SEEN. Each result flags whether an investigation brief exists |
get_issue | one issue by fingerprint, including its latest investigation brief (root cause, evidence, likely area) |
Issues are addressed by fingerprint, the id list_issues returns, not by a number.
Alerting
Section titled “Alerting”Author and manage alert rules: the tool shape of the Alerts pages.
| Tool | What it does |
|---|---|
describe_alerting | how Fixter alert rules work: the shapes and options, self-describing for agents |
get_alert_rules | list your alert rules |
save_alert_rule | create or update a rule (thresholds or anomaly conditions over a QuerySQL-filtered signal) |
preview_alert_rule | dry-run a rule against recent data before saving it |
set_alert_rule_status | enable or disable a rule |
delete_alert_rule | remove a rule |
suppress_signal / unsuppress_signal / list_suppressions | temporarily silence matching alerts |
create_ignore_rule / delete_ignore_rule / list_ignore_rules | permanently ignore known-noise signals |
A rule does not carry channels. Where its alerts go is set with
set_notification_destinations under Notifications, addressing either
the whole alerting source or one rule id as a subject. A check tree holds at most 20
metric checks, and the number of rules you can have active at once comes from your plan.
API tests
Section titled “API tests”Synthetic probes against your HTTP endpoints and MCP servers: the tool shape of the API Tests page.
| Tool | What it does |
|---|---|
create_api_test / update_api_test / delete_api_test | define probes, with assertions on status, latency, headers, body, or MCP handshake/tools |
list_api_tests / get_api_test | inspect configured tests |
enable_api_test / disable_api_test | pause and resume a test |
get_api_test_runs | run history with outcomes, filterable by time and status |
get_uptime | uptime percentage over a window |
create_api_test_credential / list_api_test_credentials / delete_api_test_credential | manage the credentials probes authenticate with (basic, bearer, API key, OAuth2); values are write-only and never echoed back |
A test does not carry channels either. Route the whole e2e-monitoring source, or one
test id as a subject, under Notifications.
Investigations
Section titled “Investigations”Work investigations and configure how they run. Setup changes require the admin role; reads are open to any role.
Working an investigation
Section titled “Working an investigation”| Tool | What it does |
|---|---|
list_investigations | recent investigations, newest first |
get_investigation_brief | the full transcript of one investigation, read-only |
start_investigation | claim an investigation (by id or its pick-up slug) and continue it in your editor with its complete context |
| Tool | What it does |
|---|---|
list_alert_channels | your notification channels. Each entry’s id is the UUID set_notification_destinations takes; channelId is the Slack-side id, shown for recognition only. Your email channel appears here too, named “All active users” |
add_alert_channel / remove_alert_channel (admin) | add or remove a Slack channel by its Slack channel id. Every bot-posted alert in a registered channel is investigated automatically; there is no per-alert rule to configure |
list_investigation_agent_context_credentials | which monitoring-provider credentials are configured (names only; values are never readable) |
set_investigation_datadog_credentials (admin) | store Datadog keys so investigations can run against your existing monitoring during migration |
set_investigation_cloudwatch_credentials (admin) | store AWS CloudWatch credentials, same purpose |
get_issue_digest_config / set_issue_digest_config (admin, set only) | the issue digest’s mode, schedule, timezone, and delivery channel |
Notifications
Section titled “Notifications”Where alerts, new issues, and API test state changes are delivered. See Alerts.
| Tool | What it does |
|---|---|
get_notification_destinations | which channels a source’s notifications go to. Pass subject to read one alert rule’s or one API test’s own destinations instead |
set_notification_destinations (admin) | choose those channels, by channel id from list_alert_channels. Omit channelIds to clear and fall through to the next step down; pass [] to turn notifications off entirely for whatever was addressed |
list_notification_opt_outs / clear_notification_opt_out | who has unsubscribed from a source’s emails, and putting them back on |
There are three routable sources: alerting, issues, and e2e-monitoring. Anything
else is rejected with the valid set named in the error. A subject addresses one
thing inside a source: an alert rule id (the id from get_alert_rules) or an API test
id. Delivery reads the subject row first, then the source row, then your default, which
is your email channel plus your default Slack channel. So reading a source alone will
not tell you where a routed rule’s alerts actually go.
Behavior notes
Section titled “Behavior notes”- Results are capped for agent-friendliness (long strings and large result sets are truncated); every search tool takes limits and filters for precise paging.
- Destructive setup tools (channel removal, rule deletion) act immediately.
- The channel tools were once named
list_investigation_alert_channels,add_investigation_alert_channelandremove_investigation_alert_channel. Those aliases have been removed; a script still calling them gets an unknown-tool error. Use the names above. set_alert_rule_deliveryhas been removed. Routing moved off the rule and onto the source and subject model under Notifications.- This page is hand-maintained against the current tool surface; your agent’s live tool list is always authoritative, so ask it to list its Fixter tools.