Skip to main content
Glama

List review items

list_review_items
Read-onlyIdempotent

Lists the findings that may need a human: chart postings flagged for attention, endpoints nobody has identified, opening balances not yet verified against the live ledger, party conflicts to declare, and submitted source-assessment discrepancies. Each item has a level. request: the books are incomplete or provisional until what it asks arrives (a posting the chart refused, an opening balance, the statement that paid a card, a discrepancy to acknowledge, a party conflict to declare). notice: the books are complete and the finding is worth a glance (a posting to confirm, an unnamed endpoint). Requests are listed first and counted in requests, notices in notices. Each item's ref (R-0033, N-0088) is the number the viewer prints, kept for good. A chart_exception is not a review item: it stops a chart, is returned by the tool that meets it and shows on list_charts. Source reviews clear only through a submitted source_assessment acknowledgment with the exact finding and an accountable reason; acknowledgment changes no posting and does not repair the source. The queue is derived from the workspace's current state on every call, and workspace_overview's open_review_items equals its length. Attention items clear through resolve_review_items (dismiss) or when the chart judges the event again; the other kinds clear when the fact they name lands (a declaration registered and submitted, a statement submitted), and each item's suggested_action says how. An opening reminder clears only when at least one active chart binds the account, and only when in each chart that binds it the account is bound to exactly one chart account (an asset, or a liability for a card or loan) that binds nothing else, and the entries on it dated before the first statement period sum to the printed opening balance in the account's currency (a declared entry in its account's; nothing converted). An empty result means no finding is visible, not assurance that the books are correct. Read-only and not metered.

Input Schema

NameRequiredDescriptionDefault
workspace_tagYesActive workspace id (the workspace_tag create_workspace and list_workspaces return).

Output Schema

NameRequiredDescriptionDefault
engineYesStamped engine build/version identity for the tool result.
statusYesreview_items_listed on success.
noticesYesItems at level notice.
requestsYesItems at level request; listed first.
resourcesNoWorkspace resource links.
row_countYesNumber of review items.
review_itemsYesDerived findings with a closed shape for each kind.
workspace_tagYesWorkspace scoped by the tool call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial non-obvious behavior: the queue is re-derived from workspace state on every call, its length equals workspace_overview's open_review_items, requests sort and count ahead of notices, refs are stable identifiers, and acknowledgment 'changes no posting and does not repair the source'. The explicit clearing semantics per item kind are exactly the kind of context annotations cannot carry.

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?

Purpose and ordering are front-loaded well, but the body is one dense block of run-on clauses, and the extended opening-reminder clearing predicate (chart binding, single-chart-account binding, pre-statement-period entry sums, currency rules) is heavy detail for a list call. Most sentences are load-bearing, but the lack of paragraphing makes a very long definition harder to scan than it needs to be.

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?

An output schema exists, so return shape need not be described, and the description nonetheless covers derivation of the queue, ordering, stable refs, meaning of an empty result, and the full clearing path for every item kind. Nothing an agent needs in order to call this correctly and interpret the result is missing.

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?

There is a single parameter with 100% schema description coverage ('Active workspace id (the workspace_tag create_workspace and list_workspaces return)'), so the schema already does the work. The description contributes nothing about workspace_tag, so baseline 3 applies.

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 ('Lists the findings that may need a human') and then enumerates the concrete categories of item. It explicitly carves out what is NOT a review item ('A chart_exception is not a review item... shows on list_charts'), which lets an agent separate this from list_charts and the chart tools without opening a 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?

Names the alternatives and the conditions that select them: attention items clear via resolve_review_items (dismiss), source reviews clear only through a submitted source_assessment acknowledgment, opening reminders only when a chart binds the account under stated conditions. It also warns that an empty result means no visible finding, not correct books, which directly shapes how an agent should follow up.

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