Skip to main content
Glama

Fuentio: UK, France & Spain company data from official registries

Look up a company by official ID

lookup_company
Read-onlyIdempotent

Look up one company in its official register by ID: status, address, legal form, activity, source and check date. Use it when you have an official ID. Don't use it with a name: call search_companies first. Inputs: country FR or ES or GB; identifier. FR: SIREN 441639465, SIRET 44163946500091, VAT FR63441639465, LEI 969500F7JLTX36OUI695. ES: Registro Mercantil sheet VI-23266, LEI 549300EEJH4FEPDBBR25 (no NIF/CIF). GB: company number 00445790, LEI 2138002P5RNKC5W2JZ46. Optional: id_scheme (if ambiguous), format (json, csv, tsv, markdown, html, xml, ndjson; xlsx or parquet as a 24 h link). Returns: the record, a one-line summary, meta with source, source_url, last_verified_at. Limits: 1 unit (also a valid ID not found); keyless 20/day. France: insolvency from BODACC since 2008. BODACC events and dated capital. Public contracts won since 2024 (DECP, weekly). Spain: BORME acts since 2 January 2009. Every BORME act as an event. UK: no officers or PSCs. ISINs and BICs from GLEIF, by LEI. No person's name in any answer. For KYB steps, supplier checks, due diligence: SIREN, RCS, Annuaire des Entreprises, société; BORME, Registro Mercantil, empresa, sociedad; Companies House, company number, Ltd, plc, LLP.

Input Schema

NameRequiredDescriptionDefault
detailNosummary: a few key fields; standard (default): the record, long lists shortened; full: everything.standard
formatNoAnswer format: json (default); csv, tsv, markdown, html (table), xml or ndjson come back inline, one row per company with source and fetched_at; xlsx or parquet as a download link valid 24 hours. Same units; search takes limit (up to 100 rows) with a non-json format.json
countryYesISO country code: FR or ES or GB.
id_schemeNoOptional: force the ID type when it is ambiguous.
identifierYesOfficial ID. FR: SIREN (9 digits), SIRET (14) or VAT (FR + 11). ES: Registro Mercantil sheet, e.g. VI-23266. GB: Companies House company number, e.g. 00445790.

Output Schema

NameRequiredDescriptionDefault
dataYesThe record; a few key fields with detail=summary (when enabled); null when meta.export holds it.
metaYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"ISO country code: FR or ES."New value: +"ISO country code: FR or ES or GB."
    • changedInput schema / properties / country / enum
      Previous value: -[
      -  "FR",
      -  "ES"
      -]New value: +[
      +  "FR",
      +  "ES",
      +  "GB"
      +]
    • changedInput schema / properties / id_scheme / anyOf
      Previous value: -[
      -  {
      -    "enum": [
      -      "FR_SIREN",
      -      "FR_SIRET",
      -      "EU_VAT",
      -      "LEI",
      -      "ES_RM_HOJA",
      -      "ES_NIF"
      -    ],
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "FR_SIREN",
      +      "FR_SIRET",
      +      "EU_VAT",
      +      "LEI",
      +      "ES_RM_HOJA",
      +      "ES_NIF",
      +      "GB_COMPANY_NUMBER"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / identifier / description
      Previous value: -"Official ID. FR: SIREN (9 digits), SIRET (14) or VAT (FR + 11). ES: Registro Mercantil sheet, e.g. VI-23266."New value: +"Official ID. FR: SIREN (9 digits), SIRET (14) or VAT (FR + 11). ES: Registro Mercantil sheet, e.g. VI-23266. GB: Companies House company number, e.g. 00445790."
    • changedInput schema / properties / identifier / examples
      Previous value: -[
      -  "441639465",
      -  "VI-23266"
      -]New value: +[
      +  "441639465",
      +  "VI-23266",
      +  "00445790"
      +]
  2. Changed1 schema field changed
    • addedOutput schema / $defs / Name / properties / privacy_note
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Privacy Note"
      +}
  3. Changed2 schema fields changed
    • addedOutput schema / $defs / LookupMeta / properties / freshness
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "source_published_at, retrieved_at, last_verified_at, from_cache, stale and the rule applied.",
      +  "title": "Freshness"
      +}
    • addedOutput schema / $defs / LookupMeta / properties / outcome
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "verified, partial, unverified, status_unknown, not_found, not_covered, ambiguous, stale or source_unavailable: https://api.fuentio.com/docs/outcomes",
      +  "title": "Outcome"
      +}
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover safety (readOnly/idempotent/non-destructive), yet the description adds genuinely new behavior: billing ('1 unit, also a valid ID not found'), a rate limit ('keyless 20/day'), and per-country coverage ceilings (BODACC since 2008, BORME since 2 Jan 2009, no UK officers or PSCs). The privacy rule ('No person's name in any answer') is a non-obvious output constraint that is not in 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 and the sibling alternative are front-loaded in the first two sentences, and the Inputs/Limits blocks are scannable. It runs long, though, and the closing keyword list ('SIREN, RCS, Annuaire des Entreprises, société; BORME...') is closer to search-term padding than operating instruction.

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 five-parameter lookup with an output schema, everything an agent needs to call it correctly is present: which countries, accepted ID schemes, format trade-offs including the 24-hour link for xlsx/parquet, cost and quota, and per-registry coverage gaps. The return-shape note is redundant with the output schema but not harmful.

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 baseline is 3 and the description largely restates identifier formats already documented per parameter. It does add a useful ambiguity signal ('id_scheme if ambiguous'), but it also says ES has 'no NIF/CIF' while the id_scheme enum still offers ES_NIF, which muddies rather than clarifies that parameter.

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?

States a specific verb and resource ('Look up one company in its official register by ID') and enumerates what comes back (status, address, legal form, activity, source, check date). It also draws the boundary against the sibling search_companies by requiring an official ID rather than a name, so the agent can pick without opening schemas.

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?

Explicit when-to-use ('when you have an official ID'), explicit when-not ('Don't use it with a name: call search_companies first'), and it names the correct alternative. It further maps real-world colloquialisms (SIREN, RCS, BORME, Companies House, Ltd, plc) to the tool, reducing misrouting.

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.