Skip to main content
Glama
jkbngb

agentic-firmenbuch

by jkbngb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

List company documents

list_documents
Read-onlyIdempotent

Lists a company's official documents newest-first from Austria's Firmenbuch by number, returning metadata for annual filings and associated PDFs.

Instructions

List a company's available official documents, newest first. Read-only, metadata only.

    Parameter:
    - fnr (required): Firmenbuchnummer, e.g. "123456a" (an "AT:" prefix is tolerated).

    Returns ONE merged chronology, strictly newest-first: every entry is
    {type, stichtag, financial_year, document_ref, format, parsed, note?}. Two types:
    `annual_financial_statement` (a filed Jahresabschluss; `parsed=true` means figures are
    served) and `abschluss_document_pdf` (an Abschluss-carrying PDF the register holds beyond
    the plain filing — Konzernabschluss, HV-Protokoll m. Jahresabschluss, Lagebericht — with
    its `dokumentart` label; always `parsed=false`). A Konzernabschluss next to the same
    year's Jahresabschluss is a DIFFERENT document, not a duplicate. Years held only as PDF
    appear with `parsed=false` + a `note` — no extracted figures, but the original stays
    downloadable (an honest gap, never silent). Pass any entry's `document_ref`
    ("{fnr}:{stichtag}") to get_document for a signed download link. No download link and no
    personal data here — use get_document for the file, get_company_details for the figures.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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 readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond that: strictly newest-first merged chronology, no download links, no personal data, the meaning of parsed=true/false, and that PDF-only years are surfaced honestly rather than silently dropped.

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-loaded with purpose, then parameter, then returns — a logical order with no filler sentences. It is dense however, and the detailed entry-shape enumeration partially duplicates what the output schema already provides, costing a little efficiency.

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?

Given a single required parameter, an output schema, and rich annotations, the description still covers the remaining ambiguities an agent needs: parameter format, ordering guarantee, type semantics, the document_ref handoff to get_document, and the honest-gap behavior.

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% and the single parameter would otherwise be opaque, but the description fully compensates: it names fnr as Firmenbuchnummer, gives a concrete example format ('123456a'), and states that an 'AT:' prefix is tolerated.

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?

Specific verb + resource + ordering ('List a company's available official documents, newest first') with scope qualifiers ('read-only, metadata only'). It also implicitly distinguishes itself from get_document and get_company_details, which the description names explicitly later.

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: this tool for the listing/metadata, get_document for download links, get_company_details for figures. It also tells when a year appears only as PDF and that this is an intentional gap rather than an error, and clarifies that a Konzernabschluss is not a duplicate of the year's Jahresabschluss.

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