Skip to main content
Glama

list_reports

Read-only

List the user's expense reports with pagination. Filter by status (All, Draft, Submitted, Shared). Each exact report includes its app, Bill Client, and accounting handoff URLs. Use the matching accounting URL only when the user explicitly asks to send or export that report; the app keeps organization, mapping, preview, and final confirmation.

Input Schema

NameRequiredDescriptionDefault
pageNoOne-based results page to return.
limitNoMaximum reports to return on this page.
filterNoOptional report-status filter; All returns every authorized status.All
clientEmailNoAccepted client's account email (accountants only).

Output Schema

NameRequiredDescriptionDefault
pageNo
limitNo
filterNo
reportsNoPresent when the user has reports.
successYes
creationStatusYesProvenance of the listing, e.g. "existing_only".
responseGuidanceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / clientEmail / description
      Previous value: -"Client account email. Accountants may use this only for an accepted ExpenseBot client."New value: +"Accepted client's account email (accountants only)."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "creationStatus": {
      +      "description": "Provenance of the listing, e.g. \"existing_only\".",
      +      "type": "string"
      +    },
      +    "filter": {
      +      "type": "string"
      +    },
      +    "limit": {
      +      "type": "integer"
      +    },
      +    "page": {
      +      "type": "integer"
      +    },
      +    "reports": {
      +      "description": "Present when the user has reports.",
      +      "items": {
      +        "additionalProperties": true,
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "responseGuidance": {
      +      "type": "string"
      +    },
      +    "success": {
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "success",
      +    "creationStatus"
      +  ],
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "description": "Standard ExpenseBot tool result envelope. `message` is the human-readable summary the AI cites; `data` is the structured payload (totals, breakdowns, ids, etc.). On failure, `success` is false and `error` carries a code/message/hint triple.",
      -  "properties": {
      -    "data": {
      -      "additionalProperties": true,
      -      "description": "Structured payload. Shape varies per tool — common keys: total, breakdown, comparison, sampleMeta, ids, expenseId, reportId, signupUrl, results.",
      -      "type": "object"
      -    },
      -    "error": {
      -      "additionalProperties": true,
      -      "description": "Present only when success === false.",
      -      "properties": {
      -        "code": {
      -          "type": "string"
      -        },
      -        "hint": {
      -          "type": "string"
      -        },
      -        "message": {
      -          "type": "string"
      -        }
      -      },
      -      "type": "object"
      -    },
      -    "message": {
      -      "description": "Human-readable result text. Always present on success; prefer rendering this verbatim before any further reasoning.",
      -      "type": "string"
      -    },
      -    "sampleMeta": {
      -      "additionalProperties": true,
      -      "description": "Set when the underlying dataset was truncated. isTruncated=true means the agent saw a sample of `sampleCount` of `totalCount` rows; aggregate totals are still accurate.",
      -      "properties": {
      -        "isTruncated": {
      -          "type": "boolean"
      -        },
      -        "sampleCount": {
      -          "type": "integer"
      -        },
      -        "totalCount": {
      -          "type": "integer"
      -        }
      -      },
      -      "type": "object"
      -    },
      -    "success": {
      -      "description": "False on tool errors; check before reading `data`.",
      -      "type": "boolean"
      -    }
      -  },
      -  "type": "object"
      -}New value: +null
  4. Changed3 schema fields changed
    • addedInput schema / properties / filter / description
      Added value: +"Optional report-status filter; All returns every authorized status."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum reports to return on this page."
    • addedInput schema / properties / page / description
      Added value: +"One-based results page to return."
  5. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish this as a read-only, non-destructive, closed-world operation. The description adds valuable context about pagination, returned report contents, and a caution around when to use the accounting handoff URL, though it does not describe pagination limits or authorization behavior in detail.

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?

The definition is front-loaded with purpose and filter behavior, then moves to return contents and a usage constraint. It is efficient overall, though the 'Each exact report...' sentence could be tighter.

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 an output schema, full annotation coverage, and 100% schema description coverage, the description provides enough context for correct invocation. It covers purpose, pagination, filtering, return content, and the key caution around accounting URLs.

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

Parameters3/5

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

Schema description coverage is 100%, so page, limit, filter, and clientEmail are already documented in the schema. The description mentions pagination and status filtering but adds no syntax or semantics beyond the schema descriptions and enum values.

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 description opens with a specific verb and resource: 'List the user's expense reports with pagination.' It clearly identifies the resource as expense reports, distinguishing it from sibling tools like list_client_invoices or list_tags.

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

Usage Guidelines3/5

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

It provides useful guidance on the returned accounting URL ('use only when the user explicitly asks to send or export'), but it does not explain when to choose list_reports over alternatives such as search_expenses or get_report_details. The filtering behavior is stated, but tool-selection guidance is only implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.