Skip to main content
Glama

fr_search

Read-only

Search French companies — returns identity, HQ, NAF, employees, directors, finances, matched establishments. At least one filter required.

⚠️ Enumeration capped at ~10,000 (page × per_page, per_page ≤ 25): the API truncates without error beyond that. To enumerate a large set exhaustively ("all companies in sector X in region Y" when there are tens of thousands), switch to fr_stock_search (SIRENE parquet, no cap). This tool remains the right choice for searching/qualifying (indexed, fast, rich filters) as long as the result stays under ~10k.

⚠️ Geographic filters (departement, code_postal, commune) match ANY establishment, NOT only the head office (siège). To target companies whose SIÈGE is in a département, use fr_stock_search(departement=…, sieges_only=True).

⚠️ ca_min/ca_max do NOT qualify a company's size. The filter applies to an amount whose unit varies by filing (euros or thousands, sometimes from one year to the next for the same company) and whose 0 means "not declared" — so any upper bound brings back en masse companies whose revenue is unknown, which biases toward the LARGEST. Measured: tranche_effectif_salarie=51,52,53 & ca_max=400000 returns 12 results, all large companies, no true positive. To target by size, use tranche_effectif_salarie or categorie_entreprise. The finances block of the results carries the same caveats, flagged line by line (alerte) — see finances_avertissement.

Spoken legal forms: people say "the SCI Untel", but the register rarely writes the form into the name — so a query like "SCI ASC" only matches companies literally NAMED that. On page 1, this tool detects such a prefix and ALSO runs the name alone filtered on that form, appending the extra hits (flagged matched_by="legal_form") and reporting what it did under legal_form_retry.

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_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
nafNoNAF activity codes, comma-separated (e.g. "62.01Z,62.02A").
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
idccNoIDCC codes (conventions collectives), comma-separated.
pageNo1-based page number.
queryNoFull-text search (company name, SIREN, brand…).
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
ca_maxNoMaximum turnover — ⚠️ NOT reliably in euros, see below.
ca_minNoMinimum turnover — ⚠️ NOT reliably in euros, see below.
_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.
communeNoINSEE commune code (COG, 5 digits — e.g. "67482" for Strasbourg). NOT a city name (a name raises "valeur non valide" — the API's French error message). For a place, pass `code_postal`, or use `fr_stock_search` (which resolves enseigne/commune by code too).
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
per_pageNoPage size (max 25).
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
employeesNoEmployee-range codes (INSEE TEFEN) of the unité légale, comma-separated.
code_postalNoPostal code (e.g. "75001").
departementNoDepartment code (e.g. "75").
nature_juridiqueNoINSEE legal-form codes, comma-separated (e.g. "6540" for SCI, "5710" for SAS). Exact 4-digit codes only — an invalid value makes the API answer with the full list of valid ones.
categorie_entrepriseNoINSEE size category — "PME", "ETI" or "GE".

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, and the description adds behavior the agent could not otherwise know: results truncate silently past page × per_page ≈ 10,000 with no error. It discloses the surprising semantics of geographic filters (matching any establishment, not just the siège), the unit ambiguity and zero-means-undeclared problem in ca_min/ca_max, and the page-1 legal_form_retry side effect with matched_by flags.

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 purpose and the mandatory-filter rule are front-loaded, and the warning blocks are visually separated so an agent can scan them. It is long, but each warning carries a distinct, actionable trap; the only mild redundancy is restating the 'not reliably in euros' point that the schema fields already flag.

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 18-parameter search with no output schema, the description covers what comes back (including the finances block and its alerte lines), the hard result cap, the geo-filter semantics, the ca caveats, and the legal-form retry behavior. Nothing an agent needs to call this correctly or interpret the response is missing.

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 100%, so the baseline would be 3, but the description supplies meaning the schema only gestures at: ca_min/ca_max are explicitly declared unreliable for company size (mixed euro/thousand units, 0 = not declared, upper bounds bias toward the largest firms). It also explains that departement/code_postal/commune match any establishment rather than the head office, and that spoken legal forms are retried separately.

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 opening sentence gives a concrete verb and resource ('Search French companies') and enumerates the returned blocks (identity, HQ, NAF, employees, directors, finances, matched establishments). It also declares the hard constraint 'At least one filter required', so the agent knows the tool's shape 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?

Explicitly routes between this tool and `fr_stock_search`: stay here for indexed, fast, rich-filter searching while results remain under ~10k, switch there for exhaustive enumeration with no cap. It adds a second routing rule for targeting sièges ('use fr_stock_search(departement=…, sieges_only=True)') and for size targeting (use tranche_effectif_salarie or categorie_entreprise instead of ca filters).

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