M2M-native. x402 payments. Zero accounts. Zero API keys. Latin America first.
Built by the creator of Intelica and TrustBoost.
VeraData exposes a native MCP server at , compatible with Claude Desktop, Claude Code, Cursor, Windsurf, Smithery, and Glama.
Add to :
{
"mcpServers": {
"veradata": {
"url": "https://api.veradata.dev/mcp"
}
}
}claude mcp add veradata --url https://api.veradata.dev/mcpTool | Description | Price |
Real-time LATAM central bank rates (CO, MX, BR, CL, PE) | /bin/sh.02 USDC | |
Sanctions screening — OFAC + SARLAFT + CNBV + COAF + UAF | /bin/sh.05 USDC | |
Company enrichment from RUES/CNPJ/RFC registries | /bin/sh.03 USDC | |
AI-powered LATAM market intelligence (Claude Haiku) | /bin/sh.10 USDC |
Transport: HTTP (Streamable HTTP, JSON-RPC 2.0)
Manifest:
Tools: with
Payment: x402 micropayments on Base () and Solana
Tool definitions are in .
Related MCP server: x402-api
On June 28, 2026, Agentic Market has 1,357 x402 services. Person enrichment exists for the US and Europe. Sanctions screening exists for OFAC. Financial signals exist for BTC/ETH.
Nothing exists for Latin America.
No x402 service covers:
Colombian NIT / DIAN registry lookups
SARLAFT sanctions screening (mandatory for Colombian financial entities)
Brazilian CNPJ / Receita Federal verification
Mexican RFC / SAT status
LATAM central bank rates (DTF, TIIE, Selic)
Regional compliance verification for EU AI Act Art.13
This is a gap in a market processing $1.2M/day in agentic transactions. VeraData fills it.
A single FastAPI service with 5 endpoints, each payable per-call via x402 on Base and Solana. Pure M2M — no human interaction required. Any agent with a wallet can discover it via CDP Bazaar, Agentic Market, or 402 Index, pay in USDC, and receive structured JSON instantly.
Stack: FastAPI + Supabase + Render (same as Intelica/TrustBoost — proven in production)
Payment: x402 v2, CAIP-2 compliant (eip155:8453 + solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp)
Distribution: CDP Bazaar + Agentic Market + 402 Index (all channels proven with Intelica)
POST /entity — Entity Enrichment LATAM — $0.03 USDCGiven a company name + country, returns structured entity data from public registries.
// Request
{ "name": "Bancolombia", "country": "CO" }
// Response
{
"nit": "890903938-8",
"razon_social": "Bancolombia S.A.",
"estado": "ACTIVA",
"camara_comercio": "Bogotá",
"fecha_constitucion": "1945-01-24",
"representante_legal": "Juan Carlos Mora Uribe",
"ciiu": "6412",
"pep_check": false,
"data_source": "RUES_CO",
"verified_at": "2026-06-28T14:00:00Z"
}Data sources: RUES (Colombia), Receita Federal (Brazil), SAT (Mexico), SRI (Ecuador), SBS (Peru)
Price: $0.03 — refreshed every 24h, cached in Supabase
POST /sanctions — Sanctions & Compliance Screen — $0.05 USDCScreens an entity or person against LATAM + global sanctions lists. Returns risk score + EU AI Act compliant audit hash.
// Request
{ "name": "Juan García López", "country": "CO", "type": "person" }
// Response
{
"risk_score": 0.02,
"risk_category": "CLEAN",
"lists_checked": ["OFAC_SDN", "SARLAFT_CO", "CNBV_MX", "COAF_BR", "UAF_CL"],
"matches": [],
"pep_status": false,
"audit_hash": "sha256:abc123...",
"compliance": ["EU_AI_ACT_ART13", "SARLAFT_2024", "FATF_R16"],
"checked_at": "2026-06-28T14:00:01Z"
}Lists covered:
🇨🇴 SARLAFT (Colombia) — updated daily
🇲🇽 CNBV Lista Negra (Mexico)
🇧🇷 COAF/BACEN (Brazil)
🇨🇱 UAF (Chile)
🌍 OFAC SDN (USA/Global)
🌍 UN Security Council Consolidated List
🌍 EU Consolidated Sanctions List
Regulatory moat: EU AI Act Art.13 enforcement begins August 2, 2026 — any European company with AI agents operating in LATAM needs this endpoint.
Price: $0.05 — highest margin module, mandatory for fintech
POST /registry — Business Registry Lookup — $0.05 USDCReal-time lookup of business registration data from official public registries.
// Request
{ "identifier": "890903938", "country": "CO", "id_type": "nit" }
// Response
{
"identifier": "890903938-8",
"razon_social": "Bancolombia S.A.",
"tipo_empresa": "Sociedad Anónima",
"estado_juridico": "ACTIVA",
"fecha_registro": "1945-01-24",
"domicilio": "Medellín, Antioquia, Colombia",
"objeto_social": "Actividades de banca comercial",
"capital_suscrito_cop": 1076956260000,
"registro_mercantil": "890903938-8",
"renovado_hasta": "2026-12-31",
"fuente": "Cámara de Comercio de Medellín",
"verified_at": "2026-06-28T14:00:02Z"
}Countries: Colombia (RUES + Cámaras), Mexico (SAT + IMSS), Brazil (CNPJ / Receita Federal), Chile (SRCeI), Peru (SUNARP/SUNAT)
Price: $0.05
POST /rates — Financial Signal LATAM — $0.02 USDCReal-time rates and macro indicators from LATAM central banks. No AI — raw data, structured JSON, 5-minute cache.
// Request
{ "country": "CO", "signals": ["usd_cop", "dtf", "ipc_monthly"] }
// Response
{
"country": "CO",
"timestamp": "2026-06-28T14:00:03Z",
"usd_cop": 4187.35,
"dtf_ea": 10.85,
"ipc_monthly_pct": 0.47,
"ipc_annual_pct": 6.12,
"banrep_rate_pct": 9.75,
"trm_official": 4187.35,
"source": "Banco de la República de Colombia",
"cache_ttl_seconds": 300
}Countries + signals:
🇨🇴 Colombia: TRM, DTF, IPC, IBR, tasa Banrep
🇲🇽 Mexico: TIIE, INPC, UDIS, tasa Banxico
🇧🇷 Brazil: Selic, CDI, IPCA, PTAX
🇨🇱 Chile: TPM, UF, IPC, USD/CLP
🇵🇪 Peru: BCRP rate, USD/PEN, IPC
Price: $0.02 — highest volume module, called every agent cycle
POST /context — Market Context LATAM — $0.10 USDCAI-powered market context for a sector + country. Reuses Intelica's LLM layer but focused on LATAM. Returns regulatory environment, key players, market size, growth signals.
// Request
{ "sector": "fintech", "country": "CO", "query": "neobanks competitive landscape 2026" }
// Response
{
"sector": "fintech",
"country": "CO",
"market_size_usd": "2.1B",
"growth_rate_pct": 34,
"key_players": ["Nequi", "Daviplata", "Rappipay", "Lulo Bank", "Movii"],
"regulatory_framework": {
"regulator": "Superintendencia Financiera de Colombia",
"key_regulations": ["Decreto 1234/2023 sandbox", "SARLAFT 3.0", "Ley 1328 consumidor financiero"],
"eu_ai_act_applicable": true
},
"market_signals": [
"BancoEstado LATAM expansion signals 12% YoY neobank account growth",
"SFC approved 3 new sandbox licenses Q1 2026"
],
"audit_hash": "sha256:def456...",
"source": "VeraData Market Context Engine v1.0"
}Price: $0.10 — highest value, AI-powered, lowest frequency
Endpoint | Price | Conservative calls/day | Revenue/month |
| $0.03 | 500 | $450 |
| $0.05 | 300 | $450 |
| $0.05 | 200 | $300 |
| $0.02 | 2,000 | $1,200 |
| $0.10 | 100 | $300 |
Total conservador | 3,100/day | $2,700/month | |
Con 1 fintech activo | 20,000/day | $18,000/month |
Why /rates dominates: Agents de trading, DeFi, y treasury que operan en LATAM necesitan las tasas en cada ciclo — cada 5 minutos. 2,000 calls/day conservador es bajo para ese perfil.
FastAPI (Python 3.11)
├── x402 middleware (CDP Bazaar + PayAI)
├── Supabase (caché + audit log + rate limiting)
└── Render (AWS us-east, misma infra)
Payment Stack:
├── CDP Facilitator (Bazaar indexing — probado)
├── PayAI (fallback — probado)
└── Wallets: Base + Solana (mismas de Intelica)
Data Sources (todas públicas y gratuitas):
├── RUES Colombia — API pública
├── Receita Federal Brasil — scraping + API
├── SAT México — API pública
├── Banco de la República — API JSON
├── Banxico — SIE API (gratuita, registro simple)
├── BCB Brasil — API REST pública
├── OFAC SDN — descarga diaria CSV
├── SARLAFT — actualización mensual UIAF
└── COAF/UAF/CNBV — listas públicas-- Caché de entidades (evita llamadas repetidas a registros)
CREATE TABLE entity_cache (
id BIGSERIAL PRIMARY KEY,
identifier TEXT NOT NULL,
country CHAR(2) NOT NULL,
data JSONB NOT NULL,
fetched_at TIMESTAMPTZ DEFAULT NOW(),
expires_at TIMESTAMPTZ,
UNIQUE(identifier, country)
);
-- Listas de sancionados (actualizadas diariamente)
CREATE TABLE sanctions_lists (
id BIGSERIAL PRIMARY KEY,
list_name TEXT NOT NULL, -- OFAC_SDN, SARLAFT_CO, etc.
entity_name TEXT NOT NULL,
entity_type TEXT, -- person, company
country TEXT,
identifiers JSONB,
updated_at TIMESTAMPTZ DEFAULT NOW()
);
-- Tasas de cambio y macro (caché 5 minutos)
CREATE TABLE rates_cache (
id BIGSERIAL PRIMARY KEY,
country CHAR(2) NOT NULL,
signal TEXT NOT NULL,
value NUMERIC NOT NULL,
fetched_at TIMESTAMPTZ DEFAULT NOW(),
UNIQUE(country, signal)
);
-- Audit log x402 (mismo patrón de Intelica)
CREATE TABLE vera_audit (
id BIGSERIAL PRIMARY KEY,
seq_id BIGSERIAL,
ip_hash TEXT,
endpoint TEXT,
country TEXT,
network TEXT,
price_usdc NUMERIC,
trace_id UUID,
audit_hash TEXT,
created_at TIMESTAMPTZ DEFAULT NOW()
);Agent → POST /sanctions (sin X-PAYMENT)
Server → 402 + PAYMENT-REQUIRED header (con extensions.bazaar)
Agent → firma EIP-3009 con wallet Base
Agent → POST /sanctions + X-PAYMENT header
Server → CDP verify → CDP settle → extensions.bazaar → "processing"
Server → response JSON + audit_hash
CDP Bazaar → indexa automáticamente (probado Jun 28, 2026)/rates + /sanctions (Semana 1)Por qué estas dos primero:
/rates es el módulo de mayor volumen potencial y el más simple técnicamente — llamadas a APIs públicas de bancos centrales sin IA
/sanctions convierte TrustBoost existente en un módulo con LATAM coverage — 70% del trabajo ya está hecho
Deliverables:
Repo veradata con FastAPI base (fork de TrustBoost)
Scraper/fetcher de Banco de la República (Colombia)
Scraper/fetcher de Banxico (México)
Scraper/fetcher de BCB (Brasil)
Módulo de descarga y parsing de OFAC SDN CSV
Parsing de lista UIAF SARLAFT Colombia
Parsing de lista CNBV México
Endpoints /rates y /sanctions con x402
Deploy en Render
Registro en CDP Bazaar (proceso ya conocido)
Registro en 402 Index
Registro en Agentic Market
Revenue estimado Fase 1: $600-$1,800/mes
/entity + /registry (Semana 2-3)Integración RUES Colombia (API REST pública, sin auth)
Integración CNPJ Receita Federal (API pública)
Integración RFC SAT México (SOAP, parser)
Caché de 24h en Supabase
Endpoint /entity y /registry con x402
Revenue estimado Fase 2: $1,500-$4,500/mes acumulado
/context (Semana 4)Reutilizar LLM layer de Intelica (Claude Haiku)
Prompt especializado en mercados LATAM
Integración con /rates para contexto macro real-time
Endpoint /context con x402 ($0.10)
Revenue estimado Fase 3: $2,700-$8,000/mes acumulado
Orthogonal skill registration (mismo proceso que Intelica PR #60)
awesome-x402 PR
Blog post técnico en dev.to con caso de uso real
TrustBoost cross-promotion (usuarios de TB → VeraData)
Intelica cross-promotion (análisis de mercado LATAM usa /rates y /entity)
First mover en x402 LATAM — Agentic Market tiene 1,357 servicios. Cero para datos estructurados de Colombia, México, Brasil via x402. La ventana es de 6-12 meses.
EU AI Act como catalyst — Enforcement August 2, 2026. Empresas europeas con agentes IA en LATAM necesitan /sanctions para compliance Art.13. No es opcional.
Stack probado — FastAPI + Supabase + Render + x402 + CDP Bazaar ya están en producción con Intelica y TrustBoost. No hay que aprender nada nuevo.
Datos gratuitos — A diferencia de servicios como Clearbit ($99+/mes) o APIs comerciales de bureaus de crédito, las fuentes primarias de VeraData son todas públicas. Margen neto > 90%.
Demanda probada — /rates tiene análogo directo en servicios de alto volumen en Agentic Market (crypto liquidation maps, DeFi signals). El patrón de uso es idéntico pero para LATAM.
Intelica sinergy — El módulo /context reutiliza el grafo de 3,744 nodos de Intelica con foco LATAM. Un agente que usa Intelica para análisis competitivo puede llamar VeraData para datos macro en el mismo workflow.
El mismo playbook que funcionó con Intelica:
Canal | Acción | Tiempo |
CDP Bazaar | Deploy + primer pago con | Día 1 |
402 Index |
| Día 1 |
Agentic Market | Auto-indexado via CDP Bazaar | Día 1 |
punkpeye/awesome-mcp-servers | PR (sección Security/Data) | Semana 1 |
xpaysh/awesome-x402 | PR (sección Live Services) | Semana 1 |
Orthogonal | SKILL.md (mismo proceso PR #60) | Semana 2 |
402 Index TrustBoost | Ya verificado — cross-list VeraData | Semana 1 |
Nunca alterar el modelo central — todos los cambios son aditivos
Nunca borrar datos de Supabase sin confirmación explícita
Siempre CAIP-2 en accepts[]: eip155:8453 y solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp
Python 3.11 — mismo que Intelica/TrustBoost, no cambiar
Claude Haiku — modelo LLM para /context ($0.10 precio justifica costo)
Supabase Colombia project — nuevo proyecto separado de Intelica y TrustBoost
Render free tier — suficiente para MVP, upgrade al primer $500/mes
Endpoint | Cache TTL | Fuente |
| 24 horas | Registros públicos (cambian raro) |
| 24 horas | Listas actualizadas diariamente |
| 5 minutos | APIs bancos centrales (tiempo real) |
| 24 horas | Registros mercantiles |
| 1 hora | LLM + |
veradata/
├── main.py # FastAPI app principal
├── requirements.txt # FastAPI, httpx, supabase, PyJWT, cryptography
├── .env.example # Variables de entorno requeridas
├── README.md # Este archivo
├── CONTEXT.md # Historial de decisiones y sesiones
├── fetchers/
│ ├── banrep.py # Banco de la República Colombia
│ ├── banxico.py # Banco de México
│ ├── bcb.py # Banco Central do Brasil
│ ├── rues.py # RUES Colombia
│ ├── receita.py # Receita Federal Brasil
│ └── sat.py # SAT México
├── sanctions/
│ ├── ofac.py # OFAC SDN downloader + parser
│ ├── sarlaft.py # UIAF SARLAFT Colombia
│ ├── cnbv.py # CNBV México
│ ├── coaf.py # COAF Brasil
│ └── uaf.py # UAF Chile
└── llms-full.txt # Machine-readable docs para agentes# Supabase (nuevo proyecto VeraData)
SUPABASE_URL=
SUPABASE_SERVICE_KEY=
# x402 Payment
WALLET_ADDRESS= # Base mainnet (misma de Intelica)
WALLET_SOLANA= # Solana mainnet (misma de Intelica)
CDP_API_KEY_ID= # organizations/xxx/apiKeys/xxx (mismo de Intelica)
CDP_API_KEY_SECRET= # EC private key PEM
# LLM (solo para /context)
ANTHROPIC_API_KEY=
# Pricing
PRICE_ENTITY=0.03
PRICE_SANCTIONS=0.05
PRICE_REGISTRY=0.05
PRICE_RATES=0.02
PRICE_CONTEXT=0.10
# Banxico API (registro gratuito en sie.banxico.org.mx)
BANXICO_TOKEN=VeraData es el tercer producto del mismo founder que construyó:
TrustBoost (api.trustboost.dev) — PII sanitization API, 500+ downloads en ClawHub, verificado en 402 Index, awesome-mcp-servers PR #6415 mergeado
Intelica (api.intelica.dev) — Competitive intelligence API, en CDP Bazaar y Agentic Market desde Jun 28, 2026, primer pago x402 via CDP facilitator verificado
El stack, el proceso de deployment, y el playbook de discovery están probados en producción. VeraData aplica las mismas lecciones aprendidas con velocidad de ejecución máxima.
# Clonar y configurar
git clone https://github.com/teodorofodocrispin-cmyk/veradata
cd veradata
pip install fastapi uvicorn httpx supabase pyjwt cryptography anthropic
# Configurar variables
cp .env.example .env
# Editar .env con tus valores
# Correr localmente
uvicorn main:app --reload --port 8001
# Test /rates (primer endpoint a construir)
curl -X POST http://localhost:8001/rates \
-H "Content-Type: application/json" \
-d '{"country": "CO", "signals": ["usd_cop", "dtf"]}'
# → 402 Payment Required (correcto — x402 funcionando)VeraData — Built in Bogotá, Colombia. Jun 28, 2026.
AI-powered LATAM market context. Sector + country → market_size, key_players, regulations, growth signals. $0.10 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| sector | Yes | ||
| country | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the cost ($0.10) and output types, but lacks details on authentication, rate limits, latency, or potential errors. The transparency is adequate but not comprehensive.
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?
The description is a single, concise sentence with structured output hints (arrow notation). Every word adds value, with no redundancy or extraneous information.
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?
The description lists expected outputs and cost, which is helpful for a simple tool with no output schema. However, it fails to explain the optional query parameter or any edge cases/limitations (e.g., restricted to LATAM). The completeness is adequate but has notable gaps.
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 schema has 3 parameters with 0% coverage. The description explains sector and country but omits the optional 'query' parameter entirely. This leaves ambiguity for the agent on how to use query, reducing parameter semantics.
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?
The description clearly states the tool provides AI-powered LATAM market context for a given sector and country, listing specific outputs (market_size, key_players, regulations, growth signals). This distinguishes it from siblings (e.g., vera_entity, vera_rates, vera_sanctions) which serve different purposes.
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?
The description implies use for market research inquiries but does not explicitly state when to use this tool versus alternatives. Sibling names provide context clues, but no direct guidance on exclusions or when not to use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Company enrichment from LATAM public registries: RUES CO, CNPJ BR, RFC MX. Returns NIT/CNPJ, status, representative, industry. $0.03 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| country | Yes | ||
| identifier | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It discloses the cost ($0.03 USDC via x402) and returns (NIT/CNPJ, status, etc.), but lacks details on idempotency, rate limits, or side effects. The behavioral info is partial but non-trivial.
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 sentences convey purpose, registries, outputs, and cost without extraneous words. The structure is front-loaded and efficient.
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?
The description omits the additional countries (CL, PE) present in the input schema, creating inconsistency. It also does not explain how to use the optional 'name' parameter or the full set of registries. For a tool with no output schema, this leaves gaps.
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 coverage is 0%, so description must explain parameters. It implies 'identifier' maps to NIT/CNPJ and 'country' determines the registry, but does not explain the 'name' parameter. The description adds some semantics but is incomplete for the optional name field.
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?
The description clearly specifies the tool's purpose: 'Company enrichment from LATAM public registries' and lists specific registries (RUES CO, CNPJ BR, RFC MX) and return fields (NIT/CNPJ, status, representative, industry). It distinguishes itself from siblings (vera_context, vera_rates, vera_sanctions) by focusing on entity enrichment.
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?
The description implies usage for company enrichment but does not explicitly state when to use versus alternatives or provide exclusion criteria. The mention of LATAM registries gives context, but no guidance on prerequisites or conditional use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real-time central bank rates for LATAM countries (CO, MX, BR, CL, PE). Returns TRM, DTF, IBR, TIIE, Selic, UF. 5-min cache. $0.02 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| signals | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds limited behavioral context: a 5-minute cache and a cost of $0.02 USDC via x402. However, it does not disclose whether the operation is read-only, idempotent, or requires authentication.
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 sentences with no redundancy. Front-loads purpose, lists outputs, then adds caching/pricing. Every sentence adds unique value.
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?
Given no output schema and 0% parameter documentation, the description lacks details on return format, error handling, and the 'signals' parameter. It covers the core purpose but leaves gaps for an agent to invoke 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?
Schema coverage is 0%, so the description must compensate. It explains the 'country' parameter via its enum values, but the 'signals' parameter is completely ignored – no hint what values or purpose it serves.
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?
The description clearly states the tool returns real-time central bank rates for specific LATAM countries and lists the exact rate names (TRM, DTF, IBR, TIIE, Selic, UF). It distinguishes itself from sibling tools like 'vera_context' or 'vera_entity' by focusing solely on rate retrieval.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for LATAM country rates but does not explain when not to use it or mention sibling tools for context or sanctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sanctions screening — OFAC SDN + SARLAFT CO + CNBV MX + COAF BR + UAF CL. Returns risk_score 0-1 + EU AI Act Art.13 audit hash. $0.05 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | No | person | |
| country | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses return values (risk_score, audit hash) and cost ($0.05 USDC via x402). However, it does not mention side effects, permissions, or operational details like rate limits or response format.
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?
The description is extremely concise, conveying purpose, coverage, output, and cost in a single sentence. No unnecessary words.
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?
Given 3 parameters, no output schema, and no annotations, the description provides high-level purpose and output but lacks parameter descriptions and usage context. It is minimally complete for a simple tool.
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 coverage is 0% and the description does not explain the three parameters (name, type, country). The description only mentions 'Sanctions screening' without linking to parameters, leaving agents to infer meaning.
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?
The description clearly states the tool performs sanctions screening against specific lists (OFAC SDN, SARLAFT CO, etc.) and specifies the output (risk_score and audit hash). It distinguishes from siblings (vera_context, vera_entity, vera_rates) which cover different areas.
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?
The description implies usage for sanctions screening but does not explicitly state when to use it versus alternatives, nor provide when-not-to-use guidance. No mention of prerequisites or exclusions.
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. Dates show when Glama detected each change.
v1.0.0vera_contextvera_entityvera_ratesvera_sanctionsEach tool targets a distinct domain: market context, entity enrichment, financial rates, and sanctions. No overlap exists.
All tools follow a consistent 'vera_' prefix with a descriptive noun (context, entity, rates, sanctions), making names predictable.
Four tools cover the essential LATAM business data areas without being too few or too many, perfectly scoped for the server's purpose.
The set covers market context, company data, rates, and sanctions. Minor gaps like news or legal info exist but are not critical for core operations.
Verified LATAM data for AI agents: sanctions, entity, rates, KYB. Pay via x402.
Deterministic Mexican/LatAm verification + sanctions & PEP screening for AI agents. Pay via x402.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Paid x402 tools over MCP: search, FX, LEI, company research, risk. Pay-per-call USDC on Base.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/teodorofodocrispin-cmyk/veradata'
If you have feedback or need assistance with the MCP directory API, please join our Discord server