mcp-colombia-hub connects AI agents to Colombian services for shopping, travel, real estate, and finance — with verified identity and behavior reputation tracking via Soulprint.
🛍️ Search MercadoLibre products: Find products with prices, seller info, free shipping, and purchase links, filterable by category, price range, and sort order.
🔍 Get product details: Retrieve full details for a specific MercadoLibre item by ID (e.g., MCO123456789).
✈️ Search flights: Find domestic and international flights to/from Colombia (with links to Avianca, LATAM, and Skyscanner), filtered by origin, destination, dates, and passengers.
🏨 Search hotels: Look up hotels in Colombian cities for specific dates, with Booking.com links and price filtering in COP.
🏠 Search real estate: Browse apartments and houses for rent or sale via FincaRaíz, MetroCuadrado, and Ciencuadras, filtered by city, price, rooms, and neighborhood.
💳 Compare CDTs: Compare Certificados de Depósito a Término across Colombian banks by investment amount and term.
💰 Simulate loans: Calculate monthly payments and total cost for consumer/personal credits at major Colombian banks and fintechs.
🏦 Compare bank accounts: Compare savings accounts and digital wallets, including yield rates, maintenance fees, and GMF tax info.
🪪 Soulprint identity & reputation: Check your Soulprint score, DID, and reputation status. All tool usage is tracked for spam detection and reputation building.
🔒 Job applications (premium): Apply for jobs with verified identity, requiring a Soulprint score of 40 or higher.
Enables searching for flight availability, routes, and schedules to and from Colombia through Avianca's services.
Utilizes the Brave Search API as a fallback mechanism to provide real-time web search results for Colombian products and services.
Allows for the comparison of investment yields and terms for fixed-term deposit (CDT) products offered by Nu Colombia.
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., "@mcp-colombia Busca una freidora de aire en MercadoLibre por menos de 300 mil pesos"
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.
MCP server que conecta cualquier agente de IA con servicios colombianos — con identidad verificada y reputación de comportamiento mediante Soulprint.
Edita tu archivo de configuración MCP:
Windows: %APPDATA%\Claude\claude_desktop_config.json
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"mcp-colombia": {
"command": "npx",
"args": ["-y", "mcp-colombia-hub"]
}
}
}Con identidad verificada (endpoints premium):
{
"mcpServers": {
"mcp-colombia": {
"command": "npx",
"args": ["-y", "mcp-colombia-hub"],
"env": {
"SOULPRINT_TOKEN": "tu-token-aqui"
}
}
}
}Related MCP server: Scavio
Tool | Descripción |
| Busca productos con precio, vendedor y link directo |
| Detalle completo de un producto por ID |
Tool | Descripción |
| Vuelos desde/hacia Colombia (via Booking.com) |
| Hoteles con precio por noche en pesos colombianos |
Tool | Descripción |
| Compara CDTs de bancos colombianos |
| Simula créditos (cuota mensual, total a pagar) |
| Compara cuentas de ahorro y corrientes |
Tool | Descripción |
| Busca apartamentos/casas en venta o arriendo (Ciencuadras) |
Tool | Descripción | Requiere |
| Ver tu score, DID, sesión y reputación | Opcional |
| PREMIUM — Aplica a empleos con identidad verificada | Score ≥ 40 |
mcp-colombia-hub es el primer servicio verificado del ecosistema Soulprint. Cada llamada a las herramientas es monitoreada automáticamente:
🔴 Spam (>5 requests en 60s) → -1 attestation a tu DID
🟢 Uso normal (3+ tools, 3+ completions sin spam) → +1 attestationtrabajo_aplicarRequiere Soulprint score ≥ 40 (identidad básica verificada):
# Verificar tu identidad primero
npx soulprint verify-me --selfie yo.jpg --document cedula.jpg
# El token se inyecta automáticamente vía SOULPRINT_TOKENRespuesta de trabajo_aplicar:
{
"application_id": "SP-M9X3K2-Z6MK4F",
"applicant": {
"did": "did:key:z6Mk...",
"score": 97,
"verified": true
},
"trust_guarantees": {
"human_verified": true,
"no_spam_history": true,
"zkp": true
}
}Los empleadores ven un candidato verificado — sin nombre, sin cédula, solo prueba matemática de que eres un humano real con historial limpio.
src/
├── index.ts # Servidor MCP principal (10 tools)
├── tools/
│ ├── mercadolibre.ts # Búsqueda ML con fallback Brave Search
│ ├── booking.ts # Vuelos + hoteles (Booking.com / Awin)
│ ├── finanzas.ts # CDT, crédito, cuentas
│ └── inmuebles.ts # Ciencuadras JSON-LD scraping
└── soulprint/
├── service-identity.ts # DID del servicio, token SPT (score=80)
├── behavior-tracker.ts # Tracking spam/recompensas por DID
└── middleware.ts # extractToken(), verifySoulprint(), requireSoulprint()
tests/
└── soulprint.test.ts # 37 tests (unit + integración + pen tests)npm test[A] TESTS UNITARIOS (16 tests)
✅ Service identity — DID, keypair, token score=80
✅ Behavior tracker — spam detection, rewards, error reset
✅ Middleware — token extraction, verification, minScore
[B] TESTS DE INTEGRACIÓN (12 tests)
✅ Bot anónimo — tools básicas OK, trabajo_aplicar BLOQUEADO
✅ Bot low-score — bloqueado del endpoint premium
✅ Bot premium (score=100) — acceso total
✅ Ciclo de recompensa — +1 tras 3 completions en 3 tools
✅ Ciclo de penalización — -1 tras spam detectado
[C] TESTS DE PENETRACIÓN (9 tests)
✅ Score inflation ×50 → RECHAZADO
✅ DID substitution ×20 → RECHAZADO
✅ 100 fake attestations → SCORE SIN CAMBIO
✅ Sybil attack → BLOQUEADO por nodo
✅ Spam en endpoint premium → -1 rep
Total: 37/37 ✅git clone https://github.com/manuelariasfz/mcp-colombia
cd mcp-colombia
npm install
npm run build
npm testVariables de entorno opcionales:
BRAVE_API_KEY=... # Para búsqueda fallback en ML
SOULPRINT_NODE=http://... # Nodo Soulprint (default: localhost:4888)
SOULPRINT_TOKEN=... # Token SPT del bot usuarioProyecto | Rol |
Protocolo de identidad (7 paquetes npm) | |
mcp-colombia-hub | Primer servicio verificado del ecosistema |
MIT — Felipe Arias · @manuelariasfz
Compara los mejores CDTs (Certificados de Depósito a Término) disponibles en Colombia según monto y plazo. Muestra tasas, rendimiento real y links al banco.
| Name | Required | Description | Default |
|---|---|---|---|
| monto | Yes | Monto a invertir en COP (mínimo $100,000) | |
| plazo_dias | Yes | Plazo en días: 30, 60, 90, 180 o 360 | |
| top | No | Cuántos bancos mostrar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what information will be shown ('tasas, rendimiento real y links al banco'). It doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, data freshness, or what happens with invalid inputs. The description is functional but lacks operational context.
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 appropriately sized (one sentence) and front-loaded with the main purpose. It efficiently communicates the core functionality without unnecessary words, though it could be slightly more structured by explicitly mentioning all three parameters.
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?
For a comparison tool with 3 parameters and no output schema, the description adequately covers the purpose but lacks details about the return format, error handling, or data sources. With no annotations and no output schema, more context about what the comparison results look like would be helpful for the agent.
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 100%, so the schema fully documents all parameters. The description mentions 'según monto y plazo' which aligns with the first two parameters but doesn't add meaning beyond what the schema already provides. The 'top' parameter isn't mentioned at all in the description.
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 specific action ('Compara' - compares), resource ('CDTs disponibles en Colombia'), and scope ('según monto y plazo'). It distinguishes from sibling tools by focusing specifically on CDTs rather than accounts, loans, properties, products, or travel services.
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 context (when comparing CDTs by amount and term) but doesn't explicitly state when to use this vs. alternatives like 'finanzas_comparar_cuentas' or 'finanzas_simular_credito'. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compara cuentas de ahorros y billeteras digitales en Colombia. Muestra rendimiento, cuota de manejo y GMF.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | Tipo de cuenta a comparar | todos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's function but lacks details on behavioral traits such as whether it requires authentication, has rate limits, returns real-time or cached data, or how it handles errors. For a tool with no annotation coverage, this is a significant gap in transparency.
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 concise and well-structured, consisting of a single sentence that efficiently conveys the tool's purpose and key outputs. Every word earns its place, with no redundant or vague language, making it easy to understand at a glance.
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 the tool's low complexity (1 parameter with full schema coverage) and lack of annotations or output schema, the description is minimally complete. It explains what the tool does but doesn't compensate for missing behavioral details or output information, resulting in an adequate but incomplete context for an agent.
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 description coverage is 100%, with the single parameter 'tipo' fully documented in the schema (including enum values and default). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for adequate but not enhanced 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's purpose: comparing savings accounts and digital wallets in Colombia, with specific metrics like performance, management fees, and GMF. It uses specific verbs ('Compara', 'Muestra') and identifies the resource, though it doesn't explicitly differentiate from sibling tools like 'finanzas_comparar_cdt' or 'finanzas_simular_credito' beyond the different financial products.
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 provides no guidance on when to use this tool versus alternatives. While it specifies the types of accounts compared, it doesn't mention when to choose this over other financial tools like 'finanzas_comparar_cdt' (for CDs) or 'finanzas_simular_credito' (for loans), nor does it indicate any prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simula un crédito de consumo o libre inversión en los principales bancos y fintechs de Colombia. Muestra cuota mensual, total a pagar y costo del crédito.
| Name | Required | Description | Default |
|---|---|---|---|
| monto | Yes | Monto del crédito en COP | |
| cuotas | Yes | Número de cuotas mensuales | |
| proposito | No | Para qué es el crédito (ej: comprar moto, viaje, deudas) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool simulates credit and outputs key metrics (monthly payment, total cost, credit cost), which is useful. However, it lacks details on behavioral traits such as rate limits, authentication needs, data sources, or whether the simulation is real-time or based on cached data. For a tool with no annotations, this leaves significant gaps in understanding its operation.
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 appropriately sized and front-loaded, consisting of two concise sentences. The first sentence states the tool's purpose and scope, and the second specifies the outputs. There is no wasted language, and every sentence contributes directly to understanding the tool's function.
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 the tool's complexity (simulation with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers the purpose and outputs but lacks behavioral context and detailed usage guidelines. Without an output schema, it should ideally explain return values more thoroughly, but it does specify key metrics. This makes it adequate but with clear gaps for a simulation 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?
The input schema has 100% description coverage, with clear parameter definitions (monto, cuotas, proposito). The description adds no additional semantic meaning beyond what the schema provides, such as explaining parameter interactions or constraints. Since schema coverage is high, the baseline score is 3, as the description doesn't compensate but also doesn't detract.
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's purpose: 'Simula un crédito de consumo o libre inversión en los principales bancos y fintechs de Colombia' (simulates a consumer or free investment credit across major Colombian banks and fintechs). It specifies the action (simulate), resource (credit), and scope (Colombian financial institutions). However, it doesn't explicitly differentiate from sibling tools like 'finanzas_comparar_cdt' or 'finanzas_comparar_cuentas', which are also financial comparison tools but for different products.
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 provides no guidance on when to use this tool versus alternatives. It mentions the tool's function but doesn't specify scenarios, prerequisites, or exclusions (e.g., when to use 'finanzas_comparar_cdt' for certificates of deposit instead). Usage is implied only through the tool's name and description, with no explicit context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca apartamentos y casas en arriendo o venta en Colombia. Busca en FincaRaíz y MetroCuadrado. Filtra por ciudad, precio, habitaciones y zona.
| Name | Required | Description | Default |
|---|---|---|---|
| ciudad | Yes | Ciudad (Bogotá, Medellín, Cali, Barranquilla, Bucaramanga, Cartagena, Pereira...) | |
| tipo | Yes | Tipo de negocio: arriendo o venta | |
| habitaciones | No | Número de habitaciones (1-6) | |
| precio_max | No | Precio máximo en COP (ej: 2000000 para $2M arriendo) | |
| precio_min | No | Precio mínimo en COP | |
| zona | No | Barrio o zona (ej: Chapinero, Laureles, El Poblado) | |
| limit | No | Cantidad de resultados |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions searching two sources and filtering, but doesn't disclose behavioral traits like rate limits, authentication needs, response format, pagination, or error handling. For a search tool with no annotation coverage, this is a significant gap.
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 concise and front-loaded, stating the core purpose in the first sentence and listing key filters in the second. Every sentence earns its place with no wasted words, making it easy to scan and understand quickly.
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 annotations and no output schema, the description is incomplete for a 7-parameter search tool. It covers the what and where but lacks details on behavioral aspects, return values, or error cases. It's adequate as a basic overview but has clear gaps for agent invocation.
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 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value by listing some filter criteria (ciudad, precio, habitaciones, zona), but doesn't provide additional semantics beyond the schema. With high coverage, baseline is 3, but the description slightly enhances context, warranting a 4.
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 searches for apartments and houses for rent or sale in Colombia, specifying the sources (FincaRaíz and MetroCuadrado) and filtering criteria. It uses specific verbs ('busca', 'filtra') and distinguishes itself from sibling tools which are about finance, e-commerce, and travel, not real estate.
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 real estate searches in Colombia with specific filters, but doesn't explicitly state when to use this tool versus alternatives or when not to use it. No sibling tools overlap in functionality, so differentiation isn't needed, but guidance on prerequisites or constraints is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca productos en MercadoLibre Colombia. Devuelve precios, vendedor, envío gratis y link de compra.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Qué producto buscar | |
| categoria | No | Filtrar por categoría | |
| limit | No | Cantidad de resultados (máx 10) | |
| precio_min | No | Precio mínimo en COP | |
| precio_max | No | Precio máximo en COP | |
| ordenar | No | Ordenar resultados |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what information is returned (precios, vendedor, envío gratis, link de compra), but does not cover important aspects like rate limits, authentication needs, error handling, or pagination behavior for a search tool with up to 10 results.
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, efficient sentence that front-loads the core functionality. Every part earns its place by specifying the action, target, and key return values without unnecessary elaboration.
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?
For a search tool with 6 parameters, 100% schema coverage, and no output schema, the description adequately covers the basic purpose and return values. However, it lacks details on behavioral aspects like result format, error cases, or limitations, which would be helpful given the absence of annotations and output schema.
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 100%, so the schema already documents all 6 parameters thoroughly. The description does not add any parameter-specific information beyond what the schema provides, such as explaining how query terms are matched or the meaning of 'relevancia' sorting. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Busca productos') and resource ('en MercadoLibre Colombia'), distinguishing it from sibling tools like 'ml_detalle_producto' which likely provides detailed product information. It explicitly mentions the scope of the search and the key information returned.
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 searching products on MercadoLibre Colombia, but does not explicitly state when to use this tool versus alternatives like 'ml_detalle_producto' or other search tools. It provides basic context but lacks explicit exclusions or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene el detalle completo de un producto de MercadoLibre por su ID (ej: MCO123456789).
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | ID del producto en MercadoLibre (formato MCO + números) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'obtiene' (gets) details, implying a read-only operation, but does not mention error handling, rate limits, authentication needs, or response format. This leaves gaps in understanding how the tool behaves beyond its basic function.
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, efficient sentence that front-loads the core purpose and includes a helpful example. There is no redundant or unnecessary information, making it appropriately concise and well-structured for its purpose.
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 the tool's simplicity (1 parameter, no annotations, no output schema), the description is adequate but incomplete. It covers the basic operation but lacks details on behavioral aspects like error conditions or output structure, which are important for a tool without annotations or output schema.
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 100%, with the parameter 'item_id' fully documented in the schema. The description adds minimal value by providing an example format ('MCO123456789'), but does not elaborate on semantics beyond what the schema already states. This meets the baseline for high schema coverage.
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's purpose: 'Obtiene el detalle completo de un producto de MercadoLibre por su ID' (Gets the complete detail of a MercadoLibre product by its ID). It specifies the verb ('obtiene'), resource ('producto de MercadoLibre'), and scope ('detalle completo'), but does not explicitly differentiate from sibling tools like 'ml_buscar_productos', which likely searches for products rather than fetching details by ID.
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 provides no guidance on when to use this tool versus alternatives. It mentions the parameter ('por su ID') but does not specify use cases, prerequisites, or exclusions. For example, it does not clarify if this is for single-product lookups versus bulk searches, or how it differs from 'ml_buscar_productos'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca hoteles en ciudades colombianas para las fechas indicadas. Devuelve sugerencias y link directo a Booking.com.
| Name | Required | Description | Default |
|---|---|---|---|
| ciudad | Yes | Ciudad destino (Bogotá, Medellín, Cartagena, Cali, Santa Marta, Barranquilla, San Andrés...) | |
| checkin | Yes | Fecha de llegada en formato YYYY-MM-DD | |
| checkout | Yes | Fecha de salida en formato YYYY-MM-DD | |
| adultos | No | Número de adultos | |
| habitaciones | No | Número de habitaciones | |
| precio_max | No | Precio máximo por noche en COP |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns suggestions and a direct link to Booking.com, but lacks details on rate limits, authentication needs, error handling, or the format of returned suggestions, which is insufficient for a search tool with external integration.
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 front-loaded and concise, consisting of two efficient sentences that directly state the tool's function and output without any wasted words or unnecessary details.
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 the tool's moderate complexity (6 parameters, no output schema, no annotations), the description is partially complete but lacks details on behavioral aspects like integration with Booking.com, result formatting, or error scenarios, which are important for effective tool use.
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 description does not add meaning beyond what the input schema provides, as schema description coverage is 100% and all parameters are well-documented in the schema. The baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
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's purpose with specific verbs ('Busca hoteles') and resources ('en ciudades colombianas'), and distinguishes it from sibling tools like 'viajes_buscar_vuelos' by focusing on hotel searches rather than flights or other travel services.
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 provides no guidance on when to use this tool versus alternatives like 'inmuebles_buscar' or 'viajes_buscar_vuelos', nor does it mention any prerequisites or exclusions for its use, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca vuelos domésticos e internacionales desde/hacia Colombia. Devuelve links a Avianca, LATAM y Skyscanner.
| Name | Required | Description | Default |
|---|---|---|---|
| origen | Yes | Ciudad/aeropuerto de origen (código IATA o nombre, ej: BOG, Bogotá) | |
| destino | Yes | Ciudad/aeropuerto de destino (ej: MDE, Medellín, MIA, Miami) | |
| fecha | Yes | Fecha de salida YYYY-MM-DD | |
| ida_vuelta | No | Si es ida y vuelta | |
| fecha_regreso | No | Fecha de regreso YYYY-MM-DD (solo si ida_vuelta=true) | |
| pasajeros | No | Número de pasajeros |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool returns links to Avianca, LATAM and Skyscanner, which is useful output information. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or what happens with invalid inputs. For a flight search tool with no annotations, this leaves significant gaps.
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 and front-loaded with essential information in just two sentences. The first sentence states the core purpose, and the second sentence adds crucial output information. Every word earns its place with zero waste or redundancy.
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 the tool's moderate complexity (6 parameters, flight search functionality) and the absence of both annotations and output schema, the description provides basic but incomplete context. It covers what the tool does and what it returns (links to specific providers), but doesn't address behavioral aspects, error conditions, or detailed usage scenarios. For a tool with no output schema, mentioning the return format is helpful but insufficient for full completeness.
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 100%, so the schema already documents all 6 parameters thoroughly with examples and constraints. The description adds no additional parameter semantics beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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's purpose: 'Busca vuelos domésticos e internacionales desde/hacia Colombia' (searches domestic and international flights to/from Colombia). It specifies the verb ('busca') and resource ('vuelos') with geographic scope. However, it doesn't explicitly differentiate from its sibling 'viajes_buscar_hotel' beyond the obvious flight vs. hotel distinction.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling hotel search tool or any other flight search options. The only implicit context is that it's for flights rather than hotels, but there's no explicit when/when-not guidance or alternative recommendations.
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.
v1.1.0finanzas_comparar_cdtfinanzas_comparar_cuentasfinanzas_simular_creditoinmuebles_buscarml_buscar_productosml_detalle_productoviajes_buscar_hotelviajes_buscar_vuelosScored across 8 tools
Each tool has a clearly distinct purpose targeting specific domains (finances, real estate, e-commerce, travel) with no overlap in functionality. For example, finanzas_comparar_cdt and finanzas_comparar_cuentas serve different financial comparison needs, while ml_buscar_productos and ml_detalle_producto handle distinct e-commerce tasks.
All tools follow a consistent snake_case pattern with a clear domain_prefix_verb_noun structure (e.g., finanzas_comparar_cdt, inmuebles_buscar). This predictable naming convention makes it easy to understand each tool's purpose and category at a glance.
With 8 tools, the server is well-scoped for its purpose as a Colombia-focused utility covering multiple domains (finance, real estate, e-commerce, travel). Each tool earns its place by addressing a specific, common use case without redundancy or excessive fragmentation.
The tool set provides solid coverage for key consumer domains in Colombia, with clear CRUD-like operations where applicable (e.g., search and detail for products, search for flights/hotels). Minor gaps exist, such as no tool for comparing flight or hotel options directly, but agents can work around this by using the provided search tools effectively.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
