Verify Spanish companies by CIF: registry data, status and BORME filings, paid per call over x402.
Scored across 3 tools
The three tools have mostly distinct purposes: metadata discovery, service health/demand, and the paid verification operation. get_veridex_info and health_check both probe the service but differ in what they return (manifest vs uptime/usage), so confusion risk is low though not zero.
get_veridex_info and verify_company_by_cif follow a verb_noun pattern, while health_check is a noun_noun form. It's a minor deviation that stays readable and unambiguous, not a chaotic mix.
Three tools is lean but well-matched to a narrow paid verification service: one discovery call, one health/demand check, one core operation. Nothing feels redundant, though it sits near the thin end of the range.
Core lifecycle is covered (discover, check health, verify), but the surface is limited to a single CIF lookup with no batch, search, or alternate-identifier operation, and get_veridex_info hints at additional endpoints not exposed as tools. Usable but with notable gaps.
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.
get_veridex_infohealth_checkverify_company_by_cifEuropean business verification for AI agents: registry, VAT, sanctions, IBAN. Pay-per-call x402.
French company checks (SIREN): status, insolvency (BODACC), VAT number, RGE. Pay-per-call via x402.
Company lookups and annual-account financials: Sweden, Norway, Finland, UK. Pay per call (x402).
Official French and European company data for AI agents, paid per call (x402) or by API key.
Add one secure layer between your agents and this server.
