Skip to main content
Glama
deenesjakoruzh
tbellicha

siret-mcp

by tbellicha
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

siret-mcp

MCP server for French company registry data. Ask about any French company by name, SIREN or SIRET and get back clean JSON — with every registry code already translated into plain French.

The official registry hands you "nature_juridique": "5710", "activite_principale": "62.01Z", "tranche_effectif_salarie": "12". An LLM handed that either guesses or hallucinates. This server hands it "Société par actions simplifiée (SAS)", "Programmation informatique", "20 à 49 salariés" — with the original code alongside so the answer stays checkable.

No API key. No account.

Install

Claude Code

claude mcp add siret -- npx -y siret-mcp

Cursor — ~/.cursor/mcp.json:

{
  "mcpServers": {
    "siret": {
      "command": "npx",
      "args": ["-y", "siret-mcp"]
    }
  }
}

Claude Desktop — claude_desktop_config.json, same block as Cursor.

Restart the client. You should see four tools.

Related MCP server: INSEE MCP Server

Try these

  • "Is SIREN 552100554 still active, and what legal form is it?"

  • "Find software companies in Loire-Atlantique with more than 20 employees."

  • "What does NAF code 43.22A mean?"

  • "Here's a SIRET from an invoice: 55210055400015 — verify it and tell me the registered address."

  • "List every establishment for this SIREN and flag which is the head office."

Tools

Tool

What it does

search_companies

Fuzzy search by name, trade name, acronym or officer. Filters: département, postal code, NAF code, active-only. Returns compact summaries.

get_company

Full profile from a SIREN (9 digits) or SIRET (14). Validates the Luhn checksum before spending a request.

list_establishments

All known sites for a SIREN, head office first, with a complete flag so you know if the list is exhaustive.

explain_code

Decodes NAF / legal form / workforce bracket / status. Offline, no API call.

Plus a siret://health resource exposing cache stats.

Design decisions worth knowing

Codes always travel with labels. Every coded field returns {code, label, exact, source}. exact: false means the label came from a fallback (a NAF section rather than the precise class), so a model can hedge appropriately instead of stating a guess as fact.

Absent fields are named, not nulled. Each profile carries a missing array. Given "workforce": null, a model will often invent a headcount. Given "missing": ["workforce"], it says the registry doesn't hold it.

Errors are returned, not thrown. Failures come back as JSON with a hint, so the model can retry or reformulate rather than dying mid-conversation.

Caching is the product, not an optimisation. The upstream rate-limits bursts. A 6h TTL cache (SIRENE_CACHE_TTL_MS) is what makes this usable in an agent loop that asks about the same company nine times.

Four tools, not twelve. Every extra tool costs the calling model context and adds a way for it to pick wrong.

Limitations

  • Code tables are partial. Full NAF rev. 2 is ~732 codes and catégorie juridique ~300; this ships the common ones plus a fallback that flags itself as approximate (exact: false).

  • Backed by recherche-entreprises.api.gouv.fr, not INSEE Sirene v3. No API key means this runs immediately. The trade-off is fewer fields and no exhaustive establishment listing.

  • Cache is in-process. Fine for a local stdio server, wrong for a hosted multi-tenant one.

Data & attribution

Data comes from the API Recherche d'Entreprises (DINUM), derived from INSEE SIRENE, under Licence Ouverte. Officer records may include a birth year. You are responsible for using the data lawfully.

Development

git clone https://github.com/tbellicha/siret-mcp.git
cd siret-mcp
npm install
npm run build
npm test                 # node:test, offline
npm run test:live        # hits the real API
npm run typecheck

Licence

MIT © 2026 tbellicha

Available Tools

4 tools
explain_codeDecode a registry codeA

Translate a NAF activity code, catégorie juridique (legal form), workforce bracket, or administrative status into plain French. Offline — no API call. Use this instead of guessing what a code means.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYese.g. '62.01Z', '5710', '12', 'A', 'PME'

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description must carry behavioral disclosure. It adds useful traits: the operation is offline ('no API call') and translates several code categories into plain French. It stops short of describing error behavior, output format, or what happens for unsupported codes, so it is adequate but not rich.

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?

Three short sentences with no redundancy. The primary action and scope are front-loaded, followed by an important execution detail (offline) and a useful usage cue. Every sentence earns its place.

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?

This is a minimal single-parameter tool with no output schema. The description covers the code categories, the offline behavior, and the high-level output ('plain French'), which is enough for an agent to decide and invoke correctly. Minor gaps like invalid-code handling do not significantly reduce completeness.

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% and the parameter already includes examples ('62.01Z', '5710', '12', 'A', 'PME'). The description adds semantic meaning by classifying these examples into NAF, legal form, workforce bracket, and administrative status, helping the agent understand what value to pass.

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 ('Translate') and a clearly bounded resource: NAF activity codes, legal forms, workforce brackets, and administrative statuses. This is immediately distinguishable from the sibling tools (search_companies, get_company, list_establishments), which are about company/establishment data rather than code decoding.

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

Usage Guidelines4/5

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

It gives clear context for when to use the tool ('Use this instead of guessing what a code means') and adds the offline constraint. However, it does not explicitly name alternatives or state when not to use it, though the sibling tools are sufficiently different that the guidance is adequate.

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

get_companyGet a company profile by SIREN or SIRETA

Full profile for one company from its SIREN (9 digits) or SIRET (14 digits). Returns legal form, activity, workforce bracket, headquarters, officers and certifications, all with plain-French labels. The missing array lists fields the registry does not hold — do not fill those in from memory.

