Skip to main content
Glama

fynsight: MCP server for DATEV

search_cost_center_transactions

Read-only

Search individual transactions. Returns period, cost_center, account, amount, description, transaction_date (day-exact booking date), contra_account, sub_account, contra_sub_account (sub-account of the account/contra account, null if none), plus id (use this as transaction_id for propose-transaction-correction) and source ("upload" or "manual"). Each row also reports correction_status ("none" | "pending" | "corrected") and correction_role (null | "reversal" | "rebooking") so you can see whether a booking already has an open or approved correction, or is itself the reversal/re-booking line of one — check this before calling propose-transaction-correction to avoid duplicate proposals. With truncated=true not all matches were loaded — FIRST call the tool again with a higher limit_count (default 200, maximum 1000); only if limit_count=1000 still returns truncated=true, narrow down via periods/cost_centers/accounts/text_query/date_from/date_to. Never claim 'no further data'. Use available_range. text_query searches the term literally as a case-insensitive substring in description OR reference; % and _ are NOT wildcards but are searched as characters ("25%" only finds "25%", not "2500"). With group_by the tool returns bookings grouped by period and/or cost center instead of the flat row list. Take counts only from total_count (returned bookings), group_count (groups) or transaction_count per group — never count yourself and never state limit_count as a count. This tool returns individual bookings; for sums (per month, cost center or account) call compute_aggregates instead of adding up the rows yourself. If the user names a cost center (e.g. "Betriebsrat"), call get_cost_center_list FIRST to resolve its number; never guess the number.

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": "search_cost_center_transactions"
  }
}

Input Schema

NameRequiredDescriptionDefault
date_toNoDay-exact upper bound on transaction_date, inclusive (YYYY-MM-DD). Omit for no upper bound.
periodsNo
accountsNo
group_byNoOptional. Groups the matching bookings by these fields instead of returning a flat row list — the response then carries `groups` (each with transaction_count and transactions_truncated) instead of `rows`. Omit it when you want the individual bookings.
date_fromNoDay-exact lower bound on transaction_date, inclusive (YYYY-MM-DD). Omit for no lower bound.
text_queryNoLiteral case-insensitive substring, matched against description OR reference. %, _ and \ are searched as characters, not as wildcards.
limit_countNoMax rows (default: 200, max: 1000)
cost_centersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds substantial behavior beyond that: truncation semantics and the escalation path, the rule that counts must come from total_count/group_count/transaction_count and never from limit_count, and the instruction never to claim 'no further data'. It also discloses that group_by switches the response shape from rows to groups, which is not derivable from the annotations.

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?

It is front-loaded with purpose and return shape, but it is a dense run-on paragraph where several clauses duplicate the schema verbatim, notably the text_query wildcard rule and the limit_count default/max. The truncation-handling and counting rules earn their place, but the whole block would read better as short structured bullets.

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 return values, and it does so field by field (id, source, correction_status, correction_role, contra/sub accounts) plus the alternate grouped response. For an 8-parameter read tool with truncation risk, nothing an agent needs to call it correctly or interpret results is missing.

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 63%, and the description compensates for the uncovered parameters by naming periods, cost_centers, accounts and date bounds as the narrowing levers, plus explaining that limit_count defaults to 200 and caps at 1000. The text_query semantics (literal substring over description OR reference, % and _ not wildcards) and group_by's effect on the response shape are spelled out, adding real meaning rather than restating 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?

Opens with a specific verb+resource ("Search individual transactions") and immediately enumerates the returned fields, which distinguishes it from the aggregation sibling. The final sentences explicitly separate it from compute_aggregates (sums) and get_cost_center_list (name resolution), so an agent can route correctly 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 when-to-use and when-not-to-use rules: use this for individual bookings, call compute_aggregates for sums, call get_cost_center_list FIRST to resolve a named cost center and never guess the number. It also prescribes a concrete recovery procedure for truncated results (retry with higher limit_count, only then narrow filters) and warns to check correction_status before propose-transaction-correction.

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