Skip to main content
Glama

list_items

List/filter items, scoped to the caller's member companies (A1).

Optional period (YYYY-MM) filters by the item's effective date (invoice date, falling back to the Europe/Zurich-local ingestion date); a malformed value returns 422 {"msg": "period must be YYYY-MM"}. exclude_triage_status drops items carrying that triage verdict (NULL-safe; for unrelated not a booked one, ZCT-954). Payables/Receivables pass unrelated, so parked items show only in the Inbox.

Optional q is free text: a case-insensitive partial (substring) match over the filename and the counterparty name from both of its sources (the linked counterparty and the extracted data.company). %/_ are matched literally, blank is ignored, and total counts the filtered set.

duplicate filters on the row's is_duplicate flag (ZET-413); credit_note on its is_credit_note flag (ZET-429) — both server-side, so total stays exact. posted filters on the posting badge (ZCT-811): true = posted, false = held, reversed or not booked; a copy filed with the booking of the same invoice ("Already booked", posting.filed_with) is in neither (ZEN-1).

Input Schema

NameRequiredDescriptionDefault
qNo
paidNo
limitNo
offsetNo
periodNo
postedNo
sourceNo
directionNo
duplicateNo
company_idNo
credit_noteNo
triage_statusNo
archive_statusNo
counterparty_idNo
exclude_triage_statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the 422 error and message for a malformed period, NULL-safe exclusion semantics, that server-side filters keep `total` exact, and the three-valued `posted` logic including the "Already booked" exclusion. Missing only pagination/ordering behavior and what the response body contains.

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?

Front-loaded with the core purpose, then organized one filter per paragraph. Dense but nearly every sentence carries semantics; internal ticket references (ZCT-954, ZET-413, ZEN-1) are noise that could be dropped.

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

Completeness3/5

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

For a 15-parameter, unannotated, output-schema-less list tool, the description explains the trickiest filters but leaves many parameters and the returned item shape undefined. An agent can call it, but not confidently for the undocumented filters.

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 coverage is 0% across 15 parameters, but the description adds real meaning for roughly six of them (`period`, `exclude_triage_status`, `q`, `duplicate`, `credit_note`, `posted`), including substring/wildcard handling. `paid`, `source`, `direction`, `archive_status`, `company_id`, `counterparty_id`, `triage_status`, `limit` and `offset` remain undocumented in both places, which is a large uncompensated gap.

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

Purpose4/5

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

Opens with a specific verb+resource ("List/filter items") and states the access scope (caller's member companies). It never distinguishes itself from nearby siblings such as get_item, list_ar_invoices or global_search, so an agent must infer which listing tool applies.

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?

Usage is implied through filter narratives ("Payables/Receivables pass unrelated, so parked items show only in the Inbox"), which hints at how the tool is used in practice. There is no explicit when-to-use / when-not-to-use statement or named alternative for retrieving a single item vs a filtered list.

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.

Resources