finance

Support: List support tickets

list_support_tickets

Read-onlyIdempotent

    List the user's own support tickets, most recently active first.
    API docs: https://zoninga.com/ai/#support-tickets

    Closed tickets are hidden by default (they're soft-archived once
    closed). Pass a ``status`` to change that:

    Args:
        status: ``None`` (default) hides closed tickets. ``"all"`` shows
            every ticket including closed. A specific status —
            ``open``, ``in_progress``, ``resolved``, ``closed`` — filters
            to exactly that. Any other value raises a validation error.
        limit: Max tickets to return (1-100, default 20).

    Returns:
        ``{"tickets": [{id, subject, category, category_display, status,
        status_display, priority, priority_display, message_count,
        created_at, updated_at}], "count": N}``.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`status`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the bar is lower, yet the description still adds real behavior: closed tickets are soft-archived and filtered out by default, results are sorted by most recent activity, and invalid status values raise a validation error. It does not mention pagination or total-vs-returned count semantics, which is the remaining gap.

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?

Purpose and default behavior are front-loaded, and the Args/Returns structure keeps it scannable. The docstring formatting and API-docs URL add slight bulk, but every sentence conveys usable information.

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?

With no output schema, the description supplies the exact return shape (tickets array with field list plus count), covering what an agent needs to consume the result. Combined with the filtering and limit semantics, nothing essential is missing for a 2-param read tool.

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 description coverage is 0%, so the description carries the full burden and does so: it enumerates every accepted status value (None, 'all', open, in_progress, resolved, closed), states the default, describes the limit range (1-100, default 20), and warns that other values error. This is meaning well beyond the raw schema.

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 and resource ('List the user's own support tickets') plus a scope and sort order ('most recently active first'). This clearly distinguishes it from get_support_ticket, create_support_ticket, and reply_to_support_ticket without needing their schemas.

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

Usage Guidelines4/5

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

Explains the default behavior (closed tickets hidden) and the condition that changes it via an explicit status list, which is solid context for when to use which filter. It stops short of naming sibling tools or saying when to prefer get_support_ticket for a single record, but the usage context is unambiguous.

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

All finance 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?