Every active French company by SIREN: search, full fiche, and filed PDFs paid per fetch by agents.
Scored across 6 tools
Each tool targets a distinct action: search (by name/SIREN/SIRET/activity), get_company (full fiche by SIREN), get_document (PDF URL), and three account/billing tools. The only mild overlap is that search_companies also accepts a SIREN, so an agent holding a SIREN could plausibly choose search instead of get_company, but the descriptions make the intended split clear.
Four of six tools follow a clean verb_noun pattern (get_company, get_document, search_companies, top_up) with consistent snake_case. The deviations are 'balance' (bare noun) and 'signup' (bare verb), which break the pattern slightly but remain unambiguous.
Six tools is well-scoped for a company-registry API with a prepaid billing model: three data tools and three account tools, each earning its place with no filler. Nothing feels redundant or conspicuously absent from the count.
The surface covers discovery (search), detail (get_company), document retrieval, and the full account lifecycle (signup, balance, top_up), which is complete for a read-only registry. The minor gap is that there is no way to enumerate available documents for a company beyond what the fiche or get_document implies, and no explicit company-by-SIRET establishment endpoint.
Returns the balance and recent movements of the account whose API key the transport carries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful behavioral context by stating that the account is implicit via the transport API key and that it returns recent movements, but it does not explain how far back movements go, whether results are paginated, or what format the balance and movements take.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or filler language. It immediately states what is returned and how the account is scoped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read tool with no output schema, the description is largely complete: it identifies the implicit account source and summarizes the return content. It could be slightly more complete by describing the movement window or response shape, but the essential context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero input parameters, so the parameter semantics baseline is 4. The description correctly reinforces that no account identifier is needed because the API key determines the account, which is consistent with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns the account balance and recent account movements. It also clarifies that the account is selected by the API key carried by the transport, which distinguishes it from tools that take explicit company or document identifiers. It does not explicitly name or contrast with the sibling tool top_up, so it is clear but not maximally differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: an agent can infer this is the tool for checking the current balance and recent movements of the authenticated account. However, there is no explicit when-to-use guidance, no exclusions, and no mention of top_up or other alternatives for account-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. The full fiche as Markdown, by SIREN.
| Name | Required | Description | Default |
|---|---|---|---|
| siren | Yes | The 9 digit SIREN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden; it does disclose that the call is free and that output is Markdown, which are genuine behavioral facts. However, it omits error behavior (unknown SIREN), and whether any auth or rate limit applies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments with zero filler, and the most decision-relevant fact ('Free') is front-loaded. It is perhaps over-compressed — a few more words on failure mode would not have hurt — but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does partially compensate by naming the return format (full fiche as Markdown). Against a no-annotation, no-output-schema tool it still lacks error/edge-case behavior, leaving the agent with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is documented with a pattern and description in the schema. 'By SIREN' in the description merely restates the schema, adding no new semantic detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource ('company fiche'), the return format ('full fiche as Markdown'), and the key ('by SIREN'), which is a clear verb+resource+key combination. It implicitly distinguishes itself from search_companies (which would find a SIREN) but never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is 'Free', which tells the agent there is no cost but says nothing about when to prefer this over search_companies or get_document, nor what happens with an unknown SIREN. The agent must infer that a SIREN is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the URL of a PDF (statutes, decisions, annual accounts). Free when cached; costs $0.0004 when it must be fetched from the registry (INPI), paid from your balance (Authorization: Bearer) or with x402.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The registry PDF id, for acte and bilan | |
| kind | Yes | acte: statutes or decisions; bilan or comptes: annual accounts | |
| type | No | Accounts type (C, S, K...), for comptes | |
| depot | No | Filing date, for comptes | |
| siren | No | For comptes | |
| closing | No | Closing date of the accounts, for comptes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the caching model, the exact cost ($0.0004 on registry miss), the upstream source (INPI), and both auth paths (Bearer balance or x402). It omits failure modes — what happens if payment fails or the document does not exist — and whether the returned URL expires.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, zero filler, front-loaded with what is returned before the cost/auth details. Every clause adds information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter read tool with full schema coverage and no output schema, the description explains the return value (a URL) and the payment mechanics, which are the non-obvious parts. It stops short of describing error behavior or URL lifetime, which an agent would need before relying on the link.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter's meaning, valid patterns, and the kind enum with per-value notes. The description's parenthetical '(statutes, decisions, annual accounts)' merely restates the enum rather than adding selection guidance such as which parameters are required per kind.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — returns the URL of a PDF — and enumerates the document classes covered (statutes, decisions, annual accounts). This is clearly distinguishable from siblings like get_company or search_companies, which return company data rather than document links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving document PDFs but never states when to use it versus alternatives, nor the prerequisite chain (e.g., obtain id/siren from get_company first, then request acte vs comptes). Usage is inferable from the kind enum but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Finds companies by name, SIREN, SIRET or activity.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | Yes | A company name, SIREN, SIRET or activity, in French or English |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no result count limits, no pagination behavior, no note that the corpus is limited to French companies (that appears only in the title), and no rate/quota statement beyond the word 'Free'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the identifiers front-loaded and no padding. It is efficient, though the terseness borders on under-specification for a search tool with pagination.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should explain at least the result shape and page semantics; neither is covered. The agent knows what to pass but not what it will get back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% and the covered half (query) already documents that name, SIREN, SIRET or activity are accepted, so the description largely repeats it. The page parameter is undocumented in both the schema and the description, leaving a real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Finds') and resource ('companies'), plus the key identifiers accepted. It doesn't explicitly contrast with the sibling get_company, which retrieves a single company, so the search-vs-lookup distinction is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this instead of get_company, or what to do once a SIREN is known. 'Free' hints at a cost dimension but does not tell the agent anything about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a prepaid account and returns its API key. No human step and no payment is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | A name for the account, such as your agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description does real work: it confirms creation of a persistent resource, discloses that the response contains a credential (API key), and rules out payment/KYC gating. It omits important behavioral facts for a signup tool — whether repeated calls create duplicate accounts, whether the key can be retrieved later, and any rate or account limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and its return value, followed by the precondition that matters. No filler, nothing repeated from the schema or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description correctly compensates by naming the returned API key, and it covers the auth/payment preconditions that annotations would otherwise carry. Only the idempotency/duplicate-account question is left unanswered, which is a modest gap for a zero-required-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'label' parameter already carries a clear description with an example, and it is optional. The description adds nothing about the parameter, but with full schema coverage the baseline applies and the low parameter count leaves little to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('opens a prepaid account') plus the concrete payoff ('returns its API key'), which is exactly the outcome an agent needs to know. This is clearly distinct from the sibling tools balance/top_up, which operate on an account that already exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence implicitly positions this as the entry point by removing the two usual blockers ('no human step and no payment'), but there is no explicit when-to-use guidance, e.g. 'call this first, then top_up' or 'do not call if you already hold a key'. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds credit to your account. Without a payment it answers how to pay (x402, MPP, card link); pay with any listed option and call it again with the payment.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | The USD amount to add, as a decimal string such as "5" or "0.50" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose a non-obvious two-phase payment handshake and the accepted payment rails (x402, MPP, card link). It omits other important traits: whether the operation is idempotent, what happens on payment failure, whether credit is refundable, or minimum/maximum amounts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler, and the core action is front-loaded before the payment-flow detail. Every clause carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool this covers the action and the unusual payment flow, which is the main thing an agent needs. But it instructs the caller to 'call it again with the payment' while the schema exposes only 'amount', leaving a real ambiguity about how payment is actually conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, so the baseline is 3. The description adds no meaning beyond the schema (no constraints, bounds, or format guidance for 'amount'), and indeed introduces a payment concept the schema does not model.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Adds credit to your account'), which is clear enough to distinguish it from the read-only sibling 'balance'. It never explicitly names the sibling it complements, so differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines a two-step protocol—call without payment to learn how to pay, then call again with payment—which is useful implied usage guidance. However, it gives no guidance on prerequisites (e.g., checking 'balance' first), no when-not-to-use conditions, and is ambiguous about how the payment is supplied given the schema exposes only 'amount'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
balanceget_companyget_documentsearch_companiessignuptop_upFrance Sirene company data (company-level, change tracking) for AI agents.
French company data from public registers (Sirene, RNE, BODACC) and French legal notices.
Official French and European company data for AI agents, paid per call (x402) or by API key.
Search French companies: financials, directors, ownership, M&A and insolvency events.
Add one secure layer between your agents and this server.
