Skip to main content
Glama
jkbngb

agentic-firmenbuch

by jkbngb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Find peer companies

find_peers
Read-onlyIdempotent

Identify same-size peer companies for a given Austrian Firmenbuch number, preferring same ÖNACE industry matches and returning compact company cards.

Instructions

Find the companies most similar in size to a given one. Read-only.

    Parameters:
    - fnr (required): the reference company's Firmenbuchnummer, e.g. "123456a".
    - n (optional, default 10, clamped to 1..50): how many peers to return.

    Returns up to `n` companies in the SAME size class (`gkl`) as the reference, preferring
    the same ÖNACE industry as SPECIFICALLY as possible: the cascade class -> group ->
    division -> section widens only when a level has too few companies, and any remaining
    slots are filled with the nearest same-size companies from other industries — closest by
    Bilanzsumme within the class and group levels; on broader levels a reference with a
    registered activity text gets the most similar activities first. Each is a compact card
    like search_companies. The response
    carries `same_sector_level` ("class"/"group"/"division"/"section"/null: how specific the
    industry match is), `same_sector_count`, and an explicit `note` when the match is only
    section-wide or the list is (partly) a pure size-neighbourhood — so you never mistake
    same-size-different-industry rows for a sector benchmark (e.g. holdings whose stated
    industry differs from the group's). The reference company is excluded; an empty list means
    the FNR is unknown or has no Bilanzsumme to rank against. Recency: only companies whose
    last Jahresabschluss is from the current year minus 3 or later qualify; when fewer than
    `n` class/group-level peers exist in that window it widens once to minus 5 and the `note`
    says so (`peer_recency` = {years, min_year, widened}); every peer row carries
    `latest_year`. For a strict industry benchmark, filter search_companies by oenace_* + size
    instead; for group aggregates use get_cohort_summary.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNo
fnrYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent, and the description adds substantial behavior beyond them: the sector cascade (class->group->division->section), the size-neighbour fallback, recency window (current year minus 3, widening once to minus 5), exclusion of the reference company, and the same_sector_level/note signals that guard against misreading rows as benchmarks.

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?

Well front-loaded (purpose, then parameters, then the long return/cascade explanation), but the returns paragraph is a dense run-on covering cascade, tie-breaking, recency, and note semantics in one block. Every sentence is informative, though it could be split for scanability.

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 tool with non-obvious matching logic, the description covers selection cascade, tie-breaking rules, recency widening, reference exclusion, and the caveat fields (same_sector_level, peer_recency, note). With an output schema present, it appropriately stops short of re-listing raw field types.

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: it explains fnr as the reference Firmenbuchnummer with a concrete format example ('123456a') and defines n's default (10) and clamp (1..50). Both parameters gain meaning unavailable in the bare 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?

First sentence gives a precise verb+resource+scope: find companies most similar in size to a reference company. It is clearly distinguishable from siblings, and the closing sentences explicitly name search_companies and get_cohort_summary as the tools for different jobs.

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?

Explicitly routes the agent: use find_peers for size-based peer discovery, search_companies with oenace_* + size for a strict industry benchmark, and get_cohort_summary for group aggregates. It also states the meaning of an empty result, which removes a common ambiguity.

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

Deploy Server

Other Tools