Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

fr_get

Read-only

Full company profile by SIREN: identity (siège, directors, NAF code with its rév. 2 label activite_principale_libelle, employees) + 7 top financial ratios from the latest INPI/BCE filing

  • recent BODACC legal events. Aggregates 3 open data sources in parallel. Use this as first call when investigating a company.

⚠️ latest_bilan = LITERALLY the last filed fiscal year, which does not necessarily carry revenue — a simplified balance sheet has no "total revenue" box. For revenue, go back through the years: fr_bilans(siren) returns them from most recent to oldest with their chiffre_d_affaires, and you must take the first one that carries one. Do not conclude "no revenue" from latest_bilan alone. Seen on Norauto: last year (simplified) silent, €974,718,176 the year before.

⚠️ identity.etat_administratif is the SIRENE register's state, which does NOT follow collective proceedings: a company whose liquidation was closed years ago can still read "A". When the BODACC events read here (the 10 most recent) carry a judgment closing a liquidation, procedure_collective_cloturee gives it (nature, date) and etat_administratif_avertissement flags the contradiction. Older proceedings: fr_events(siren, famille="collective").

BATCH: pass sirens=[…] (max 20 per call, chunk beyond) to qualify a LIST in one call — returns {profiles: […], count}, one profile per SIREN in input order; per-SIREN failures degrade to {error, siren} without failing the batch. For bulk HQ addresses only (no financials), fr_stock_enrich is cheaper.

latest_bilan is trimmed to 7 B2B-relevant ratios (CA, résultat net, EBE, marge EBE, autonomie financière, taux d'endettement, liquidité). For the full ratio set, call fr_bilan(siren, date_cloture).

Resilient to per-source failures: a timeout or error on INPI (bilan) or BODACC (events) degrades gracefully — the available blocks are returned and the failing sources are listed under partial_errors. Only an identity failure (the keystone source) fails the whole call.

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

Input Schema

NameRequiredDescriptionDefault
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
sirenNoSIREN number (9 digits) — single-company mode.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
sirensNolist of SIREN numbers (max 20) — batch mode. Give one OR the other, not both.
_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.
_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

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the real burden and does: it discloses graceful degradation per source, that partial_errors is populated on failure, that only identity failure aborts the call, and that batch per-SIREN failures degrade to {error, siren} without failing the batch. It also surfaces two non-obvious data traps (latest_bilan may lack revenue; etat_administratif does not follow collective proceedings) with the flag fields that expose them — information an agent could not obtain from any structured field.

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 is front-loaded in the first line, then warnings, then batch, then ratio trimming, then resilience — a coherent order. It is long for a 7-parameter tool and the Norauto anecdote is more illustration than instruction, but nearly every sentence carries operational consequence, so little is genuinely 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?

No output schema exists, yet the description explains the returned blocks, the batch return shape, the partial_errors and procedure_collective_cloturee fields, and the failure model. For a three-source aggregator with non-obvious data pitfalls, nothing an agent needs to call it correctly or interpret results 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 coverage is 100%, so the schema already documents siren, sirens, and the _org/_group/_run_id context params, establishing a baseline of 3. The description goes beyond it by stating the max-20 batch limit, the chunking remedy, the return shape {profiles, count} with one profile per SIREN in input order, and the per-item error degradation — semantics not present in the schema.

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?

Opens with a specific verb and resource ("Full company profile by SIREN") and enumerates the three constituent blocks: identity, 7 financial ratios, BODACC events. It also distinguishes itself from fr_bilans, fr_events, fr_bilan and fr_stock_enrich, so an agent can separate it from adjacent siblings 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?

Gives an explicit routing rule ("Use this as first call when investigating a company") and names alternatives with the exact condition that selects each: fr_bilans for multi-year revenue, fr_events(famille="collective") for older proceedings, fr_bilan for the full ratio set, fr_stock_enrich for bulk HQ addresses only. Batch vs single mode is also spelled out with the 20-per-call limit and chunking instruction.

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