Skip to main content
Glama

Mapa Societario — Spanish Company Registry (BORME)

search_officers

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 and 'ceased' once the registry has inscribed the cessation — never describe a ceased role as a current directorship. Each role also carries date where the registry recorded one: the APPOINTMENT date for an active role, the CESSATION date for a ceased one — 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesPerson name or partial name.
limitNoMax rows (1-25, default 10).

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It comprehensively explains key behaviors: status field interpretation ('active' vs 'ceased'), date field semantics (role-specific, never a single 'since'), first_appointed for history, row ordering (active companies first), count semantics (companies vs seats), and the lower_bound flag. This is exceptional transparency for a tool with zero annotations.

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?

The description is comprehensive yet efficient, packing substantial behavioral detail into a dense paragraph. Every sentence adds value beyond the schema. However, it could benefit from slight structural breaks (e.g., bullet points) for longer descriptions, and it is somewhat long. A 4 reflects good conciseness with minor room for improvement.

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?

Given the tool has no output schema, the description fully compensates by explaining all return fields (status, date, first_appointed, history, companies_total, companies_active, seats_total, counts_are_lower_bound, links). The 2 required/optional parameters are well-documented in the schema. The description is complete for an effective tool invocation.

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 baseline is 3. The description adds meaning by clarifying that 'name' is for partial match and that 'limit' controls max rows (1-25, default 10) and its relation to ordering (truncated list keeps live ones). The schema already describes the parameters adequately, but the description provides additional nuance that justifies a score above baseline.

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 description clearly states the verb 'Find' and the resource 'person in the BORME registry', specifies the types of persons (administrator/director/apoderado), and distinguishes the tool's purpose from siblings by explicitly contrasting it with listing companies linked to an officer rather than searching for companies or getting company details.

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?

The description provides explicit when-to-use guidance: answering whether an officer is present in other companies. It also includes implicit context that this is for BORME registry data, and the sibling tool names (get_company, get_company_network, search_companies) further help differentiate usage without needing explicit exclusions.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: get_company retrieves a single company's profile, get_company_network shows connections between companies, search_companies finds companies by name, and search_officers finds a person and their linked companies. The descriptions explicitly guide when to use each, eliminating ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: get_company, get_company_network, search_companies, search_officers. The verbs 'get' and 'search' are used appropriately for retrieval vs. lookup, and the naming is predictable and clear.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of querying a Spanish company registry. The count covers the essential operations (search, details, network, officers) without being too few or excessive, each tool earns its place.

Completeness5/5

The tool set covers the core lifecycle of querying company registry data: searching for companies, retrieving detailed profiles, exploring corporate networks, and investigating officer connections. There are no obvious gaps for this read-only domain, and edge cases (former names, truncation, status) are well-handled.