Skip to main content
Glama
Sign In

YESbusiness

by ch.yesbusiness
OverviewDiscussionsAdmin

Income statement

get_income_statement
Read-onlyIdempotent

The income statement (profit and loss): revenue and expenses over a date range (date_from to date_to, inclusive), as a nested tree of account groups and accounts. Sign convention in the raw values: revenue is POSITIVE and expenses NEGATIVE, so a group total is revenue plus (negative) expenses and a positive top-level result means a profit, a negative one a loss. Every row is a real account or group — no synthetic rows. Set both compare_from and compare_to to add the compare period and the difference. The tree is PRE-SUMMED by the server: a group row's values already include every account under it, so read a total off the group row itself and never add child rows up yourself. Every amount is an integer in CENTS of the company's home currency — divide by 100 and present francs with two decimals, never the raw integer. Each row has values.period_1 (the main period), plus values.period_2 and values.difference (period_1 - period_2) only when compare dates were sent.

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": {
      "date_from": "<date_from>",
      "date_to": "<date_to>",
      "company_id": "<company_id>"
    },
    "name": "get_income_statement"
  }
}

Input Schema

NameRequiredDescriptionDefault
date_toYesEnd of the period, YYYY-MM-DD, inclusive.
date_fromYesStart of the period, YYYY-MM-DD, inclusive.
company_idYesThe company to work on — one of list_my_companies' company_id values.
compare_toNoEnd of the compare period, YYYY-MM-DD. Only takes effect together with compare_from.
compare_fromNoStart of the compare period, YYYY-MM-DD. Only takes effect together with compare_to.
show_all_accountsNoInclude accounts with no bookings (zero balances). Leave off unless the user asks about an account that is missing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/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 behavior that structured fields cannot convey: the sign convention (revenue positive, expenses negative), the server-side pre-summing of group totals with an explicit instruction not to add child rows, integer cents in home currency, and the presence of period_2/difference only when compare dates are supplied. This is exactly the kind of context that prevents misinterpretation of the response.

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 the tool's purpose and dense with useful constraints, with no filler sentences. It is a single long block of run-on sentences though, so high-value warnings like the pre-summed totals and the cents convention are buried mid-paragraph rather than set apart.

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?

There is no output schema, so the description carries the full burden of describing the return shape — and it does: nested tree structure, per-row values.period_1 with conditional period_2 and difference, sign convention, and unit (integer cents). An agent has everything needed to both call it and present results correctly.

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 100%, so the baseline is 3, but the description goes further by explaining what the compare parameters actually produce (period_2 and period_1 minus period_2) and by reinforcing the inclusive date-range semantics. The one gap is show_all_accounts, whose guidance lives only in the schema.

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 (income statement / P&L) plus the exact scope: revenue and expenses over an inclusive date range, returned as a nested tree of account groups and accounts. Alongside siblings like get_balance_sheet and get_vat_statement, an agent can tell immediately which report this produces without opening the schema.

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

Usage Guidelines4/5

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

Gives clear operational guidance: set both compare_from and compare_to to get a comparison, and the schema entry warns to only use show_all_accounts when an account appears missing. It does not, however, explicitly route the agent away from alternatives such as get_balance_sheet or get_analysis, so the sibling selection is left implicit.

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