Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

bodacc_notice

Read-only

BODACC legal notices across ALL French companies (DILA open data, no key): find companies FROM their notices — every receivership opened in a department this week, every business sale in a city, accounts filed, deregistrations. For the notices of ONE known company, fr_events(siren) is the shorter path.

op="search" (default) — notices matching the filters, most recent first. Returns total_count, next_offset (null on the last page) and notices: flat lines — the company (siren, parties, commercant, denomination, forme_juridique, capital, adresse_siege, activite), the place (ville, departement, region, tribunal), the judgment, resume (the notice's own text). ⚠️ A SALE names two companies: siren is null and parties gives each SIREN with its role. full=true returns the full notices (heavy). ⚠️ Pagination stops at offset+limit = 10000: past it, narrow the period rather than paging.

op="count" — the number of matching notices grouped by group_by (required), largest first; mois/jour come in date order. Count BEFORE paging a large set: one call sizes it.

op="get" — one notice in full by id (the id of a search line).

Filters (search and count) combine with AND. Always bound a sweep by date: the bulletin holds tens of millions of notices since 2008.

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

Input Schema

NameRequiredDescriptionDefault
qNofull-text search over the whole notice (e.g. "liquidation judiciaire").
idNoop=get only — the notice id (e.g. "A202601943821").
opNosearch | count | get.search
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
fullNosearch only — the full notices instead of the flat lines.
limitNosearch: 1-100 per page (default 20); count: max groups (default 20, up to 100).
orderNosearch only — desc (newest first, default) or asc.desc
sirenNo9-digit SIREN.
villeNowords in the city name.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
offsetNosearch only — first notice to return (pagination).
_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.
date_toNopublication date to, YYYY-MM-DD, inclusive.
familleNonotice family — collective (insolvency proceedings), conciliation, creation, divers, dpc (accounts filed), immatriculation, modification, radiation (deregistration), retablissement_professionnel, vente (sales and transfers of a business).
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
group_byNoop=count only — famille, departement, region, tribunal, type_avis, mois (YYYY-MM), jour.
tribunalNowords in the court name (e.g. "Nanterre").
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
date_fromNopublication date from, YYYY-MM-DD, inclusive.
type_avisNoannonce (initial notice), rectificatif, annulation.
commercantNowords in the company or trader name.
departementNodepartment code — "75", "2A", "974".

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the `readOnlyHint` annotation, the description discloses the data source (DILA open data, no key), the return shape for search (`total_count`, `next_offset`, flat notice lines with specific fields), a critical sale edge case where `siren` is null and `parties` carries SIRENs, the heaviness of `full=true`, and the hard pagination cap at offset+limit=10000. These are meaningful behavioral traits an agent could not infer from the annotations alone.

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?

The description is long but front-loaded and well structured by op mode, with the most important scoping rule (`fr_events` alternative) placed early. A few phrases are slightly redundant, such as repeating that search is most recent first alongside the `order` default, but overall every section earns its place for a 22-parameter multi-op tool.

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 the tool's complexity — 22 parameters, three op modes, no output schema — the description is complete enough for an agent to call it correctly. It explains return fields, pagination behavior, sale-notice handling, date-bounding requirements, and the count-before-paging strategy, so no critical calling context is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds cross-parameter meaning beyond the schema by explaining that filters combine with AND, that `group_by` is required for `op=count`, that `full=true` is heavy, and that pagination stops at 10000; however, it does not discuss many individual filter parameters, leaving the schema to carry most per-parameter detail.

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?

The description states a specific verb and resource — retrieving BODACC legal notices across all French companies — and names concrete use cases (receiverships by department, business sales by city, accounts filed, deregistrations). It also distinguishes itself from the sibling `fr_events(siren)`, which is explicitly recommended for notices of one known company, so the agent can choose correctly without opening the 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?

It gives explicit when-to-use guidance for each op mode (`search`, `count`, `get`), names the alternative for a narrower need (`fr_events`), and states operational rules such as counting before paging a large set and always bounding sweeps by date. The routing between search/count/get is unambiguous.

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

All Tulina toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources