Skip to main content
Glama

fr_events

Read-only

List BODACC legal events for a company: creations, modifications, sales, collective proceedings, annual filings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "siren": "<siren>"
    },
    "name": "fr_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
limitNoMax results (default 20).
sirenYesSIREN number (9 digits).
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
familleNoFilter by BODACC family code (the schema lists them, e.g. collective, modification, vente, dpc = dépôt des comptes). Output `familleavis_lib` is a label, not an input. None = all.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

B3.4/5.0
Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read. The description adds real context by defining what an 'event' is (the BODACC family types), but says nothing about result limits/pagination despite a limit parameter, ordering, or volume expectations for a company's history.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the verb, resource, scope, and content categories all arrive immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with full schema coverage, annotations, and no output schema, this is nearly complete. A brief note on ordering or how many events typically return per company would fully close the gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and every parameter, including the famille enum and limit, is documented in-schema. The description only conveys the SIREN-scoping implicitly and adds no meaning beyond the schema, so it falls below the baseline-3 case where schema already does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('BODACC legal events') scoped to a single company, and enumerates the event categories (creations, modifications, sales, collective proceedings, annual filings) so the agent knows what content to expect. It does not explicitly separate itself from nearby siblings like fr_events_batch or bodacc_notice, which keeps it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: 'for a company' plus the required siren shows this is the per-company event lookup, and the batch sibling name hints at a bulk alternative. There is no explicit statement of when to prefer fr_events_batch or bodacc_notice, and no exclusions or prerequisites.

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.

Resources