fynsight: MCP server for DATEV

list-open-anomaly-cases

Read-only

Summarize anomaly cases of a Monatsreporting run by default (counts, sums, top cases); view cases lists single cases, filtered and paginated. status: open (default), decided (resolved/dismissed) or all. Filters for both views: kind, severity, category (label name; ambiguous names are rejected, then pass pnl_label_id), pnl_label_id, cost_center, min_abs_delta. by_cost_center entries carry hidden (cost center hidden in the app); they are marked, never dropped. Amounts (actual, reference, delta = actual - reference, delta_pct) are taken unchanged from the detection rules and follow their sign convention; only budget_deviation and mom_outlier carry delta (sign_flip fills actual from current, duplicate_suspicion from amount, missing_account has no amount). Sums (sum_abs_delta) are given per kind only, never mixed across kinds; kinds without delta report sum_abs_delta null and cases_without_delta. commentary is the case note (Reporting-Vermerk): while the case is open it is material for the comment of the position; once a person accepts the comment in the app it holds the short form of that comment. The report shows the comments (see list-comment-status), not case notes. commentary_source says who wrote the note (ai = AI review, user = a person, null = older case). follow_up is a check of an earlier watch item (the case carries watch with the original statement and the result of the check: recurred true/false/null from the detection, position_missing true when the position could not be assessed in this month - then it is never "did not recur"). Each case carries clarification (the one open or answered question with its context, suggestions and answer) or null; the summary counts open_clarifications and follow_ups. updated_at is the last change of the case (not the decision time). READ ONLY.

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": {
      "run_id": "<run_id>"
    },
    "name": "list-open-anomaly-cases"
  }
}

Input Schema

Name	Required	Description
`top`	No	view summary: number of top cases (default 20, max 50)
`kind`	No	Filter by case kind
`view`	No	summary (default): counts, sums and top cases; cases: single cases, paginated
`limit`	No	view cases: page size (default 50, silently capped at 200)
`run_id`	Yes	UUID of the run
`status`	No	open (default): unresolved cases; decided: resolved + dismissed; all: both
`after_id`	No	view cases: cursor, the next_cursor of the previous page
`category`	No	Filter by P&L category, name as shown in the app
`severity`	No	Filter by severity
`cost_center`	No	Filter by cost center
`pnl_label_id`	No	Filter by P&L category id (UUID); use when the category name is ambiguous
`min_abs_delta`	No	Only cases with abs(delta) at least this amount (cases without delta are excluded)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Well beyond the readOnlyHint annotation, it discloses substantive behavior: hidden cost centers are marked but never dropped, sums are never mixed across kinds and kinds without delta report null plus a cases_without_delta count, and amounts follow the detection rules' sign convention with per-kind caveats. It also explains that updated_at is not the decision time and that commentary changes meaning once a person accepts the comment — all the kind of nuance annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and no sentence is pure filler, but the body is a dense run-on of semicolon-clamped clauses (e.g. the sign_flip/duplicate_suspicion/missing_account parenthetical) that is hard to scan. It would benefit from separating input semantics from return-value semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since there is no output schema, the description correctly carries the full burden of explaining return values — per-kind sums, by_cost_center hidden markers, commentary/commentary_source, follow_up and clarification shapes, and pagination via next_cursor. It is nearly complete for a 12-parameter, two-mode tool; a short statement on what the summary's top-case list contains in cases mode would close the gap.

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

Parameters3/5

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

With schema coverage at 100% and enum descriptions already present, the schema does most of the work; the description mainly repeats defaults (status, view, top) rather than adding syntax or constraints. The genuine value-adds are that filters apply to both views and that ambiguous category names are rejected in favor of pnl_label_id; most remaining prose describes returned fields, not parameters.

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 first clause gives a specific verb and resource ('Summarize anomaly cases of a Monatsreporting run') and immediately distinguishes the two modes: default summary vs 'view cases' listing single, filtered, paginated cases. It also differentiates itself from mutating siblings by cross-referencing list-comment-status for report comments and closing with 'READ ONLY.'

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?

It states which view is the default and what each is for, that filters apply to both views, and gives an explicit escalation path when a category name is ambiguous ('ambiguous names are rejected, then pass pnl_label_id'). What is missing is explicit routing to sibling tools such as note-anomaly-case or answer-clarification for the write side.

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?