Skip to main content
Glama
bormeapi

BORME MCP Server

by bormeapi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Company registry timeline

company_history
Read-onlyIdempotent

Retrieve one company's BORME registry timeline and published events within your plan window by slug or name, with paging and merged-company history.

Instructions

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 instead of a slug is searched: several matches return {ambiguous: true, candidates}, none returns {error}.

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 just 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 changedv2.1.1
    • 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. Addedv1.1.1
  3. Removedv1.1.0
  4. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint, but the description goes beyond them: per-call request count, plan-tier windows (7 days anonymous, 365 basic, 2009+ pro/risk), merged-company former_slugs behavior, truncation, the 10000 offset ceiling, and the fact that refusals still count out-of-window events. That is exactly the context an agent needs and no annotation provides.

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 purpose, then usage routing, then return shape, then paging, then auth windows — a logical order with dense but information-bearing sentences. Minor redundancy with the schema (offset max 10000, limit/order kept stable) keeps it just short of maximal.

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?

No output schema exists, so the description carries the return contract and does so fully: field list, the fact that total_events/first_seen/last_seen span the whole window rather than the page, truncated/next_offset paging, former_slugs, and plan_window. Combined with the auth tier explanation, an agent has everything needed to call and interpret it.

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, but the description adds real semantics: a name of at least 3 characters is searched case-insensitively and may return {ambiguous: true, candidates} or {error}, and paging requires keeping limit and order while passing next_offset as offset. It does not restate the limit range or enum-like order values, which is appropriate since the schema covers them.

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 — the BORME registry timeline for one company, events within the plan window — and immediately scopes it against search_events for the multi-company case. An agent can distinguish it from siblings like search_events and company_by_nif without opening any 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?

Explicitly names the precondition ('once the company is known (a slug from search_companies or company_by_nif)') and the alternative ('across many companies use search_events'). It also covers the name-instead-of-slug fallback and what the ambiguous/no-match responses look like.

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

Deploy Server

Other Tools