Skip to main content
Glama

Register change feed (AT + DE)

list_events
Read-onlyIdempotent

Beispiel: „Welche Firmen in Salzburg hatten im letzten Monat einen Geschäftsführerwechsel?“

Cross-company, cross-country feed of register CHANGES, newest first - the market-watch / deal-sourcing surface. Read-only.

    Parameters (all optional, AND-combined):
    - types: any of the SUPERSET enum - founding, new_registration, deletion,
      deletion_announced, name_change, seat_change, legal_form_change, capital_change,
      management_change, management_join, management_leave, gegenstand_change, merger,
      split, conversion, contribution, consolidation, division,
      shareholder_capital_change. Each country's feed carries a SUBSET; a type not in
      a country's feed is skipped for that country (reported in notices), and a
      country with none of the requested types is excluded. Note new_registration (DE,
      a discovery date) and founding (AT, a register event) are distinct - see
      describe_fields.
    - since / until: ISO dates. Default window: last 30 days.
    - bundesland: full state name.
    - nace_section (A-U, both countries); nace_division (AT only); legal_form (AT only).
    - company_ids: prefixed watchlist; AT filters the whole list, DE filters ONE id at
      a time (pass a single DE id, or query DE separately).
    - country: "AT" | "DE" | "all" (default). page (1), page_size (25).

    Returns {countries, events, per_country, windows, notices}. ``events`` are merged
    newest-first, each with ``country`` and a prefixed ``company_id``; AT events add
    before/after values only for the detailed types. ``windows`` states each country's
    data availability (AT: detailed >= 2026-07-01, coarse >= ~2020; DE: >= 2026-07-30)
    so an empty stretch is never mistaken for missing data. For aggregate counts use
    get_event_stats; for one company's history use get_company_details.

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": "list_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo
sinceNo
typesNo
untilNo
countryNoall
page_sizeNo
bundeslandNo
legal_formNo
company_idsNo
nace_sectionNo
nace_divisionNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses real behavior: each country carries a subset of types, unsupported types are skipped and reported in notices, countries with none of the requested types are dropped, DE company_ids filter one id at a time, and empty stretches should be checked against the returned windows. That is exactly the non-obvious behavior an agent needs.

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?

Purpose and read-only flag are front-loaded, and nearly every line carries information. The leading German example is useful but sits oddly ahead of the core statement, and the parameter block is dense though well-organized with bullets.

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 an 11-parameter, zero-schema-coverage tool this is complete: filters, defaults, country-specific asymmetries, data-availability windows, and the return envelope are all covered, and an output schema exists so field-level detail need not be repeated.

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 carries the full burden and does so for all 11 params: the complete types enum superset with the new_registration vs founding distinction, ISO dates with a 30-day default, full state names, nace_section both countries vs nace_division/legal_form AT-only, country values, and page defaults.

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 ('feed of register CHANGES, newest first') plus scope ('cross-company, cross-country') and the job it serves ('market-watch / deal-sourcing'). The closing sentence explicitly separates it from get_event_stats and get_company_details, so an agent can route 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?

The opening example question anchors a concrete use case (management change in Salzburg last month), and the final sentence gives explicit alternatives with their conditions: get_event_stats for aggregate counts, get_company_details for one company's history. Default window and read-only nature are stated up front.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.