Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@veridex-mcp verify Spanish company CIF A58818501 and explain its risk score"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP (Model Context Protocol) para VERIDEX: verificación de empresas españolas por CIF contra el BORME, con puntuación de riesgo explicable y el ciclo de pago x402 resuelto paso a paso.
Una vez configurado, cualquier agente (Claude Desktop, Cursor, VS Code, Claude Code…) puede descubrir y usar la verificación sin que tú escribas una línea de HTTP.
Agente ──MCP (stdio)──▶ veridex-mcp ──HTTPS──▶ https://api.veridexia.es/v1/verify
│
└── no firma pagos: entrega el reto x402 y espera
un X-PAYMENT que produzca una wallet tuyaEs un cliente MCP fino sobre la API pública de VERIDEX: tres herramientas, tipos explícitos, errores tipados y el reto de pago x402 decodificado para que el agente sepa exactamente cuánto cuesta, en qué red, en qué activo y a qué dirección.
No es una wallet. Este servidor no firma, no custodia claves y no envía transacciones. No puede pagar por ti — y eso es deliberado: un servidor MCP que pudiera mover fondos en nombre del usuario sería una wallet sin dueño. Lo que hace es entregar al agente una petición de pago completa y exacta, y dejar que la settle una wallet que tú controlas.
Tampoco modifica la API: es un consumidor puro de api.veridexia.es.
Related MCP server: eu-verify
Herramienta | Argumentos | Coste | Qué devuelve |
|
| 0,20 USDC (primera llamada devuelve 402) | Datos registrales, situación en el BORME, actos recientes y scoring 0–100 explicable |
| — | Gratis | Precio, red, activo, dirección de cobro y endpoints, leídos de |
| — | Gratis | Estado de la API, uptime y demanda de hoy (peticiones y agentes únicos) |
verify_company_by_cif// Entrada
{ "cif": "A58818501", "x_payment": null, "idempotency_key": null }
// Salida (ok = true)
{
"ok": true,
"cif": "A58818501",
"company": {
"cif": "A58818501",
"name": "…",
"legal_form": "Sociedad Anónima",
"status": "active",
"status_label": "Activa sin incidencias",
"province": "Málaga",
"incorporation_date": "2015-10-02",
"last_borme_deposit": "2025-08-09",
"administrator": "…",
"share_capital_cents": 4500000,
"insolvency_published_on": null
},
"risk": {
"value": 15, // 0 = más seguro, 100 = más arriesgado
"band": "low", // low | medium | high | critical
"reasons": ["…"],
"signals": [{ "code": "status_active", "points": 15, "description": "…" }],
"confidence": "high",
"assurance": "high", // cuánto se SABE, no cuánto de malo es
"conclusive": true
},
"recent_acts": [{ "date": "2026-08-28", "section": "Sección Primera", "description": "…" }],
"mock": false,
"provenance": { "source": "prometiam", "fetched_at": "…", "from_cache": false, "confidence": "high" },
"payment": null,
"error": null,
"guidance": ""
}risk.assurance es el campo que más se malinterpreta: assurance: "none" con
value: 0 significa no sabemos nada de esta empresa, no esta empresa es segura. El
servidor lo dice explícitamente en guidance cuando ocurre.
Requiere Python 3.10+.
pip install -e mcp-serverEso instala el paquete veridex-mcp en modo editable junto con sus dependencias
(mcp>=1.9,<2 y httpx), y deja disponible el ejecutable veridex-mcp.
Comprueba que arranca:
veridex-mcp --version
python -m veridex_mcp --version # equivalente, más portable en WindowsWindows: si el host lanza el servidor con un intérprete concreto, usa
python -m veridex_mcpcon la ruta completa al Python del entorno virtual. Es la forma más fiable de que el proceso correcto arranque.
Variable | Por defecto | Para qué |
|
| Apuntar a un backend local o a un despliegue propio |
| (sin definir) | Reservado para un tier premium futuro. No es necesario: el endpoint de pago no pide credenciales, el pago es la credencial |
|
| Timeout de cada petición HTTP |
Edita el fichero de configuración:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"veridex": {
"command": "python",
"args": ["-m", "veridex_mcp"],
"env": {
"VERIDEX_API_URL": "https://api.veridexia.es",
"VERIDEX_TIMEOUT_SECONDS": "30"
}
}
}
}Si prefieres el ejecutable instalado en lugar del módulo:
{
"mcpServers": {
"veridex": {
"command": "veridex-mcp",
"args": [],
"env": { "VERIDEX_TIMEOUT_SECONDS": "30" }
}
}
}Cierra Claude Desktop por completo (icono de bandeja incluido) y vuelve a abrirlo. Los
servidores MCP se lanzan al arrancar; el icono de herramientas aparecerá junto al cuadro de
texto. Hay un ejemplo listo para copiar en el fichero claude_desktop_config.json, en la
raíz del paquete.
Configuración global en ~/.cursor/mcp.json, o por proyecto en .cursor/mcp.json:
{
"mcpServers": {
"veridex": {
"command": "python",
"args": ["-m", "veridex_mcp"]
}
}
}VS Code 1.102+ usa .vscode/mcp.json (la clave es servers, no mcpServers):
{
"servers": {
"veridex": {
"type": "stdio",
"command": "python",
"args": ["-m", "veridex_mcp"]
}
}
}También puedes ejecutarlo desde la paleta de comandos con MCP: Add Server. Comprueba
con veridex-mcp --transport streamable-http y el
MCP Inspector si quieres ver las
herramientas sin un agente de por medio.
x402 es un protocolo de pago sobre HTTP: en lugar de una API key, se paga por petición. La
primera llamada a un recurso de pago devuelve HTTP 402 Payment Required con un reto
que describe exactamente cuánto, dónde y en qué activo. Se settle ese reto con una wallet,
se repite la petición con el resultado en la cabecera X-PAYMENT, y el recurso responde con
el contenido.
Con este servidor MCP el flujo tiene cuatro pasos:
Llama a get_veridex_info, que lee https://api.veridexia.es/.well-known/x402. Obtiene:
{
"network": "base",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"asset_symbol": "USDC",
"asset_decimals": 6,
"pay_to": "0x2bDc11AEB751EC845aE5fED5bbf7c73BF6D0C4E3",
"price": "0.20 USDC"
}verify_company_by_cif sin pagoLa API responde 402:
POST /v1/verify HTTP/1.1
Host: api.veridexia.es
Content-Type: application/json
{"cif": "A58818501"}HTTP/1.1 402 Payment Required
X-PAYMENT-REQUIRED: eyJ4NDAyVmVyc2lvbiI6MSwiYWNjZXB0cyI6W3… ← reto en base64
Content-Type: application/json
{
"error": "payment_required",
"detail": "payment required: retry with the X-PAYMENT header",
"price_eur_cents": 20,
"amount_atomic": 200000,
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"network": "base",
"pay_to": "0x2bDc11AEB751EC845aE5fED5bbf7c73BF6D0C4E3",
"accepts": [{
"scheme": "exact",
"network": "base",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"payTo": "0x2bDc11AEB751EC845aE5fED5bbf7c73BF6D0C4E3",
"maxAmountRequired": "200000",
"resource": "/v1/verify",
"description": "Verificación de empresa española por CIF",
"mimeType": "application/json",
"maxTimeoutSeconds": 300
}]
}200000 con 6 decimales son 0,20 USDC.
No es un error. Es la primera mitad del ciclo, y el servidor la devuelve como resultado
normal (ok: false) con el campo payment completo, no como una excepción:
{
"ok": false,
"cif": "A58818501",
"payment": {
"x402_version": 1,
"scheme": "exact",
"network": "base",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"pay_to": "0x2bDc11AEB751EC845aE5fED5bbf7c73BF6D0C4E3",
"amount_atomic": 200000,
"price_eur_cents": 20,
"resource": "/v1/verify",
"max_timeout_seconds": 300,
"accepts": [/* … */],
"payment_header": "X-PAYMENT",
"payment_required_header_value": "eyJ4NDAyVmVyc2lvbiI6MSwiYWNjZXB0cyI6W3…",
"instructions": "Payment required: 200000 atomic units of 0x8335… on base to 0x2bDc… This MCP server cannot sign or send payments. Have a wallet you control build an x402 payload for this exact challenge, then call verify_company_by_cif again with the same cif and the payload in the 'x_payment' argument (sent as the X-PAYMENT header)."
},
"error": { "code": "payment_required", "http_status": 402, "retryable": false }
}Reintentar en bucle no sirve de nada: el reto es idéntico en cada intento. Por eso
retryable es false.
Aquí es donde entra el dinero, y donde este servidor se aparta a propósito. La wallet (la de tu usuario, o el proveedor x402 que uses) construye un payload de pago firmado para ese reto exacto — misma red, mismo activo, misma dirección, mismo importe — y lo serializa en base64.
// Lo que la wallet produce (esquema "exact" sobre Base):
{ "x402Version": 1, "scheme": "exact", "network": "base",
"payload": { "signature": "0x…", "authorization": { /* … */ } } }
// ↓ base64
// "eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoiZXhhY3QiLCJuZXR3b3JrIjoiYmFzZSIsInBheWxvYWQiOnsi…"Misma herramienta, mismo CIF, y el payload base64 en x_payment:
{
"cif": "A58818501",
"x_payment": "eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoiZXhhY3Qi…",
"idempotency_key": "verif-A58818501-2026-10-04"
}El servidor lo envía como cabecera:
POST /v1/verify HTTP/1.1
Content-Type: application/json
X-PAYMENT: eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoiZXhhY3Qi…
Idempotency-Key: verif-A58818501-2026-10-04
{"cif": "A58818501"}Y ahora sí:
{ "ok": true, "company": { "name": "…", "status": "active", "…": "…" },
"risk": { "value": 15, "band": "low", "…": "…" }, "recent_acts": [/* … */] }idempotency_key merece la pena. Si la conexión se cae justo después de enviar el pago,
reutilizar la misma clave hace que el reintento devuelva el resultado original en lugar de
cobrar dos veces.
Alternativa sin agente de por medio: el mismo ciclo con
curl, útil para depurar:# 2. El reto curl -sS -X POST https://api.veridexia.es/v1/verify \ -H 'Content-Type: application/json' -d '{"cif":"A58818501"}' # 4. Con el pago curl -sS -X POST https://api.veridexia.es/v1/verify \ -H 'Content-Type: application/json' \ -H "X-PAYMENT: $X_PAYMENT" \ -d '{"cif":"A58818501"}'
Situación | ¿Se cobra? |
Empresa encontrada ( | Sí |
CIF con formato válido pero sin registro ( | No — se resuelve antes de cobrar |
Fuente de datos caída ( | No — el reintento es gratis |
CIF mal formado ( | No — se rechaza antes de ninguna búsqueda |
Falta el pago o es inválido ( | No (todavía) |
Con la configuración de arriba y Claude Desktop reiniciado, una conversación real:
Tú: Verifica la empresa con CIF A58818501 y dime si tiene riesgo.
Claude llama a la herramienta y recibe el 402:
Claude: La verificación cuesta 0,20 USDC en la red Base, pagaderos a
0x2bDc11AEB751EC845aE5fED5bbf7c73BF6D0C4E3. No puedo firmar ni enviar el pago yo mismo: este servidor MCP no tiene wallet.Para completarlo, settle este reto con una wallet tuya y pégame aquí el payload base64 resultante:
{ "x402Version": 1, "accepts": [ { "scheme": "exact", "network": "base", "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "payTo": "0x2bDc11AEB751EC845aE5fED5bbf7c73BF6D0C4E3", "maxAmountRequired": "200000", "resource": "/v1/verify" } ] }Si prefieres, dime y te indico cómo hacerlo desde tu wallet.
Tú: Aquí lo tienes:
eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoiZXhhY3QiLCJuZXR3b3JrIjoiYmFzZSIsInBheWxvYWQiOnsi…
Claude vuelve a llamar a verify_company_by_cif pasando ese valor en x_payment, recibe el
200 y responde:
Claude: Empresa verificada.
Nombre: MOCK TECNOLOGIAS SA — Sociedad Anónima, Málaga
Situación: Activa sin incidencias (último depósito en BORME: 2025-08-09)
Constituida: 2015-10-02 · Capital: 45.000 €
Riesgo: 15/100 (banda baja), confianza alta, conclusivo
status_active(+15): la sociedad figura activa sin incidencias publicadasActos recientes: 2026-08-28, Sección Primera — Cambio de domicilio social
Fuente: prometiam (respuesta en directo, no cacheada)
No hay publicaciones de insolvencia ni señales adversas registradas.
Si el CIF no existiera, Claude no habría pagado nada y lo diría tal cual:
Claude: El CIF
A58818501tiene formato válido pero no aparece en el BORME ni en ninguna de las fuentes configuradas. No se ha realizado ningún cargo. ¿Quieres que compruebe si el CIF está bien escrito?
Todos los fallos llegan como resultado normal con ok: false y un error tipado — nunca
como una excepción, para que el agente pueda leer error.code, decidir y actuar en lugar de
ver interrumpido su turno.
| HTTP | ¿Reintentable? | Qué significa |
| 402 | No (tal cual) | Falta el pago. Trae |
| 404 | No | CIF válido, sin registro. No se ha cobrado |
| 503 | Sí | La fuente de datos falló. No se ha cobrado |
| 422 | No | CIF mal formado (una letra, 7 dígitos y un carácter de control, p. ej. |
| 401 / 403 | No | Se rechazó |
| 429 | Sí, esperando | Cuota por llamante agotada |
| (ninguno) | Sí | No se pudo alcanzar la API (DNS, TLS, timeout). |
| cualquiera | 5xx sí | Respuesta que este cliente no modela; el código original queda en |
| 200 | No | El 200 no encaja con el contrato. Trae |
El estado siempre incluye guidance: una frase imperativa con el siguiente paso concreto,
escrita para que la siga un modelo.
cd mcp-server
python -m venv .venv
.venv/Scripts/activate # Windows; source .venv/bin/activate en Unix
pip install -e ".[dev]"
pytest # 101 tests, sin red: todo va por httpx.MockTransport
pytest -v tests/test_server.pyEstructura:
mcp-server/
├── pyproject.toml
├── README.md
├── LICENSE
├── claude_desktop_config.json
├── src/veridex_mcp/
│ ├── __init__.py versión del paquete
│ ├── __main__.py python -m veridex_mcp
│ ├── main.py argparse, logging a stderr, arranque
│ ├── config.py Settings desde el entorno
│ ├── models.py los tipos de cada resultado (→ outputSchema)
│ ├── errors.py jerarquía de errores tipados
│ ├── client.py transporte HTTP + decodificación del reto x402
│ └── server.py las tres herramientas MCP
└── tests/
├── conftest.py API mockeada con payloads reales
├── test_client.py un test por cada respuesta posible de la API
├── test_server.py mapeo de errores + protocolo MCP real
└── test_main.py arranque, transporte y la regla de stderrTodo el logging va a stderr. Bajo el transporte stdio, stdout es el canal JSON-RPC:
un solo print() corrompe el framing y el host reporta un error de parseo que no nombra la
causa real. Es la forma más común de que un servidor MCP "conecte pero no haga nada", así
que main.configure_logging() es explícito en lugar de delegar en basicConfig().
El pyproject.toml ya está listo (nombre veridex-mcp, licencia MIT, license-files):
python -m build
twine check dist/*
twine upload dist/*MIT. El texto completo viaja en el paquete, en el fichero LICENSE.
VERIDEX · https://api.veridexia.es · manifiesto de descubrimiento: https://api.veridexia.es/.well-known/x402
Describe the VERIDEX service: what it does, its price, the settlement network and asset, the receiving address and the available endpoints.
Reads the public discovery manifest at /.well-known/x402. Needs no credentials and costs nothing. Call this before verifying if you need to know what a verification costs or where the payment goes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| name | No | |
| asset | No | |
| error | No | |
| price | No | |
| pay_to | No | |
| network | No | |
| endpoints | No | |
| how_to_pay | No | |
| description | No | |
| asset_symbol | No | |
| raw_manifest | No | |
| asset_decimals | No | |
| manifest_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new operational context beyond that: it reads a public discovery manifest at /.well-known/x402, needs no credentials, and costs nothing — all of which matter for an agent deciding whether it can call this unauthenticated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first front-loads the returned content, the second covers cost, auth, and the recommended call ordering. No filler, and the most decision-relevant facts (free, no credentials) come early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema already exists, so the description is not obligated to document return values, yet it still summarizes them usefully. Combined with the no-auth/no-cost note and the call-ordering guidance, an agent has everything needed to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. The description correctly implies a parameterless discovery call rather than suggesting any input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (describe) and resource (the VERIDEX service) and enumerates exactly what the payload contains: price, settlement network/asset, receiving address, and endpoints. This cleanly separates it from the sibling verify_company_by_cif, which performs the actual verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: 'Call this before verifying if you need to know what a verification costs or where the payment goes.' That is a clear when-to-use condition tied to the sibling verification flow. It does not state when not to call it or name the alternative tools directly, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the VERIDEX API is up, and see today's demand: uptime, the number of verification calls served today and the distinct callers.
Free and unauthenticated. The request count excludes the service's own healthchecks and local tests, so it answers 'is anyone using this?' rather than 'is the process alive?'. Useful before starting a paid flow.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| error | No | |
| status | No | 'ok' when the API is serving. |
| api_url | No | |
| reachable | No | |
| checked_at | No | |
| latency_ms | No | |
| requests_today | No | |
| uptime_seconds | No | |
| unique_agents_today | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes beyond them by disclosing the auth posture (free, unauthenticated) and the exact counting semantics — healthchecks and local tests excluded, so it reports real external demand. That is genuine behavioral context an agent could not derive from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core capability, then auth/cost posture, then counting caveat. Every sentence carries distinct information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, and the description still summarizes what comes back (uptime, call count, distinct callers). For a no-arg read tool, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so there is nothing to document and the baseline is 4. The description adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (check API liveness) and adds a second, concrete capability: today's uptime, verification-call count and distinct callers. The 'free and unauthenticated... before a paid flow' framing implicitly separates it from the paid verification siblings without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Useful before starting a paid flow' gives a clear usage context, and 'free and unauthenticated' tells the agent it can be called speculatively. It does not name verify_company_by_cif or get_veridex_info as alternatives, so the when-not side 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.
Verify a Spanish company by its CIF and get its registry data, status in the BORME, recent published acts and an explainable 0-100 risk score.
This is an x402-paid endpoint. The first call returns ok=false with error.code='payment_required' and a complete payment challenge (price, network, asset, receiving address). Settle that challenge with a wallet you control and call again with the resulting base64 payload in x_payment; the same call then returns the company.
Errors are typed: 'not_found' (valid CIF, no record — you are not charged), 'source_unavailable' (upstream registry down — not charged, safe to retry), 'invalid_request' (malformed CIF), 'rate_limited' (quota), 'transport_error' (the API was unreachable). Do not retry a 402 without changing the payment.
| Name | Required | Description | Default |
|---|---|---|---|
| cif | Yes | ||
| x_payment | No | ||
| idempotency_key | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| cif | No | The CIF as requested. |
| mock | No | True when the facts are synthetic, never true for a real source. |
| risk | No | |
| error | No | |
| company | No | |
| payment | No | |
| guidance | No | What to do next, in one sentence, for the calling agent. |
| provenance | No | |
| recent_acts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the full x402 payment handshake, the exact payment_required envelope shape, which errors are free (not_found, source_unavailable) vs billable, and retry semantics per error code. This is behavior an agent could not infer from readOnlyHint/openWorldHint alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and deliverable, then a dedicated payment paragraph and a typed-error paragraph. Dense and useful with no filler, though the payment guidance is slightly verbose relative to what an agent needs on the first read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description nonetheless previews them. Payment, error taxonomy, and retry policy are all covered; only the idempotency_key parameter is left unexplained, a minor gap for an otherwise complete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains x_payment thoroughly (base64 payload from a settled challenge) and cif is self-evident, but idempotency_key is never mentioned anywhere, leaving one of three parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (verify) and resource (Spanish company by CIF) and enumerates the returned payload: registry data, BORME status, recent acts, and an explainable 0-100 risk score. This is unmistakably distinct from siblings get_veridex_info and health_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit operational context: first call returns payment_required, settle and re-call with x_payment, and a clear when-not rule ('Do not retry a 402 without changing the payment'). It also scopes retryability per error code. No comparison to siblings, but they are unrelated utility endpoints, so nothing essential is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1get_veridex_infohealth_checkverify_company_by_cifScored across 3 tools
Three tools serve clearly distinct purposes: paying for a company lookup, reading the service's own pricing manifest, and checking API health/demand. There is no realistic way to confuse verify_company_by_cif with either of the free informational tools.
All three use a consistent snake_case verb_noun pattern: verify_company_by_cif, get_veridex_info, health_check. The style is predictable and readable throughout.
Three tools is somewhat thin for a server whose core value is a single paid verification endpoint. However, the informational tools (manifest, health) are coherent supporting pieces rather than padding, so it is defensible but borderline.
The core verification operation is covered, including detailed error taxonomy and payment flow. But there is no batch verification, no historical results, and only one real domain action, which is a notable gap for a registry-data service.
European business verification for AI agents: registry, VAT, sanctions, IBAN. Pay-per-call x402.
Brazilian company data, CNPJ/CPF validation and KYB risk score. Pay per call via x402 (USDC).
China company verification and supplier due diligence data for AI agents via remote MCP and x402 on Base USDC. Basic: 0.032 USDC per call for company registration, operating abnormalities and administrative penalties. Full: 0.093 USDC per call for those 3 modules plus serious violations, enforcement, dishonest judgment debtors, bankruptcy, qualifications and customs (9 modules total, not 9 fields). Structured JSON with per-module availability and limitations. List modules return the first page only, up to 10 records; no automatic pagination or historical expansion. Missing data is not a clean-risk finding. The legacy resolver returns a capability notice only, not a free company lookup. No government procurement coverage. Not a complete due diligence report.
Deterministic Mexican/LatAm verification + sanctions & PEP screening for AI agents. Pay via x402.