Skip to main content
Glama
WYRE-AI

gorelo-mcp

by WYRE-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

gorelo_list_invoices

Read-only

Retrieve and filter service provider invoices by status, client, contract, dates, or email status, with sorting and pagination for reporting and reconciliation.

Instructions

Lists the service provider's invoices, filtered and sorted.

Input Schema

NameRequiredDescriptionDefault
queryNoFree-text search against the invoice number, reference and name.
cursorNoOpaque pagination cursor from a previous page; omit for the first page. Only valid against the same filters and sort that produced it.
numberNoExact match on the invoice's bare sequential number (the wire's Number, not DisplayNumber). A value that does not parse as a whole number is a 400.
sortByNoSort field: createdOn (default), updatedOn, date, dueDate or totalAmount.
pageSizeNoNumber of items per page. 1-200 (default 50); out of range is a 400, never clamped.
clientIdsNoclient ids; keeps only invoices billed to any of them.
sortOrderNoSort direction: asc or desc (default).
statusIdsNostatus ids: 1 Draft, 2 Submitted, 3 Paid, 4 Void, 5 Approved. Any other id is a 400.
contractIdsNocontract ids; keeps only invoices raised from any of them.
isEmailSentNoKeeps only invoices that have (true) or have not (false) been emailed to the client.
createdSinceNoKeeps only invoices created at or after this instant.
dueDateSinceNoKeeps only invoices due at or after this date.
updatedSinceNoKeeps only invoices last updated at or after this instant.
createdBeforeNoKeeps only invoices created at or before this instant.
dueDateBeforeNoKeeps only invoices due strictly before this date.
updatedBeforeNoKeeps only invoices last updated at or before this instant.
invoiceDateSinceNoKeeps only invoices dated at or after this date.
invoiceDateBeforeNoKeeps only invoices dated strictly before this date.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.1

TDQS

C2.9/5.0
Behavior2/5

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

readOnlyHint=true already establishes this is a safe read, so the description owes context beyond that. It offers none: no statement about default result ordering, what happens with zero filters, that pageSize is rejected rather than clamped, or how the cursor is tied to filters/sort — all of which matter for an 18-parameter listing tool.

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?

A single front-loaded sentence with no filler. It is efficient, though its brevity borders on under-specification for a tool with 18 optional filters.

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?

The rich schema carries most of the burden and there is no output schema to explain, so the definition is callable as-is. Still, for a tool with three date-range families (created/due/invoiceDate) and an opaque cursor, the description could usefully flag default sort and pagination expectations.

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% and the per-parameter text is unusually thorough (status id mapping, cursor/filter coupling, 400 conditions). The description itself adds nothing about parameters, so the baseline of 3 is the correct ceiling.

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?

The description gives a specific verb and resource ("Lists the service provider's invoices") plus the two axes of variation (filtered, sorted), which is enough to separate it from gorelo_get_invoice. It stops short of naming the sibling it is not, or stating that no filters means all invoices.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all: nothing tells the agent to prefer this over gorelo_get_invoice when a specific id is known, or over other list endpoints. Filter and pagination semantics live entirely in the schema, so the description adds no routing help.

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

Deploy Server

Other Tools