Spanish company registry (BORME): companies, directors, links. Needs a free work-email account.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 4 tools
Each tool targets a distinct operation: fetching a single company profile, exploring company relationships, searching companies by name, and searching officers. No overlaps or ambiguity—an agent can unambiguously select the right tool for a given query.
All tool names follow a consistent verb_noun pattern: get_company, get_company_network, search_companies, search_officers. The verbs (get/search) and nouns (company/companies/officers/network) are uniform and predictable, making the API easy to navigate.
Four tools is well-scoped for a read-only registry server. It covers the essential operations: resolving entities (search_companies), retrieving full details (get_company), exploring relationships (get_company_network), and finding officers (search_officers). No redundancy or excessive sprawl.
The tool set covers the primary use cases for a Spanish company registry: searching and retrieving company data, querying ownership/board connections, and finding officer affiliations. The detailed descriptions address edge cases like renames, historical links, and status handling, indicating a thorough surface with no obvious gaps.
Get the BORME registry profile of one Spanish company: status, incorporation, current and former officers, sole shareholder (BORME records only sole-shareholder ownership), and — where available — NIF, share capital and registered address. NIF is never in BORME, and capital/address are missing for entities last amended before 2009; such values may be filled by web search and are flagged *_external: true (verify before relying on them). Officers are capped at the 25 most relevant (board/management before apoderados) with *_officers_total counts and an officers_truncated flag — large companies register hundreds of apoderados. Includes a mapasocietario.es link to cite. Resolves to exactly one entity by its current OR former name (company renames are handled) and returns not-found rather than a near-miss — if unsure of the exact name, call search_companies first. name is always the company's CURRENT name; if you queried an old name (or the result's name looks unrelated to your query), check former_names — it lists every prior registered name (registry-recorded 'Cambio de denominación social') before assuming this is the wrong company.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Company name (fuzzy-resolved to one entity). | |
| slug | No | A mapasocietario /empresa slug, e.g. 'acme-sl'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels. It discloses data limitations (NIF never in BORME, capital/address missing for old entities), flags for external data (*_external: true), officer caps (25 most relevant with truncation indicator), name handling (current vs former names), and not-found behavior. No contradictions with annotations (none exist).
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 relatively long but every sentence earns its place by providing essential context. It is front-loaded with the main purpose and then details edge cases and caveats. Could be more structured with bullet points, but as a free-text description it is well-organized and efficient.
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?
Given the tool's complexity (Spanish company registry with multiple fields, officer caps, name history, external data flags) and the absence of an output schema, the description covers all necessary aspects: what data is returned, what is missing, how to interpret flags, and how to handle name variations. It also mentions a mapasocietario.es link for citation, making the output fully actionable.
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% (both parameters described), but the description adds significant value: it explains that 'name' is fuzzy-resolved to one entity and that 'slug' is a mapasocietario-style identifier. It also clarifies that the returned 'name' field always holds the current name, which is not evident from the schema alone.
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 precisely states the tool retrieves the BORME registry profile of one Spanish company, listing specific data fields (status, incorporation, officers, etc.). It distinguishes from sibling tools like search_companies by explicitly directing the agent to use search_companies when unsure of the exact name, and from get_company_network by implication.
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 provides clear context: it resolves to exactly one entity, returns not-found instead of near-miss, and advises calling search_companies first if the name is uncertain. While it lacks explicit 'when not to use' statements, the guidance is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show companies directly connected to one Spanish company: via a shared board/management officer (shared_officer — apoderados and representatives are excluded as low-signal), via being owned by it (owns), or via owning it (owned_by). Answers 'is there a relationship between company X and company Y?'. shared_officer edges carry status: 'active' means the shared officer still holds the seat at the connected company, 'ceased' means the registry has inscribed their cessation there, and 'superseded' means no cessation was inscribed but a successor took the post. A 'ceased' or 'superseded' edge is a HISTORICAL link, do not report it as a current one. A top-level dissolved: true means the SUBJECT company is dissolved, so under the registry-faithful rule it has no officer currently in office and every shared_officer link is historical from its side, whatever each edge's own status says about the connected company. Active edges are listed first, so a truncated list keeps the live relationships. Resolves to one entity by current or former name (renames handled). Each connection links to mapasocietario.es.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Company name (fuzzy-resolved). | |
| slug | No | A mapasocietario /empresa slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds: it defines status values, marks 'ceased'/'superseded' edges as historical, explains how a top-level dissolved flag overrides edge-level status, and discloses ordering behavior (active edges first). It also notes fuzzy name resolution and renaming.
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 relatively long but every sentence earns its place: connection types, status semantics, historical caveats, ordering, resolution, and output links are all compactly organized and front-loaded with the core purpose.
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?
There is no output schema, so the description must explain return semantics; it does so in depth, including edge statuses, historical vs current classification, dissolved-company behavior, truncation ordering, and URL links. Together with the exhaustive behavioral notes, nothing essential is missing for correct invocation and interpretation.
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%, so the baseline is 3. The description adds useful context about fuzzy resolution and former names, but it does not clarify how name and slug relate, which one is preferred, or what happens if both or neither are supplied.
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: 'Show companies directly connected to one Spanish company', and enumerates the three edge types (shared_officer, owns, owned_by). This distinguishes it clearly from sibling tools like get_company or search_companies, which address single entities or searches.
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?
It gives a clear invocation context: use it to list direct corporate relationships for one company, and frames it as answering 'is there a relationship between company X and company Y?'. It does not explicitly name alternatives or state when not to use it, so it misses the top level of the rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Spanish companies by name in the BORME registry. Returns ranked matches (fuzzy — tolerant of typos) with status and a mapasocietario.es/empresa link to cite. A hit's name is always its CURRENT registered name; when the entity has been renamed, former_names lists its prior name(s) — a hit whose name differs from your query is not necessarily a wrong match, check former_names first. Use this first to resolve a company before get_company.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-25, default 10). | |
| query | Yes | Company name or partial name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: fuzzy matching tolerant of typos, returns status and link, and explains the name/former_names logic in detail (current name always present, former_names lists prior names, a hit with different name is not necessarily wrong). This is exceptionally transparent for a search tool.
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?
Four concise sentences, each earning its place: purpose, return details, behavioral nuance, and usage recommendation. No fluff or redundancy. Front-loaded with the core action, making it easy to parse quickly.
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?
Given the tool has only 2 parameters, no output schema, and no annotations, the description covers the essential behavioral details (fuzzy matching, result structure with name, former_names, link, status) and provides usage context. No gaps are apparent for an agent to understand and invoke this tool correctly.
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% with clear descriptions, so baseline is 3. The description adds the critical nuance that the search is fuzzy and tolerant of typos, which enhances understanding of the query parameter beyond the schema. This justifies a 4.
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 clearly states 'Search Spanish companies by name in the BORME registry', specifying the verb and resource. It distinguishes from sibling tool get_company by explicitly saying 'Use this first to resolve a company before get_company', making the purpose unambiguous.
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?
Includes explicit guidance: 'Use this first to resolve a company before get_company', indicating when to use this tool versus an alternative. Also implies it is for initial fuzzy lookups and advises checking former_names if the name differs from the query, aiding correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a person (administrator/director/apoderado) in the BORME registry and list the companies they are linked to. Answers 'is officer Z present in other companies?'. Returns ONE row per company, with roles listing every post held there. status (per row and per role) is 'active' when the appointment is still in force, 'ceased' once the registry has inscribed the cessation, and 'superseded' when the registry inscribed NO cessation but a successor was appointed to the post — common for auditors. 'ceased' and 'superseded' are BOTH closed seats: never describe either as a current directorship. 'unknown' means the registry gave no usable status, so do not assert the seat is either held or closed. Each role also carries date where the registry recorded one: the APPOINTMENT date for an active role, the CESSATION date for a ceased one, and for a 'superseded' role the successor's appointment date (NOT this person's exit — the registry inscribed none) — read it against that role’s status, never as a single “since”. When the officer held the seat before that (a revoke-and-reappoint, common in Spanish registries), the role also carries first_appointed — cite THAT for “since when”, not date — and history, every published act newest-first. Companies where the person is still in office come first, so a truncated list keeps the live ones. companies_total/companies_active count COMPANIES and seats_total counts appointment rows — cite the company figures when asked how many companies someone sits on. counts_are_lower_bound: true means more companies exist than could be read. Each row links to mapasocietario.es/empresa.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Person name or partial name. | |
| limit | No | Max rows (1-25, default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It exhaustively explains row semantics, role fields, three status values and their closed/unknown interpretations, per-status date meanings, first_appointed/history, ordering by live companies, count distinctions, lower-bound truncation, and row links. This is far beyond typical descriptions.
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?
Though long, every sentence delivers necessary semantic precision — status distinctions, date pitfalls, count definitions — that would otherwise cause errors. The core purpose is front-loaded, and details are organized by field in a readable, backtick-structured flow. No sentence 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?
For a tool with no output schema and no annotations, this description provides a near-complete behavioral contract: it covers all return fields, status meanings, date semantics, ordering, and edge cases like revoke-and-reappoint and truncation lower bounds. An agent can invoke it correctly with no external documentation.
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% with descriptions for both name and limit, so baseline is 3. The description adds value beyond the schema by explaining the behavioral effect of limit (live companies first, truncated list keeps them) and that name is partial-match, which aids correct invocation.
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 finds a person in the BORME registry and lists the companies they are linked to, framed by the exact question 'is officer Z present in other companies?'. This clearly differentiates it from company-centric siblings like search_companies.
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 context is clear — this is the tool for person-to-company lookups — but it never explicitly names sibling tools or states when to avoid them. The intended use is strongly implied rather than contrasted with alternatives, so it does not reach a 5.
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.
get_companyget_company_networksearch_companiessearch_officersRegistro Mercantil español (BORME) + subvenciones (BDNS) + contratos públicos (PLACSP), por empresa.
Official company and director data: search, profiles, filings, and name normalization.
Live data from 27 official national company registries. Unmodified. For KYB and due diligence.
Verified French company facts and corporate events from INSEE Sirene and BODACC.
Add one secure layer between your agents and this server.
