veridex-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VERIDEX_API_KEY | No | Reservado para un tier premium futuro. No es necesario: el endpoint de pago no pide credenciales, el pago es la credencial | |
| VERIDEX_API_URL | No | Apuntar a un backend local o a un despliegue propio | https://api.veridexia.es |
| VERIDEX_TIMEOUT_SECONDS | No | Timeout de cada petición HTTP | 30 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| verify_company_by_cifA | 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 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. |
| get_veridex_infoA | 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. |
| health_checkA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.