Fixter

List Issues

list_issues

Read-onlyIdempotent

List the issues and problems Fixter has already detected in the caller's telemetry. An issue groups every occurrence of one exception, one recurring error log line or one service that stopped reporting, with its service, environments, status, event count, firstSeen, lastSeen and impact; a problem (kind=PROBLEM) is an item of the Overview: an alert rule, an error, or a group of them that share one cause. Call this first when investigating something failing: an error, a broken feature or job, a service that will not start, a deploy's health, or before searching logs for an error message or log tag. query is a case-insensitive substring of the title, error type, service and frames, so query="PaymentSync" finds the issues titled "[PaymentSync] ...". Then call get_issue on a fingerprint for its frames, traceId and investigation, and search logs with what it gives you. To see what a deploy introduced: service set, sort=FIRST_SEEN, direction=desc, and compare firstSeen with the deploy time. Filter by status (NEW, ONGOING, REGRESSED, RESOLVED, IGNORED), service, environment, kind (EXCEPTION for thrown errors and agent failures, LOG for issues derived from log lines, AVAILABILITY for a service that stopped reporting, PROBLEM for the Overview's problems), or a free-text query; sort by EVENTS, LAST_SEEN or FIRST_SEEN, ascending or descending. To answer what is new, call this with status=NEW, or with sort=LAST_SEEN and direction=desc. To answer what has been broken longest, call it with sort=FIRST_SEEN, direction=asc and an open status, ONGOING or REGRESSED: without a status the oldest issue that comes back is usually one somebody already resolved, which is not a problem to report. The default list leaves out ignored issues and issues a suppression rule matches: pass status=IGNORED to see the ignored ones, includeSuppressed=true to see the suppressed ones alongside the rest, and suppressedByRuleOnly=true to see nothing but the rule-suppressed ones, where suppressedBy names the rule that hides each, and suppressedOnly=true to see both kinds of suppression in one list, the ignored issues together with the rule-hidden ones. Each result flags whether a telemetry investigation brief exists (hasInvestigation) and whether a draft pull request attempt exists (hasFix); call get_issue to read either. Each result carries impact: how many callers got an error on which flows in the last 24 hours and 7 days; sort=CALLERS orders by that; impact is not computed for a problem. With kind=PROBLEM each problem also carries priority (level URGENT, HIGH, MEDIUM or LOW, shown as Urgent, High, Medium, Low; manual when a person set it; and the reason that decided it) and recommendation (the next step: kind and reason; the kinds as the Overview shows them are FIX "Fix available", REVIEW_FIX "Review fix", FIX_MERGED "Fix merged", FIX_RUNNING "Fix running", CHANGE_BY_HAND "Change by hand", TUNE_ALERT "Tune alert", IGNORE_AS_NOISE "Noise", INVESTIGATE "Investigate", RESOLVE "Resolve", NEEDS_INPUT "Needs input"), problems come in triage order (priority, then the most recently opened first), and priority and recommendation filter the list: priority=URGENT,HIGH lists only those levels, recommendation=FIX lists only the problems recommended for a fix.

Input Schema

Name	Required	Description
`kind`	No	EXCEPTION, LOG, AVAILABILITY or PROBLEM (default: every kind but PROBLEM, the Overview's problems)
`sort`	No	EVENTS, LAST_SEEN, FIRST_SEEN or CALLERS (default LAST_SEEN). CALLERS orders by how many callers the issue hit in the last 7 days. FIRST_SEEN orders by when the issue was first seen, so with direction=asc it starts at the oldest issue the account still has. With kind=PROBLEM only (refused for every other kind): PRIORITY (the default for problems; desc is triage order, asc the reverse), TITLE (A to Z with asc, case-insensitive), SIGNALS (the problem's eventCount: alert firings plus error occurrences; a problem with neither counts its investigations) or STATUS (NEW, REGRESSED, ONGOING, RESOLVED, IGNORED with asc)
`limit`	No	Max results, 1..100 (default 25)
`query`	No	Case-insensitive substring of the title, error type, service or frames: a feature, component, log tag or error text
`status`	No	NEW, ONGOING, REGRESSED, RESOLVED or IGNORED
`service`	No	Service name to filter by, or several comma-separated (checkout,billing) to match any of them
`priority`	No	With kind=PROBLEM only: URGENT, HIGH, MEDIUM or LOW, or several comma-separated (URGENT,HIGH), to list only problems at those priorities. Refused for every other kind
`direction`	No	asc or desc (default desc). To find the issues that have been around longest: call list_issues with sort=FIRST_SEEN and direction=asc, then read firstSeen on each result. To find the rarest ones: sort=EVENTS with direction=asc
`minMembers`	No	With kind=PROBLEM only: the fewest members (investigations, alerts and issues) a problem needs to be listed (default 2, so a problem with a single member is left out; pass 1 to list every problem). Ignored for every other kind
`environment`	No	Deployment environment to filter by, e.g. production, or several comma-separated (production,staging) to match any of them. Omit this argument for no filter; on this surface an empty string is also treated as no filter, not as the unknown environment
`recommendation`	No	With kind=PROBLEM only: one or more comma-separated recommendation kinds (NEEDS_INPUT, FIX_RUNNING, REVIEW_FIX, FIX_MERGED, FIX, TUNE_ALERT, CHANGE_BY_HAND, INVESTIGATE, RESOLVE, IGNORE_AS_NOISE, NONE) to list only problems recommended for them. Refused for every other kind
`suppressedOnly`	No	true to list everything the account has suppressed: the issues a person suppressed (IGNORED) and the issues a suppression rule hides, in one list (default false), so it is a superset of suppressedByRuleOnly. To review what the account is no longer looking at: call list_issues with suppressedOnly=true, read status on each result, where IGNORED means a person suppressed that issue and suppressedBy names the rule that hides the rest, then call set_issue_status to bring a suppressed issue back, or list_suppression_rules and manage_suppression_rule with action=delete for a rule that hides more than the person wants. This argument wins over status, includeSuppressed and suppressedByRuleOnly when they are combined
`includeSuppressed`	No	true to include issues a suppression rule matches (default false)
`suppressedByRuleOnly`	No	true to list only the issues a suppression rule currently hides (default false), which is the rule-hidden part of suppressedOnly and never the ignored ones. To audit what the account is silencing: call list_issues with suppressedByRuleOnly=true, read suppressedBy.ruleId on each result for the rule and suppressedBy.expression for the conditions it matched on, then call list_suppression_rules to name those rules, and manage_suppression_rule with action=delete or action=update for any that hide more than the person wants. This argument answers from the rules alone, so status and includeSuppressed are ignored when it is true

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / sort / description

Previous value: -"EVENTS, LAST_SEEN, FIRST_SEEN or CALLERS (default LAST_SEEN). CALLERS orders by how many callers the issue hit in the last 7 days. FIRST_SEEN orders by when the issue was first seen, so with direction=asc it starts at the oldest issue the account still has. With kind=PROBLEM only (refused for every other kind): PRIORITY (the default for problems; desc is triage order, asc the reverse), TITLE (A to Z with asc, case-insensitive), SIGNALS (member count: investigations, alerts and issues) or STATUS (NEW, REGRESSED, ONGOING, RESOLVED, IGNORED with asc)"New value: +"EVENTS, LAST_SEEN, FIRST_SEEN or CALLERS (default LAST_SEEN). CALLERS orders by how many callers the issue hit in the last 7 days. FIRST_SEEN orders by when the issue was first seen, so with direction=asc it starts at the oldest issue the account still has. With kind=PROBLEM only (refused for every other kind): PRIORITY (the default for problems; desc is triage order, asc the reverse), TITLE (A to Z with asc, case-insensitive), SIGNALS (the problem's eventCount: alert firings plus error occurrences; a problem with neither counts its investigations) or STATUS (NEW, REGRESSED, ONGOING, RESOLVED, IGNORED with asc)"

Changed6 schema fields changedOct 22, 2026

changedInput schema / properties / environment / description

Previous value: -"Deployment environment to filter by, e.g. production. Omit this argument for no filter; on this surface an empty string is also treated as no filter, not as the unknown environment"New value: +"Deployment environment to filter by, e.g. production, or several comma-separated (production,staging) to match any of them. Omit this argument for no filter; on this surface an empty string is also treated as no filter, not as the unknown environment"

changedInput schema / properties / kind / description

Previous value: -"EXCEPTION, LOG or AVAILABILITY (default: all)"New value: +"EXCEPTION, LOG, AVAILABILITY or PROBLEM (default: every kind but PROBLEM, the Overview's problems)"

changedInput schema / properties / minMembers / description

Previous value: -"With kind=PROBLEM only: the fewest member signals a problem needs to be listed (default 2, so a problem with a single member is left out; pass 1 to list every problem). Ignored for every other kind"New value: +"With kind=PROBLEM only: the fewest members (investigations, alerts and issues) a problem needs to be listed (default 2, so a problem with a single member is left out; pass 1 to list every problem). Ignored for every other kind"

changedInput schema / properties / recommendation / description

Previous value: -"With kind=PROBLEM only: one or more comma-separated recommendation kinds (NEEDS_INPUT, FIX_RUNNING, REVIEW_FIX, FIX, TUNE_ALERT, CHANGE_BY_HAND, INVESTIGATE, RESOLVE, IGNORE_AS_NOISE, NONE) to list only problems recommended for them. Refused for every other kind"New value: +"With kind=PROBLEM only: one or more comma-separated recommendation kinds (NEEDS_INPUT, FIX_RUNNING, REVIEW_FIX, FIX_MERGED, FIX, TUNE_ALERT, CHANGE_BY_HAND, INVESTIGATE, RESOLVE, IGNORE_AS_NOISE, NONE) to list only problems recommended for them. Refused for every other kind"

changedInput schema / properties / service / description

Previous value: -"Service name to filter by"New value: +"Service name to filter by, or several comma-separated (checkout,billing) to match any of them"

changedInput schema / properties / sort / description

Previous value: -"EVENTS, LAST_SEEN, FIRST_SEEN or CALLERS (default LAST_SEEN). CALLERS orders by how many callers the issue hit in the last 7 days. FIRST_SEEN orders by when the issue was first seen, so with direction=asc it starts at the oldest issue the account still has. With kind=PROBLEM only (refused for every other kind): PRIORITY (the default for problems; desc is triage order, asc the reverse), TITLE (A to Z with asc, case-insensitive), SIGNALS (member signal count) or STATUS (NEW, REGRESSED, ONGOING, RESOLVED, IGNORED with asc)"New value: +"EVENTS, LAST_SEEN, FIRST_SEEN or CALLERS (default LAST_SEEN). CALLERS orders by how many callers the issue hit in the last 7 days. FIRST_SEEN orders by when the issue was first seen, so with direction=asc it starts at the oldest issue the account still has. With kind=PROBLEM only (refused for every other kind): PRIORITY (the default for problems; desc is triage order, asc the reverse), TITLE (A to Z with asc, case-insensitive), SIGNALS (member count: investigations, alerts and issues) or STATUS (NEW, REGRESSED, ONGOING, RESOLVED, IGNORED with asc)"

Changed4 schema fields changedOct 20, 2026

addedInput schema / properties / minMembers

Added value: +{
+  "description": "With kind=PROBLEM only: the fewest member signals a problem needs to be listed (default 2, so a problem with a single member is left out; pass 1 to list every problem). Ignored for every other kind",
+  "format": "int32",
+  "type": "integer"
+}

addedInput schema / properties / priority

Added value: +{
+  "description": "With kind=PROBLEM only: URGENT, HIGH, MEDIUM or LOW, or several comma-separated (URGENT,HIGH), to list only problems at those priorities. Refused for every other kind",
+  "type": "string"
+}

addedInput schema / properties / recommendation

Added value: +{
+  "description": "With kind=PROBLEM only: one or more comma-separated recommendation kinds (NEEDS_INPUT, FIX_RUNNING, REVIEW_FIX, FIX, TUNE_ALERT, CHANGE_BY_HAND, INVESTIGATE, RESOLVE, IGNORE_AS_NOISE, NONE) to list only problems recommended for them. Refused for every other kind",
+  "type": "string"
+}

changedInput schema / properties / sort / description

Previous value: -"EVENTS, LAST_SEEN, FIRST_SEEN or CALLERS (default LAST_SEEN). CALLERS orders by how many callers the issue hit in the last 7 days. FIRST_SEEN orders by when the issue was first seen, so with direction=asc it starts at the oldest issue the account still has"New value: +"EVENTS, LAST_SEEN, FIRST_SEEN or CALLERS (default LAST_SEEN). CALLERS orders by how many callers the issue hit in the last 7 days. FIRST_SEEN orders by when the issue was first seen, so with direction=asc it starts at the oldest issue the account still has. With kind=PROBLEM only (refused for every other kind): PRIORITY (the default for problems; desc is triage order, asc the reverse), TITLE (A to Z with asc, case-insensitive), SIGNALS (member signal count) or STATUS (NEW, REGRESSED, ONGOING, RESOLVED, IGNORED with asc)"

Changed3 schema fields changedOct 16, 2026
- addedInput schema / $schema
```
Added value: +"https://json-schema.org/draft/2020-12/schema"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / limit / format
```
Added value: +"int32"
```

Changed1 schema field changedOct 9, 2026

changedInput schema / properties / query / description

Previous value: -"Free-text match on title/type/service/frame"New value: +"Case-insensitive substring of the title, error type, service or frames: a feature, component, log tag or error text"

Changed1 schema field changedSep 29, 2026

changedInput schema / properties / kind / description

Previous value: -"EXCEPTION or LOG (default: both)"New value: +"EXCEPTION, LOG or AVAILABILITY (default: all)"

AddedSep 23, 2026
RemovedSep 23, 2026
AddedSep 22, 2026
RemovedSep 22, 2026
AddedSep 19, 2026
RemovedSep 19, 2026
AddedSep 17, 2026
RemovedSep 17, 2026

Changed3 schema fields changedSep 17, 2026

changedInput schema / properties / sort / description

Previous value: -"EVENTS, LAST_SEEN or FIRST_SEEN (default LAST_SEEN). FIRST_SEEN orders by when the issue was first seen, so with direction=asc it starts at the oldest issue the account still has"New value: +"EVENTS, LAST_SEEN, FIRST_SEEN or CALLERS (default LAST_SEEN). CALLERS orders by how many callers the issue hit in the last 7 days. FIRST_SEEN orders by when the issue was first seen, so with direction=asc it starts at the oldest issue the account still has"

changedInput schema / properties / suppressedByRuleOnly / description

Previous value: -"true to list only the issues a suppression rule currently hides (default false), which is the rule-hidden part of suppressedOnly and never the ignored ones. To audit what the account is silencing: call list_issues with suppressedByRuleOnly=true, read suppressedBy.ruleId on each result for the rule and suppressedBy.expression for the conditions it matched on, then call list_suppression_rules to name those rules, and delete_suppression_rule or update_suppression_rule for any that hide more than the person wants. This argument answers from the rules alone, so status and includeSuppressed are ignored when it is true"New value: +"true to list only the issues a suppression rule currently hides (default false), which is the rule-hidden part of suppressedOnly and never the ignored ones. To audit what the account is silencing: call list_issues with suppressedByRuleOnly=true, read suppressedBy.ruleId on each result for the rule and suppressedBy.expression for the conditions it matched on, then call list_suppression_rules to name those rules, and manage_suppression_rule with action=delete or action=update for any that hide more than the person wants. This argument answers from the rules alone, so status and includeSuppressed are ignored when it is true"

changedInput schema / properties / suppressedOnly / description

Previous value: -"true to list everything the account has suppressed: the issues a person suppressed (IGNORED) and the issues a suppression rule hides, in one list (default false), so it is a superset of suppressedByRuleOnly. To review what the account is no longer looking at: call list_issues with suppressedOnly=true, read status on each result, where IGNORED means a person suppressed that issue and suppressedBy names the rule that hides the rest, then call set_issue_status to bring a suppressed issue back, or list_suppression_rules and delete_suppression_rule for a rule that hides more than the person wants. This argument wins over status, includeSuppressed and suppressedByRuleOnly when they are combined"New value: +"true to list everything the account has suppressed: the issues a person suppressed (IGNORED) and the issues a suppression rule hides, in one list (default false), so it is a superset of suppressedByRuleOnly. To review what the account is no longer looking at: call list_issues with suppressedOnly=true, read status on each result, where IGNORED means a person suppressed that issue and suppressedBy names the rule that hides the rest, then call set_issue_status to bring a suppressed issue back, or list_suppression_rules and manage_suppression_rule with action=delete for a rule that hides more than the person wants. This argument wins over status, includeSuppressed and suppressedByRuleOnly when they are combined"

AddedSep 16, 2026
RemovedSep 16, 2026

Changed5 schema fields changedSep 14, 2026

addedInput schema / properties / direction

Added value: +{
+  "description": "asc or desc (default desc). To find the issues that have been around longest: call list_issues with sort=FIRST_SEEN and direction=asc, then read firstSeen on each result. To find the rarest ones: sort=EVENTS with direction=asc",
+  "type": "string"
+}

removedInput schema / properties / dismissedOnly

Removed value: -{
-  "description": "true to list everything the account has dismissed: the issues a person ignored and the issues a suppression rule hides, in one list (default false). To review what the account is no longer looking at: call list_issues with dismissedOnly=true, read status on each result, where IGNORED means a person silenced that issue and suppressedBy names the rule that hides the rest, then call set_issue_status to bring an ignored issue back, or list_suppression_rules and delete_suppression_rule for a rule that hides more than the person wants. This argument wins over status, includeSuppressed and suppressedOnly when they are combined",
-  "type": "boolean"
-}

changedInput schema / properties / sort / description

Previous value: -"EVENTS or LAST_SEEN (default LAST_SEEN)"New value: +"EVENTS, LAST_SEEN or FIRST_SEEN (default LAST_SEEN). FIRST_SEEN orders by when the issue was first seen, so with direction=asc it starts at the oldest issue the account still has"

addedInput schema / properties / suppressedByRuleOnly

Added value: +{
+  "description": "true to list only the issues a suppression rule currently hides (default false), which is the rule-hidden part of suppressedOnly and never the ignored ones. To audit what the account is silencing: call list_issues with suppressedByRuleOnly=true, read suppressedBy.ruleId on each result for the rule and suppressedBy.expression for the conditions it matched on, then call list_suppression_rules to name those rules, and delete_suppression_rule or update_suppression_rule for any that hide more than the person wants. This argument answers from the rules alone, so status and includeSuppressed are ignored when it is true",
+  "type": "boolean"
+}

changedInput schema / properties / suppressedOnly / description

Previous value: -"true to list only the issues a suppression rule currently hides (default false). To audit what the account is silencing: call list_issues with suppressedOnly=true, read suppressedBy on each result for the rule id, then call list_suppression_rules to name those rules, and delete_suppression_rule or update_suppression_rule for any that hide more than the person wants. This argument answers from the rules alone, so status and includeSuppressed are ignored when it is true"New value: +"true to list everything the account has suppressed: the issues a person suppressed (IGNORED) and the issues a suppression rule hides, in one list (default false), so it is a superset of suppressedByRuleOnly. To review what the account is no longer looking at: call list_issues with suppressedOnly=true, read status on each result, where IGNORED means a person suppressed that issue and suppressedBy names the rule that hides the rest, then call set_issue_status to bring a suppressed issue back, or list_suppression_rules and delete_suppression_rule for a rule that hides more than the person wants. This argument wins over status, includeSuppressed and suppressedByRuleOnly when they are combined"

Changed4 schema fields changedSep 12, 2026

addedInput schema / properties / dismissedOnly

Added value: +{
+  "description": "true to list everything the account has dismissed: the issues a person ignored and the issues a suppression rule hides, in one list (default false). To review what the account is no longer looking at: call list_issues with dismissedOnly=true, read status on each result, where IGNORED means a person silenced that issue and suppressedBy names the rule that hides the rest, then call set_issue_status to bring an ignored issue back, or list_suppression_rules and delete_suppression_rule for a rule that hides more than the person wants. This argument wins over status, includeSuppressed and suppressedOnly when they are combined",
+  "type": "boolean"
+}

addedInput schema / properties / includeSuppressed

Added value: +{
+  "description": "true to include issues a suppression rule matches (default false)",
+  "type": "boolean"
+}

changedInput schema / properties / status / description

Previous value: -"NEW, ONGOING, REGRESSED or RESOLVED"New value: +"NEW, ONGOING, REGRESSED, RESOLVED or IGNORED"

addedInput schema / properties / suppressedOnly

Added value: +{
+  "description": "true to list only the issues a suppression rule currently hides (default false). To audit what the account is silencing: call list_issues with suppressedOnly=true, read suppressedBy on each result for the rule id, then call list_suppression_rules to name those rules, and delete_suppression_rule or update_suppression_rule for any that hide more than the person wants. This argument answers from the rules alone, so status and includeSuppressed are ignored when it is true",
+  "type": "boolean"
+}

Changed1 schema field changedSep 7, 2026

addedInput schema / properties / environment

Added value: +{
+  "description": "Deployment environment to filter by, e.g. production. Omit this argument for no filter; on this surface an empty string is also treated as no filter, not as the unknown environment",
+  "type": "string"
+}

AddedAug 12, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description adds substantial behavioral context beyond them: the default list omits ignored and suppression-rule-matched issues, how suppressedByRuleOnly answers from the rules alone, that impact is not computed for problems, that PRIORITY sort is refused for non-PROBLEM kinds, and that suppressedOnly wins over other suppression args when combined. These are real operational traits an agent would otherwise miss.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with purpose and when-to-use followed by filter/next-step guidance, and most sentences carry distinct decision value. It is, however, a dense prose block for a 14-parameter tool; some suppression-argument explanation is verbose and would read better as bullets, so not a perfect 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 14 optional parameters, no output schema, and high complexity, the description supplies everything needed to call it correctly: valid kinds, sort/direction interplay, suppression precedence, priority/recommendation filtering, and what each result carries (hasInvestigation, hasFix, impact, priority/recommendation). No material gap remains for an agent to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description still adds meaning beyond it: it explains that query matches frames as well as title/type/service, that sort=FIRST_SEEN+direction=asc starts at the oldest issue still present, that CALLERS orders by 7-day caller impact, and documents filter-value consequences (e.g. priority=URGENT,HIGH, recommendation=FIX) plus argument precedence. This goes well past the schema's enum lists.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource ('List the issues and problems Fixter has already detected in the caller's telemetry') and then clearly distinguishes an issue from a problem (kind=PROBLEM). It names what each issue groups and carries, so an agent can tell list_issues apart from get_issue, search logs, or list_investigations without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to call this first (investigating an error, broken feature/job, service that won't start, deploy health) and prescribes the next step (get_issue on a fingerprint, then search logs). It also names concrete filter combinations for specific questions (status=NEW for new, sort=FIRST_SEEN/direction=asc plus open status for the longest-broken), which is explicit when-and-how guidance with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Fixter tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?