BORME API - Spain company registry

A company's signals

company_signals

Read-onlyIdempotent

Get one company's derived signals within your plan's window, newest first: the REST API's GET /v1/companies/{slug}/signals.

Use it for one company's ownership changes, mass exits, insolvency declarations and the like; across all companies use recent_signals. A name is searched as in company_history: several matches return {ambiguous: true, candidates}, none returns {error, suggested_companies}.

Returns JSON {company_slug, total, count, next_offset, signals: [{event_id, signal_type, date, company_slug, company_name, province, details}]}, with former_slugs for a merged company (every slug is read), and plan_window or hidden_by_plan when your plan's window applied: relay their notes. AEAT_DEBTOR: say the company was on the list published on that date, never that the debt is outstanding. count 0 is not proof of good health.

Read-only; one request per call. Needs the pro plan or higher; key in the X-API-Key header (https://bormeapi.com/account).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "company": "<company>"
    },
    "name": "company_signals"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Signals per page, integer 1-200, e.g. 20 (default 50).
`offset`	No	Signals to skip, integer 0-10000 (default 0); pass the previous page's next_offset, e.g. 50.
`company`	Yes	Company slug, e.g. vaz-metales-sl (from search_companies), or a name of at least 3 letters or digits, e.g. "Mercadona", searched case-insensitively as in company_history.
`date_to`	No	Latest signal date, inclusive, YYYY-MM-DD, e.g. 2026-10-31. Optional.
`date_from`	No	Earliest signal date, inclusive, YYYY-MM-DD, e.g. 2024-11-01. Optional; moved up to the start of your plan's window when earlier (plan_window says so).
`signal_types`	No	Optional list; each one of INSOLVENCY_FILED, ACCORDION, MASS_EXIT, OWNERSHIP_CHANGE, DISTRESS_COMBO, PHOENIX, ADDRESS_CLUSTER, AEAT_DEBTOR, PUBLIC_CONTRACT_AWARD, e.g. ["OWNERSHIP_CHANGE", "MASS_EXIT"]; omit for all types your plan covers.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description goes well beyond them: plan-window truncation with plan_window and hidden_by_plan fields, "one request per call", ambiguous-name and no-match return branches, and how merged companies are handled via former_slugs. It also gives a domain constraint that cannot be inferred from structure (AEAT_DEBTOR must be reported as historical listing, not outstanding debt).

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?

Front-loaded with the purpose and then the routing alternative, with each subsequent sentence carrying new information (return shape, plan caveats, auth). It is dense and the line breaks split clauses awkwardly ("A name is searched as in / company_history"), but nothing is redundant.

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?

There is no output schema, and the description supplies the full response envelope plus the conditional fields (former_slugs, plan_window, hidden_by_plan) an agent will encounter. Combined with the mutation-free annotations and complete param docs, 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.

Parameters4/5

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

With 100% schema coverage the schema already documents all six parameters, so the baseline would be 3. The description still adds meaning: company names are searched as in company_history (tying to a familiar sibling's semantics) and date_from is silently raised to the plan window start when earlier, which is not stated in the schema.

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?

Opens with a specific verb, resource and ordering ("Get one company's derived signals within your plan's window, newest first") and even maps to the REST endpoint GET /v1/companies/{slug}/signals. It explicitly names the sibling recent_signals for the all-companies case, so an agent can distinguish the two without reading either schema.

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 (one company's ownership changes, mass exits, insolvency declarations) and an explicit alternative for the opposite case ("across all companies use recent_signals"). It also states the prerequisite that shapes eligibility: pro plan or higher, key in the X-API-Key header.

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

All BORME API - Spain company registry tools Inspect

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

Need Help?