Skip to main content
Glama
Sign In

YESbusiness

by ch.yesbusiness
OverviewDiscussionsAdmin

Bookings

list_bookings
Read-onlyIdempotent

The company's bookings (double-entry ledger entries), newest first, as one page with a total count. Filters: date_from / date_to (YYYY-MM-DD, inclusive, on the booking date — turn 'this month' etc. into an explicit range before calling); search (free text matched against a booking's description OR its number — good for a named item like 'rent', but it does NOT match account names or amounts); status. Each row has date, number, description, amount_home (integer, in cents of the company's home currency), currency symbol, and the debit/credit account labels. Use the returned total to answer whether or how many bookings match; do not sum amounts across many rows yourself. You CANNOT filter by income vs expense or by account here — if that is what the user wants, say you cannot look that up yet.

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": {
      "company_id": "<company_id>"
    },
    "name": "list_bookings"
  }
}

Input Schema

NameRequiredDescriptionDefault
searchNoFree text matched against booking description or number.
statusNoRestrict to bookings in this state.
date_toNoInclusive upper bound on the booking date, YYYY-MM-DD.
per_pageNoRows to return, 1-50 (default 25).
date_fromNoInclusive lower bound on the booking date, YYYY-MM-DD.
company_idYesThe company to work on — one of list_my_companies' company_id values.

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?

Goes well past the readOnly/idempotent annotations by disclosing ordering, pagination-with-total behavior, that amount_home is an integer in cents of the home currency, that debit/credit account labels are included, and the important warning not to sum amounts across rows manually. This is behavior an agent could not derive from the annotations or schema.

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 resource, ordering, and return shape, then filters, then caveats — a sensible progression. It is dense and parenthetical-heavy, running long for a single-tool definition, but nearly every clause carries operational meaning.

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?

With no output schema, the description responsibly enumerates the returned row fields (date, number, description, amount_home in cents, currency symbol, debit/credit labels) and the total count. Combined with the explicit filter limitations, an agent has everything needed to call this correctly and to explain its limits to a user.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds real semantics the schema lacks: search matches description OR number only (not account names or amounts), and date bounds are inclusive on the booking date with relative periods needing conversion. per_page is left to the schema, which is a minor omission only.

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 resource ('the company's bookings (double-entry ledger entries)'), the ordering ('newest first'), and the return shape ('one page with a total count'). It does not explicitly distinguish itself from close siblings such as get_journal or get_account_statement, so an agent must infer the boundary from the resource name alone.

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?

Gives explicit when-to-use for search ('good for a named item like rent'), explicit when-NOT ('does NOT match account names or amounts', 'You CANNOT filter by income vs expense or by account'), and prescribes the fallback behavior ('say you cannot look that up yet'). It also instructs the agent to normalize relative dates into an explicit range before calling.

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

All YESbusiness toolsInspect
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.

Resources