ParametersJSON Schema
NameRequiredDescriptionDefault
identifierYesSIREN (9 digits) or SIRET (14 digits). Spaces are tolerated.

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It goes beyond a simple 'get' by listing the returned fields and, notably, explaining the `missing` array and warning not to fabricate missing data — important behavioral guidance. It could mention error handling or data freshness, but it is still substantially transparent for a read-only lookup.

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?

The description is concise, with the core purpose stated first and the important `missing`-array caveat in the second sentence. Every sentence adds value and there is no redundant or filler text.

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 a single-parameter lookup tool with no output schema, the description is complete: it explains what is returned, mentions the caveat about missing fields, and gives the identifier formats. The agent has enough context to call the tool correctly and interpret the response.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents the `identifier` parameter including formats and space tolerance. The tool description does not add parameter-level detail beyond that, so the baseline score of 3 is appropriate.

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 clearly states the tool retrieves a 'full profile for one company' by SIREN or SIRET, naming the returned data categories (legal form, activity, workforce, etc.). This distinguishes it from the sibling tools, especially search_companies, by emphasizing lookup by unique identifier rather than search.

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

Usage Guidelines4/5

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

The description makes the intended usage context clear: use this when you have a SIREN or SIRET and need a single company's full profile. It does not explicitly exclude the sibling tools or state when to prefer search_companies, but the identifier-based lookup is strongly implied.

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

list_establishmentsList a company's establishmentsA

All known sites (établissements) for a SIREN, headquarters first. Note: the registry returns matching establishments rather than an exhaustive list, so complete tells you whether every site is included.

ParametersJSON Schema
NameRequiredDescriptionDefault
sirenYesSIREN, 9 digits

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It meaningfully warns that the registry may return matching establishments rather than an exhaustive list and introduces the `complete` flag to indicate completeness. It also discloses the ordering rule (headquarters first), which adds useful non-obvious behavior.

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?

The description is two sentences with no filler. The core action and ordering rule are front-loaded, and the critical exhaustiveness caveat follows immediately. Every word earns its place.

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 one-parameter tool with no output schema or annotations, the description covers the main behaviors an agent needs: what is returned, the ordering, and the completeness caveat. It would be slightly more complete with explicit return-value details, but the description is largely sufficient for correct invocation.

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

Parameters3/5

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

The single parameter `siren` is already fully documented in the schema with 'SIREN, 9 digits', so schema coverage is 100%. The description repeats the SIREN concept without adding substantive new parameter detail, which aligns with the baseline score of 3.

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?

The description clearly states that the tool lists a company's establishments for a SIREN and notes that headquarters appear first. The resource and scope are specific, and the tool is clearly distinct from the sibling tools by focusing on sites rather than company records. However, it does not explicitly name or contrast itself with siblings like get_company or search_companies.

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?

The description implies the tool should be used when an agent needs establishment-level data for a given SIREN, rather than company-level details or search results. It does not explicitly provide when/when-not guidance or mention alternative tools.

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

search_companiesSearch French companiesA

Find French companies by name, trade name, acronym or officer name. Fuzzy — 'boulangerie dupont nantes' works. Returns compact summaries; call get_company for the full profile. Filters are optional and combine with AND.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo
limitNo
queryYesCompany name, trade name, acronym or officer name
naf_codeNoNAF rev.2 activity code, e.g. '62.01Z' for software development
departmentNoDépartement code, e.g. '44' for Loire-Atlantique, '2A' for Corse-du-Sud
active_onlyNoExclude companies that have ceased trading
postal_codeNoExact postal code

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses fuzzy behavior, compact summary output, and response-depth differences versus get_company. It does not mention pagination behavior or the active_only default, but the search-oriented nature makes the read-only behavior clear.

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?

Three efficient sentences front-load the search scope, provide a concrete example, route to the correct sibling, and explain filter semantics. No wasted words or repetition of the schema.

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?

The description covers expected behavior, output granularity, filter semantics, and an alternative tool. It lacks detail on pagination, defaults, and the role of list_establishments, but for a search tool with a small schema these are minor gaps.

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 71%, and the description adds semantics beyond the schema by showing that the query can be a fuzzy multi-word phrase and that filters are optional and AND-combined. Page and limit are not described in prose, but their names and defaults largely make their behavior clear.

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 action and resource: finding French companies by name, trade name, acronym, or officer name. It also clarifies fuzzy matching and explicitly distinguishes itself from get_company, which returns the full profile.

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

Usage Guidelines4/5

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

It gives clear guidance to call get_company when the full profile is needed, and states filters are optional and AND-combined. It does not mention when to prefer list_establishments or explain_code, but the search-versus-lookup distinction is reasonably clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedexplain_code
    • First observedget_company
    • First observedlist_establishments
    • First observedsearch_companies
Deploy Server
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

TDQS

A4.3/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clear, separate job: searching companies, retrieving a full company profile, listing establishment sites, and explaining registry codes. The cross-references between search_companies and get_company reinforce their complementary roles rather than creating ambiguity.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case verb_noun pattern: search_companies, get_company, list_establishments, explain_code. The naming is uniform, predictable, and accurately reflects each action.

Tool Count5/5

Four tools is well-scoped for a read-only French business registry lookup server. Each tool covers a distinct part of the workflow without unnecessary duplication or bloat.

Completeness5/5

The server covers the core lookup lifecycle: fuzzy search, full company profile retrieval, establishment enumeration, and code translation. Since this is a read-only registry service, CRUD operations are not expected, and there are no obvious dead ends in the workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers