Red by Big Red Cloud

List Cash Receipts

brc_list_cash_receipts

Read-only

Lists BRC cash receipts. entryDate is the accounting period date; procDate is the transaction/processing date. Customer and procDate filters use a complete bounded local scan (10,000 records), not upstream OData; narrow entryDate when needed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "companyName": "<companyName>"
    },
    "name": "brc_list_cash_receipts"
  }
}

Input Schema

Name	Required	Description
`top`	No
`page`	No
`skip`	No
`filter`	No	Optional OData $filter using entryDate only. Other fields are unsupported.
`orderBy`	No	Optional OData $orderby expression, only if this endpoint supports ordering.
`pageSize`	No
`customerId`	No
`procDateTo`	No	Inclusive transaction date YYYY-MM-DD; local filtering.
`companyName`	Yes	Company context name, for example YOUR-COMPANY-NAME.
`customerCode`	No	Exact case-sensitive code; bounded local filtering, no fuzzy match.
`procDateFrom`	No	Inclusive transaction date YYYY-MM-DD; local filtering.
`connectionRef`	No	Opaque Red connection reference returned by brc_confirm_company_connection. Pass this exact value on every later tool call when the MCP client rotates session ids (for example Vibe/Mistral). Keep reusing the same connectionRef after successful tool calls — do not start a new connection because a lookup returned empty or partial data. It is not an API key and does not contain credentials.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 21, 2026

addedInput schema / properties / customerCode

Added value: +{
+  "description": "Exact case-sensitive code; bounded local filtering, no fuzzy match.",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / customerId

Added value: +{
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

addedInput schema / properties / procDateFrom

Added value: +{
+  "description": "Inclusive transaction date YYYY-MM-DD; local filtering.",
+  "type": "string"
+}

addedInput schema / properties / procDateTo

Added value: +{
+  "description": "Inclusive transaction date YYYY-MM-DD; local filtering.",
+  "type": "string"
+}

Changed1 schema field changedOct 12, 2026

changedInput schema / properties / filter / description

Previous value: -"Optional OData $filter expression, only if this endpoint supports filtering."New value: +"Optional OData $filter using entryDate only. Other fields are unsupported."

First observedJul 30, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare read-only, non-destructive, closed-world behavior. The description adds valuable behavioral context beyond annotations: customer and procDate filters perform a bounded local scan of 10,000 records rather than upstream OData filtering, which affects query strategy.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose, then adds date semantics and a practical scan-limit warning in three tight sentences. No filler or redundant restatement of the title.

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?

Adequate for a read-only list tool whose annotations cover safety, and the filter-scan limitation is useful. But with no output schema, the description does not explain return shape or pagination behavior, which leaves some gap for a 12-parameter listing endpoint.

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?

The description adds meaning to entryDate and procDate by distinguishing accounting period date from transaction/processing date, and it explains that customer/procDate filtering is local. However, with 12 parameters and 58% schema coverage, it does not cover pagination, ordering, customerId, customerCode, or connectionRef semantics beyond what the schema already provides.

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?

States a specific verb and resource: "Lists BRC cash receipts." It is clear enough to distinguish from create/update/delete/get siblings by name, but it does not explicitly differentiate itself from brc_list_cash_payments or explain its distinct scope beyond the resource name.

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?

Gives implied usage guidance through date-field semantics and the instruction to "narrow entryDate when needed," but does not explicitly state when to use this tool versus brc_list_cash_payments, brc_get_cash_receipt, or the batch cash receipt tool.

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

All Red by Big Red Cloud 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.