Skip to main content
Glama

fynsight: MCP server for DATEV

get_periodic_summaries

Read-only

P&L summaries per period: metrics (EBIT, EBITDA, margins) and category_totals. For a yearly or quarterly figure set granularity — the tool then sums the months and re-derives the metrics itself. Each summary's metrics.category_totals_sort_order gives the GuV-Explorer display order per category (lower sorts first). Per-account balances are NOT returned by default (keeps the answer small): set include_account_totals=true to get totals per summary, but for account questions prefer compute_aggregates. Set include_previous for a ready-made deviation report against the CALENDAR predecessor (previous month/quarter/year; loaded automatically if not requested, granularity total has none): each summary gets previous_period, previous_comparison (per headline figure: current, previous, delta_absolute, delta_percentage) and delta_category_totals (same keys as category_totals, i.e. the current label name, with label_ids, current, previous and the deltas; the current value equals the category_totals value of the same key). A category without bookings in a period that has computed metrics counts as 0, not null; delta_percentage is null when the previous value is 0. All deltas are null (never 0) when a side has no computed metrics. For quarter/year, if the current bucket or its predecessor covers fewer months than the bucket length (3/12; see months_covered and previous_months_covered), all deltas are null and a warning names the period. There is no previous_metrics and no top-level delta_absolute/delta_percentage.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_periodic_summaries"
  }
}

Input Schema

NameRequiredDescriptionDefault
date_toNoEnd of a date range (YYYY-MM-DD or YYYY-MM), additive to `periods`. Independent of date_from — given alone, the range starts at the tenant's first available period. Omit both for all data.
periodsNoYYYY-MM periods
date_fromNoStart of a date range (YYYY-MM-DD or YYYY-MM), additive to `periods`. Independent of date_to — given alone, the range runs through the tenant's last available period. Omit both for all data.
granularityNoTime bucket of the returned figures: 'month' (default), 'quarter', 'year' or 'total'. Set this whenever the answer needs a figure covering more than one month — never add the monthly values up yourself.
include_previousNoAttach previous_period/previous_comparison/delta_category_totals to each summary, comparing it against the calendar predecessor (previous month/quarter/year, loaded automatically if not in the request; default false).
include_account_totalsNoAttach `totals` (one row per account/sub-account with period_balance and account_ref) to every summary (default false: omitted, answer stays small). For account questions prefer compute_aggregates.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint, but the description discloses defaults (account totals omitted), that the previous period is auto-loaded, that granularity=total has no predecessor, and precise null semantics for deltas (zero previous value, missing metrics, partial buckets plus a warning). It also states what is NOT returned (no previous_metrics, no top-level delta fields).

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?

Purpose is front-loaded and every sentence carries operational detail, but the block on delta semantics is dense and parenthesis-heavy, forcing the reader through nested caveats in a single paragraph. A short bulleted split of the delta rules would improve scanability without losing content.

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 and six optional parameters, the description carries the return-shape burden and does so: it names the summary fields, the previous_comparison sub-keys, and the delta_category_totals structure. An agent has enough to call it correctly and interpret the result.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description adds genuine meaning: granularity triggers server-side summing and metric re-derivation, include_previous targets the CALENDAR predecessor and can auto-load it, and include_account_totals changes the shape to a `totals` row per account. These are behavioral consequences the schema cannot express.

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?

Opens with a specific verb+resource: 'P&L summaries per period: metrics (EBIT, EBITDA, margins) and category_totals', naming the exact payload. It also distinguishes itself from the sibling compute_aggregates, so an agent can choose without opening schemas.

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 routing rules: set granularity for quarter/year and never sum months manually; for account questions prefer compute_aggregates; set include_account_totals only when per-account balances are needed. When-not guidance (default keeps the answer small) is stated alongside each alternative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources