fynsight: MCP server for DATEV

get_all_accounts

Read-only

Get all accounts with their labels and categories for this tenant. Filter by the 'category' field, NOT account numbers. Use the system prompt's tenant-specific category lists to identify revenue vs. cost accounts. Ignore: 'Bank', 'Cash', 'VAT'. Optional filters: exact category, account number range (account_from/account_to), and is_pnl (P&L vs. balance sheet accounts). Omit 'limit' to get every matching account (paginated internally, no row cap); pass it only to cap the number of rows returned — the response then reports whether the result was truncated.

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_all_accounts"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Optional cap on the number of accounts returned (must be a positive integer). Omit to get the full, unpaginated-by-you list of every matching account. When set, the query itself is bounded (no full-table load) and the response's 'truncated' field tells you whether more accounts existed beyond the cap.
`is_pnl`	No	Filter by P&L accounts (true) or balance sheet accounts (false)
`category`	No	Filter by exact category name (e.g. 'Umsatzerlöse', 'Bank')
`account_to`	No	Maximum account number (inclusive)
`account_from`	No	Minimum account number (inclusive)

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds behavior the annotations cannot: results are paginated internally with no row cap when 'limit' is omitted, and truncation is reported in the response when a cap is applied. It does not describe the response shape beyond the 'truncated' field, but that is a minor gap for a read-only listing.

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 purpose sentence and the filter guidance are front-loaded, and the ignore-list is compressed into a single fragment rather than prose. It is slightly dense with imperative clauses, but each one carries actionable information rather than filler.

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?

For a five-parameter, all-optional read tool with no output schema, the description covers filtering strategy, limit/pagination behavior, and the truncation signal an agent needs to decide whether to re-query. Only the exact return fields beyond 'truncated' are left implicit, which is acceptable for a read-only listing.

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 goes further by explaining the practical intent of 'limit' (omit for the complete list, set only to cap rows, avoids a full-table load) and by steering 'category' usage away from account numbers. The account_from/account_to range is only restated, not enriched.

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?

Opens with a concrete verb+resource: 'Get all accounts with their labels and categories for this tenant', which is clearly the chart-of-accounts listing rather than the transaction or cost-center tools in the sibling list. It does not name a sibling tool it might be confused with, so it stops short of full differentiation.

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?

Gives real usage direction: filter via 'category' and not account numbers, consult the system prompt's tenant-specific category lists, and ignore 'Bank'/'Cash'/'VAT'. It also explains when to omit vs. pass 'limit'. It never names an alternative tool for the cases this one doesn't cover, so no explicit exclusion of siblings.

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?