fynsight: MCP server for DATEV

get-variance-bridge

Read-only

Result bridge for a month: EBITDA, EBIT and net income from a comparison value to actual, step by step per P&L category. READ ONLY. compare_to: previous_month, previous_quarter_month, previous_year or budget (plan_id optional, only with budget; default is the active plan of the year of the period, without one the call fails with NO_ACTIVE_BUDGET_PLAN). All amounts are result impact (revenue +, expense -, positive = improves the result; deltas = actual - comparison). start/end come from the computed metrics, the steps from category deltas, check.reconciles proves they add up (on unrounded values). unassigned = result change no category of this metric explains (labels without id or subtotal group, accounts without label); excluded lists what is left out (unlabeled_accounts, labels_without_group) and a warning appears when either is non-empty. rounding_difference = end - (start + steps + other + unassigned) on the rounded figures, draw it as a last tiny bar or absorb it. Steps carry sort_order (P&L order) and auffaellig; the list is sorted by absolute delta. Small steps (below other_threshold, share of the absolute total change, default 0.05) are collapsed into other with their list. Use this instead of subtracting category totals yourself.

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": {
      "period": "<period>",
      "compare_to": "<compare_to>"
    },
    "name": "get-variance-bridge"
  }
}

Input Schema

Name	Required	Description
`period`	Yes	Month, YYYY-MM
`plan_id`	No	UUID of the budget plan; only with compare_to budget. Omitted: active plan of the year
`compare_to`	Yes	Comparison value
`other_threshold`	No	Share (0..0.5, default 0.05) of the absolute total change below which categories are collapsed into other

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses the sign convention for result impact, how deltas are computed, reconciliation checks, unassigned and excluded amounts, rounding differences, step sorting, anomaly flags, and small-step collapsing. It also warns about the NO_ACTIVE_BUDGET_PLAN failure when no budget plan is active.

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?

The description is dense and front-loaded with the tool's purpose, and most details are necessary for a complex financial tool. It is longer than ideal and packed with semicolon-separated clauses, but there is little pure repetition or waste.

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 a four-parameter analytical tool with no output schema, the description is unusually complete: it explains inputs, output components, reconciliation behavior, rounding handling, and special cases such as unassigned and excluded amounts. An agent has enough information to call the tool correctly and interpret its 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?

Even though the schema already covers all parameters, the description adds substantial meaning: compare_to values are explained, plan_id is constrained to budget comparisons with a default active-plan behavior, and other_threshold is tied to step collapsing. This goes well beyond the schema text.

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?

The description states precisely what the tool produces: a monthly result bridge for EBITDA, EBIT, and net income from comparison to actual, broken down step by step per P&L category. It clearly distinguishes the operation from manual subtraction and gives the agent an unambiguous sense of the resource and output.

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?

The description explicitly says to use this tool instead of subtracting category totals manually, and it explains compare_to options and budget-plan behavior. However, it does not name a sibling alternative or state when not to use this tool, so it gives strong context but not full routing guidance.

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?