Skip to main content
Glama
jkbngb

agentic-firmenbuch

by jkbngb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Cohort statistics

get_cohort_summary
Read-onlyIdempotent

Summarize Austrian company cohorts by size class, federal state, or legal form. Returns counts and distribution statistics instead of individual company records.

Instructions

Aggregate statistics for a cohort of companies. Read-only.

    Parameters:
    - dimension (required): which axis defines the cohort, one of "gkl" (size class),
      "bundesland" (federal state), or "legal_form" (Rechtsform). The search-filter alias
      "size_gkl" is accepted for "gkl".
    - value (required): the cohort value on that axis, e.g. dimension="bundesland",
      value="Wien" (full name or the code "W" both work); dimension="gkl", value="M".
      Use list_sectors to see valid legal_form / gkl values.

    Returns cohort counts plus distribution statistics (e.g. Bilanzsumme median; the exact
    median is skipped for very large cohorts to keep the request fast), NOT per-company rows.
    Use for "what does group X look like in aggregate"; for the individual companies use
    search_companies, for one company use get_company_details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYes
dimensionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.7/5.0
Behavior4/5

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

The description adds real context beyond the annotations (which already assert read-only, idempotent, non-destructive): it discloses the large-cohort median skip ('the exact median is skipped for very large cohorts to keep the request fast') and clarifies the return is aggregate stats, not rows. This is a meaningful behavioral disclosure not present in 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 purpose, then parameter documentation, then routing guidance. The parameter list is necessarily detailed given 0% schema coverage, but the prose is tight and every sentence carries information. Could be marginally shorter but nothing is wasted.

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?

With annotations, a 0% schema, and an output schema already present, the description supplies the only missing pieces: dimension/value semantics and routing. It even notes a behavioral caveat about large cohorts. An agent has everything needed to call it correctly.

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 0%, so the description must carry the full burden, and it does: it defines the 'dimension' axis with all valid values ('gkl', 'bundesland', 'legal_form' and the 'size_gkl' alias), explains 'value' semantics with examples and accepted forms (code 'W' or full name 'Wien'), and points to list_sectors for valid legal_form/gkl values.

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 precise verb and resource ('Aggregate statistics for a cohort of companies') and immediately sets scope with 'NOT per-company rows'. It names the alternative siblings (search_companies, get_company_details) in context, so it is clearly distinguishable from them.

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 says when to use it ('what does group X look like in aggregate') and when to use alternatives ('for the individual companies use search_companies, for one company use get_company_details'), naming both siblings. It also points to list_sectors for valid values.

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