Skip to main content
Glama
abasmartinc

APIEmpresas MCP

by abasmartinc

Verificación KYB

verify_company
Read-onlyIdempotent

Run a KYB check on a Spanish company: confirm it exists and is active, match the declared name, and see if a signer is an administrator or sole partner, with pass/review/fail guidance.

Instructions

Verificación KYB de una empresa en una sola llamada: si existe y está activa, si el nombre declarado coincide y si una persona es administradora o el socio único, con alertas y una recomendación (pass / review / fail). Devuelve también la forma jurídica, el LEI, la matriz del grupo y el socio único. Plan Pro o superior; gasta 2 consultas. KYB check for a Spanish company.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cifYesCIF/NIF de la empresa española, p. ej. A46103834 (se aceptan espacios y guiones)
vatNotrue para comprobar además el NIF-IVA en VIES (operador intracomunitario)
nameNoRazón social que ha declarado el cliente, para comprobar que coincide
personNoNombre de la persona que firma, para comprobar si es administradora o socia única

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare the safe read-only, idempotent, open-world profile, so the bar is lower. The description still adds value beyond them: query cost (2 consultas), plan gating, and the categorical verdict output (pass/review/fail). It does not discuss rate limits or failure/error behavior, which keeps it out of 5 territory.

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 main purpose and the enumerated checks are front-loaded in the first sentence, with cost/plan and the returns trailing. Dense but every clause carries information; the trailing English fragment 'KYB check for a Spanish company' is mildly redundant with the opening.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 appropriately carries the return burden, naming legal form, LEI, group parent and sole partner alongside the verdict. Combined with cost and plan gating, an agent has enough to invoke correctly; it only lacks guidance on sibling selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, so each parameter (cif, vat, name, person) is already documented in the schema. The description reinforces the purpose of 'name' (matching the declared razón social) and 'person' (administrator/sole partner) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (verificar) and resource (empresa) and enumerates exactly what the check covers: existence/active status, name match, administrator/sole-partner check, plus alerts and a pass/review/fail recommendation. That is well beyond a tautology. However, it never distinguishes itself from the sibling get_company, which an agent would plausibly confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Offers real operational constraints – 'Plan Pro o superior; gasta 2 consultas' – which tell the agent the cost and eligibility. But there is no explicit when-to-use vs get_company or get_risk_profile, so the choice between siblings is left to inference.

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