Skip to main content
Glama
myradostudio

checkbox-mcp

by myradostudio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Search receipts

search_receipts
Read-onlyIdempotent

Find receipts by period, fiscal number, barcode, shift, cash register, or branch; returns summaries with type, status, totals, goods, and payments for review.

Instructions

Finds receipts (чеки) by period, fiscal number, barcode, shift, cash register or branch. Returns a summary per receipt: type (SELL, RETURN, SERVICE_IN, SERVICE_OUT, ...), status (DONE means fiscalized), fiscal number, totals, goods and payments. The API has no filter by status or type, so filter the returned rows yourself. By default only receipts created by the signed-in cashier are returned. Use get_receipt for the full record.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoPage size. Default 25; values above the cap (100 unless stated otherwise) are clamped.
offsetNoNumber of records to skip, for paging. Default 0.
barcodeNoBarcode of the receipt.
to_dateNoReceipts before this moment. ISO 8601 with a UTC offset, e.g. 2026-10-01T00:00:00+03:00 (Kyiv is +02:00 in winter, +03:00 in summer).
from_dateNoReceipts from this moment. ISO 8601 with a UTC offset, e.g. 2026-10-01T00:00:00+03:00 (Kyiv is +02:00 in winter, +03:00 in summer).
shift_idsNoOnly receipts of these shifts (UUIDs).
branch_idsNoOnly receipts of these branches (UUIDs).
fiscal_codeNoFiscal number of the receipt.
all_cashiersNoSet true to ask for receipts of every cashier instead of only the signed-in one. Whether that is allowed depends on the cashier permissions in Checkbox.
newest_firstNoSort from newest to oldest. Default true.
cash_register_idsNoOnly receipts of these cash registers (UUIDs).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds two genuinely useful behavioral facts: results are scoped to the signed-in cashier by default, and the API cannot filter by status or type. The stated return fields are helpful too, though the default-scope detail partially overlaps the all_cashiers schema description.

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-loaded with purpose and filter dimensions, then return shape, then the API limitation, then the sibling routing hint. Every sentence carries distinct information with no filler.

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?

For an 11-parameter read tool with no output schema, the description compensates well by summarizing the returned row fields and flagging the client-side filtering requirement and default cashier scoping. Nothing essential to correct invocation 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?

Schema description coverage is 100% and all 11 parameters are documented there, including defaults, caps, ISO 8601 format and UUID patterns. The description restates the filter dimensions but adds no syntax or format detail beyond the schema, so the baseline of 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 (Finds) and resource (receipts) and enumerates the exact filter dimensions available: period, fiscal number, barcode, shift, cash register, branch. This makes it immediately distinguishable from siblings like get_receipt or search_goods.

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 alternative tool and the condition that selects it: 'Use get_receipt for the full record.' It also warns that status/type filtering must be done client-side, which tells the agent this is a broad list-and-filter tool rather than a targeted lookup.

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