Skip to main content
Glama

HelpMyAgent

by io.github.helpmyagent
OverviewDiscussionsAdmin

French Company Verification

company_fr_verify

Verifies the existence and current status of a French company or establishment from a SIREN or SIRET. Use when: You have a French SIREN or SIRET and need to confirm that the company or establishment exists in the public source. You need its current administrative active/closed status before another automated step. Avoid when: You only have a company name and need to discover its identifier; use company/fr/search. You need directors, financials, legal risk or compliance checks; use the corresponding specialized endpoint. Limitations: This verifies public administrative existence and status only; it is not KYC, identity assurance or beneficial-owner verification. Returned fields depend on what the public company source exposes for the identifier. Price: 0.005 USD per call via x402. Paid-call behavior: source records are not modified, but a successful invocation can consume the advertised x402 payment; the payment-required challenge is free, and repeating the tool after a completed paid invocation may require a new payment. Accepted x402 networks: eip155:8453, xrpl:0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
identifierYes9-digit SIREN or 14-digit SIRET

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityYesStructured value returned for “city” as defined by this API contract.
nameYesPublicly available company, person, buyer or record name for this result.
sirenYesNormalized 9-digit French SIREN when available.
siretYesNormalized 14-digit French SIRET when available.
activeYesCurrent public administrative active status when available.
existsYesWhether the requested company or public record was found in the checked source.
addressYesStructured value returned for “address” as defined by this API contract.
identifierYesIdentifier supplied for the request, echoed in normalized form when applicable.
postal_codeYesStructured value returned for “postal code” as defined by this API contract.
activity_codeYesStructured value returned for “activity code” as defined by this API contract.
identifier_typeYesNormalized identifier type, such as SIREN or SIRET when applicable. (allowed values: siren, siret).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changed
    • addedInput schema / description
      Added value: +"Structured input parameters for the company/fr/verify API."
    • addedOutput schema / description
      Added value: +"Structured result returned by the company/fr/verify API."
    • addedOutput schema / properties / active / description
      Added value: +"Current public administrative active status when available."
    • addedOutput schema / properties / activity_code / description
      Added value: +"Structured value returned for “activity code” as defined by this API contract."
    • addedOutput schema / properties / address / description
      Added value: +"Structured value returned for “address” as defined by this API contract."
    • addedOutput schema / properties / city / description
      Added value: +"Structured value returned for “city” as defined by this API contract."
    • addedOutput schema / properties / exists / description
      Added value: +"Whether the requested company or public record was found in the checked source."
    • addedOutput schema / properties / identifier / description
      Added value: +"Identifier supplied for the request, echoed in normalized form when applicable."
    • addedOutput schema / properties / identifier_type / description
      Added value: +"Normalized identifier type, such as SIREN or SIRET when applicable. (allowed values: siren, siret)."
    • addedOutput schema / properties / name / description
      Added value: +"Publicly available company, person, buyer or record name for this result."
    • addedOutput schema / properties / postal_code / description
      Added value: +"Structured value returned for “postal code” as defined by this API contract."
    • addedOutput schema / properties / siren / description
      Added value: +"Normalized 9-digit French SIREN when available."
    • addedOutput schema / properties / siret / description
      Added value: +"Normalized 14-digit French SIRET when available."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses critical paid-call behavior: source records are not modified, successful invocations can consume x402 payment, the challenge is free, and repeated calls may require new payment. Limitations and non-KYC disclaimers further set expectations. This is valuable context the annotations do not provide.

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 front-loaded with purpose, then structured into labeled Use/Avoid/Limitations/Price/Paid-call behavior sections. Every sentence carries necessary information for correct use, and the format is scannable for an agent.

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 presence of an output schema and the single identifier parameter, the description covers all essential operational context: what it verifies, when not to use it, limitations, pricing, payment side effects, and accepted networks. Nothing needed for correct invocation is missing.

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 input schema already provides a pattern and description for the identifier parameter (9-digit SIREN or 14-digit SIRET), so schema coverage is 100%. The tool description adds no new parameter-level detail beyond restating the identifier type. Baseline 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 states a specific verb and resource: 'Verifies the existence and current status of a French company or establishment from a SIREN or SIRET.' It clearly distinguishes the tool from siblings that provide other specialized data, and the identifier scope (SIREN/SIRET) is unmistakable.

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?

The description provides explicit 'Use when' and 'Avoid when' guidance. It names the alternative for name-based discovery (company/fr/search) and points to specialized endpoints for directors, financials, legal risk, and compliance. This gives an agent clear routing criteria.

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

All HelpMyAgent 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