fynsight: MCP server for DATEV

get_budget_vs_actual

Read-only

Budget (Soll) vs actual (Ist) with variance and YTD summary. Requires plan_id from list_budget_plans. detail=summary omits period_rows and row_count (use it for KPI-only questions). Besides the per-category rows (period_rows, ytd_summary) the response carries derived P&L metrics for plan AND actual: metrics (per period) and metrics_ytd (all periods of the response) with revenue, other_income, cogs, opex, depreciation, financial, tax, gross_margin, ebitda, ebit, ebt and net_income (= Jahresueberschuss), each with budget, actual, variance and variance_pct. They are computed from tenant_config.pnl_labels exactly like get_periodic_summaries.metrics — do NOT sum categories yourself. unmapped_categories lists categories with amounts but no subtotal_group (not part of any metric). With cost_center set, actuals of the metrics are tenant-wide (see metrics_note). Account level (granularity=account): one row per account/sub-account of the plan, key "8400" (the main account = sub-account 000, compared against the actuals of the main account only) or "8400/130" (a specific sub-account, compared against that sub-account only) — the two never overlap and are not summed.

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": {
      "plan_id": "<plan_id>"
    },
    "name": "get_budget_vs_actual"
  }
}

Input Schema

Name	Required	Description
`detail`	No	rows (default) = full period_rows + row_count; summary = only ytd_summary, metrics, metrics_ytd and unmapped_categories (small answer for KPI-only questions).
`date_to`	No	End date YYYY-MM-DD or YYYY-MM. Omit for full plan range.
`plan_id`	Yes	UUID of the budget plan (from list_budget_plans)
`date_from`	No	Start date YYYY-MM-DD or YYYY-MM. Omit for full plan range.
`cost_center`	No	Optional cost center filter.
`granularity`	No	Breakdown level (default: category)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Despite readOnlyHint already covering safety, the description discloses substantial behavior: metrics are computed from tenant_config.pnl_labels exactly like get_periodic_summaries.metrics, users must NOT sum categories themselves, unmapped_categories are excluded from metrics, and with cost_center set the metric actuals are tenant-wide. This is exactly the kind of non-obvious behavior an agent needs.

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 and the required plan_id are front-loaded, then the return shape and edge cases follow. It is dense and uses long run-on sentences, but nearly every clause carries non-redundant information, so little padding is present.

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 burden of explaining returns — and it does so thoroughly (metrics, metrics_ytd, unmapped_categories, account-level rows). For a six-parameter analytical tool with derived-metric subtleties, 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.

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 adds real meaning: detail=summary omits period_rows/row_count, granularity=account yields one row per account/sub-account with the '8400' vs '8400/130' non-overlap rule, and cost_center affects metric scoping. It leaves the knw_row granularity and the day-level date format unexplained.

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 concrete verb+resource: budget (Soll) vs actual (Ist) with variance and YTD summary, and names the output pieces (period_rows, ytd_summary, metrics). It references sibling tools (list_budget_plans, get_periodic_summaries) but does not explicitly distinguish itself from close alternatives like get_variance_bridge or query_kpis.

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?

Clear usage context: plan_id is required and sourced from list_budget_plans, and detail=summary is explicitly recommended for KPI-only questions. It also flags the cost_center caveat (metrics become tenant-wide). Missing an explicit statement of when to prefer a sibling such as get_variance_bridge for a different view.

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

All fynsight: MCP server for DATEV 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.

Resources

Need Help?