Fixter

list_issues

List production issues for the caller's account. 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), 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); call get_issue to read it. 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.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	No	EXCEPTION, LOG or AVAILABILITY (default: all)
`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
`limit`	No	Max results, 1..100 (default 25)
`query`	No	Free-text match on title/type/service/frame
`status`	No	NEW, ONGOING, REGRESSED, RESOLVED or IGNORED
`service`	No	Service name to filter by
`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
`environment`	No	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
`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 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.7/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: it discloses that the default list excludes ignored and rule-suppressed issues, explains each suppression flag and their precedence (suppressedOnly wins over others), notes that each result flags hasInvestigation and carries impact metrics, and describes the CALLERS sort. No contradictions are present.

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

Conciseness3/5

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

The description is front-loaded with purpose but runs long and dense, often repeating parameter details already present in the schema (e.g., suppression flag semantics). It could be structured more crisply with bullets or separate sections, and several clauses duplicate schema text, reducing conciseness.

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?

No output schema exists, so the description must explain return values; it does so by naming key result fields (hasInvestigation, impact, suppressedBy, firstSeen, status) and indicating next steps like calling get_issue. Combined with its filter/sort guidance, it is complete enough for an agent to call the tool correctly and interpret results.

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

Parameters4/5

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

Schema description coverage is 100%, and the schema already contains detailed parameter guidance (e.g., precedence for suppressedOnly, environment semantics). The description adds value by clarifying the default list behavior (excludes ignored and suppressed) and offering concrete combinations for common questions, but much of the parameter-level detail is already in the schema, so it goes beyond baseline 3 but is not wholly additive.

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?

States a specific verb ('List') and resource ('production issues for the caller's account') and immediately scopes the operation with filters and sorts. It also distinguishes itself from get_issue by noting that get_issue reads the investigation brief, so an agent can separate the two without opening schemas.

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?

Explicitly answers common analytical questions: what is new (status=NEW or sort=LAST_SEEN+desc), what has been broken longest (sort=FIRST_SEEN+asc+open status), and warns that without a status the oldest issue may already be resolved. It also routes to alternatives like get_issue, set_issue_status, list_suppression_rules, and manage_suppression_rule for follow-up actions.

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?