Skip to main content
Glama

BORME API - Spain company registry

by com.bormeapi.mcp
OverviewDiscussionsAdmin

Company registry timeline

company_history
Read-onlyIdempotent

Get one company's BORME timeline: its published registry events within your plan's window.

Use it once the company is known (a slug from search_companies or company_by_nif); across many companies use search_events. A name is searched too: several matches return {ambiguous: true, candidates}, none returns {error, suggested_companies}.

Returns JSON {company_slug, total_events, first_seen, last_seen, truncated, next_offset, count, events} (as in search_events), with former_slugs for a merged company (an old slug returns the merged timeline) and plan_window on a limited plan. total_events, first_seen and last_seen cover the whole timeline in your window, not this page. To page, keep limit and order and pass next_offset as offset (at most 10000) until it is null.

Read-only; one request per call. Without an API key (X-API-Key header) only the last 7 days; basic covers 365 days, pro and risk the full history back to 2009. If all its events are outside your window, the refusal counts them.

Input Schema

NameRequiredDescriptionDefault
limitNoEvents per page, integer 1-200, e.g. 20 (default 100).
orderNo"desc" (default, newest first) or "asc" (oldest first), e.g. "asc" to start from the earliest event in your plan's window.desc
offsetNoEvents to skip, integer 0-10000 (default 0); pass the previous page's next_offset, e.g. 100.
companyYesCompany 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / company / description
      Previous value: -"Company slug (e.g. vaz-metales-sl) or name; a name falls back to a case-insensitive search (at least 3 letters or digits)."New value: +"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."
    • changedInput schema / properties / limit / description
      Previous value: -"Events per page, 1-200 (default 100)."New value: +"Events per page, integer 1-200, e.g. 20 (default 100)."
    • changedInput schema / properties / offset / description
      Previous value: -"Events to skip, 0-10000, in steps of limit."New value: +"Events to skip, integer 0-10000 (default 0); pass the previous page's next_offset, e.g. 100."
    • changedInput schema / properties / order / description
      Previous value: -"\"desc\" (default, newest first) or \"asc\" (oldest first)."New value: +"\"desc\" (default, newest first) or \"asc\" (oldest first), e.g. \"asc\" to start from the earliest event in your plan's window."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing the API-key tiering (7 days / 365 days / full history to 2009), merged-company slug behavior, plan_window, and that a refusal still counts events outside the window. Not a 5 only because retry/rate-limit behavior and error shapes beyond the ambiguous case are not covered.

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, then usage, then return shape and pagination, then constraints. Dense but every block carries information; the parenthetical field list is long yet justified because there is no output schema.

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?

With no output schema, the description fully specifies the return object, distinguishes whole-timeline aggregates from page contents, explains pagination termination (next_offset null), and states access limits — enough for correct invocation without further discovery.

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?

Schema coverage is 100%, so the baseline is 3; the description adds cross-parameter meaning the schema cannot express — keep limit and order constant while passing next_offset as offset, capped at 10000 — and clarifies that company accepts a slug or a name of 3+ characters.

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 first sentence states a specific verb (get timeline) and resource (one company's BORME registry events) with explicit scope (within your plan's window). It is clearly separable from search_events (many companies) and from search_companies/company_by_nif (which produce the slug).

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?

Gives explicit when-to-use ('once the company is known') and a named alternative for the other case ('across many companies use search_events'), plus input-shape guidance that a name is also accepted and what the ambiguous/no-match branches return.

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