agentic-firmenbuch

Overview Schema Source Related Servers Discussions Admin

Benchmark a company vs peers

benchmark_company

Read-onlyIdempotent

Compare an Austrian company's financial metrics and percentiles to its peer group. Determine its standing within its UGB size class.

Instructions

Where one company stands in its peer group — a composite over find_peers + the company's precomputed size-peer percentiles. Read-only. Pro.

    Parameters:
    - fnr (required): the company's Firmenbuchnummer, e.g. "123456a" (an "AT:" prefix is
      tolerated).
    - n (optional, default 10, clamped 1..50): how many peers to include.

    Returns the company's headline metrics (bilanzsumme, revenue, equity_ratio, growth_profile),
    its `percentiles` WITHIN its UGB size class (100 = top of the class; available for
    bilanzsumme and equity_ratio), and the nearest peers (same size class, same ÖNACE section
    preferred, recent filers only: last Jahresabschluss within 3 years, widened once to 5 when
    too few exist, see `peer_recency` + `peers_note`; each peer carries `latest_year`). Use for
    "how does X compare to its peers"; for the raw peer list use find_peers, for whole-cohort
    aggregates use get_cohort_summary.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`n`	No
`fnr`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on genuinely non-obvious behavior: 'Pro' tier gating, percentile semantics (100 = top of class, only for bilanzsumme and equity_ratio), and the peer recency rule including the 3→5 year widening and where it surfaces (peer_recency/peers_note). That is real disclosure beyond the structured fields.

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?

Front-loads the one-line purpose, then a compact Parameters block and a returns paragraph with a routing sentence at the end. Slightly dense in the returns section, but every clause carries information an agent needs to interpret percentiles and peer recency.

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?

An output schema exists, yet the description still names the headline metrics and the percentiles/peers shape, and documents the Austrian-domain constraints (UGB size class, ÖNACE section, recent filers). For a two-parameter composite tool this is more than sufficient.

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 description coverage is 0%, so the description carries the full burden and does: fnr format with example and the tolerated 'AT:' prefix, plus n's default (10) and clamp range (1..50). Nothing about either parameter is left ambiguous.

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?

States a specific verb and resource ('Where one company stands in its peer group') and defines the composite method (find_peers + precomputed size-peer percentiles). The sibling set is named explicitly, so an agent can separate it from find_peers and get_cohort_summary without opening a schema.

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 an explicit triggering phrase ('Use for "how does X compare to its peers"') and names both alternatives with their selecting conditions: find_peers for the raw peer list, get_cohort_summary for whole-cohort aggregates.

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

Deploy Server