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 Mercado Público Show me today's active licitaciones"
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 Model Context Protocol (MCP) para la API pública de Mercado Público / ChileCompra. Permite que asistentes de IA consulten licitaciones, órdenes de compra y empresas del Estado chileno en tiempo real.
Antes de usar el servidor necesitas tu propio ticket (API key):
Iniciar sesión con Clave Única
Completar el formulario → el ticket llega a tu correo
El servidor no almacena credenciales. El ticket se pasa como parámetro en cada consulta.
Related MCP server: chile-procurement
No necesitas clonar ni compilar nada. Usa npx directamente.
Tienes dos formas de pasar tu ticket:
Método | Cuándo usarlo |
Variable de entorno | Configuras el ticket una sola vez en el IDE — el asistente nunca te lo pedirá |
Parámetro | Si no configuraste la env var, pásalo directamente en cada consulta |
Se recomienda usar la variable de entorno para una experiencia fluida.
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"mercado-publico": {
"command": "npx",
"args": ["-y", "mcp-mercado-publico"],
"env": {
"MERCADO_PUBLICO_TICKET": "TU-TICKET-AQUI"
}
}
}
}Reinicia Claude Desktop después de guardar.
Global ~/.cursor/mcp.json · Por proyecto .cursor/mcp.json
{
"mcpServers": {
"mercado-publico": {
"command": "npx",
"args": ["-y", "mcp-mercado-publico"],
"env": {
"MERCADO_PUBLICO_TICKET": "TU-TICKET-AQUI"
}
}
}
}Verifica en Settings → MCP que el servidor aparezca con punto verde.
Requiere VS Code 1.99+ y Copilot en Agent mode.
Por proyecto .vscode/mcp.json:
{
"servers": {
"mercado-publico": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-mercado-publico"],
"env": {
"MERCADO_PUBLICO_TICKET": "TU-TICKET-AQUI"
}
}
}
}Global en settings.json:
{
"mcp": {
"servers": {
"mercado-publico": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-mercado-publico"],
"env": {
"MERCADO_PUBLICO_TICKET": "TU-TICKET-AQUI"
}
}
}
}
}C:\Users\<usuario>\.gemini\antigravity\claude_desktop_config.json
{
"mcpServers": {
"mercado-publico": {
"command": "npx",
"args": ["-y", "mcp-mercado-publico"],
"env": {
"MERCADO_PUBLICO_TICKET": "TU-TICKET-AQUI"
}
}
}
}C:\Users\<usuario>\.codeium\windsurf\mcp_config.json
{
"mcpServers": {
"mercado-publico": {
"command": "npx",
"args": ["-y", "mcp-mercado-publico"],
"env": {
"MERCADO_PUBLICO_TICKET": "TU-TICKET-AQUI"
}
}
}
}Si estás modificando el código fuente, compila primero y apunta al binario local:
npm install && npm run build{
"mcpServers": {
"mercado-publico": {
"command": "node",
"args": ["D:\\PROGRAMACION\\NEST-JS\\mcp-mercado-publico\\dist\\main.js"]
}
}
}Tool | Descripción |
| Lista licitaciones por fecha, estado, proveedor u organismo (nombre o código) |
| Busca licitaciones en un rango de fechas (máximo 30 días) |
| Detalle completo de una licitación por su código |
| Lista órdenes de compra por fecha, estado, proveedor u organismo (nombre o código) |
| Detalle completo de una OC por su código |
| Busca un proveedor por su RUT |
| Lista todos los organismos públicos disponibles |
| Busca un organismo público por nombre — retorna su CodigoOrganismo |
| Retorna la estructura de respuesta JSON de la API nativa para cualquier entidad |
| Retorna los parámetros funcionales y diccionarios de anexos para consultar la API |
| Muestra ejemplos reales de URIs HTTP de la API y los distintos formatos soportados |
| Muestra la guía completa de uso del MCP, referencias de códigos y límites operativos |
Una vez configurado, puedes preguntarle al asistente cosas como:
¿Cuáles son las licitaciones activas de hoy?
Mi ticket es F8537A18-6766-4DEF-9E59-426B4FEE2844Busca la licitación con código 1509-5-L114 usando mi ticket ABC123-...¿Qué órdenes de compra aceptadas existen para el 01042026?Busca las licitaciones de la Municipalidad de Alto del CarmenBusca el proveedor con RUT 70.017.820-kestadoValor para | Código en respuesta |
| Todas las publicadas hoy |
| 5 |
| 6 |
| 7 |
| 8 |
| 18 |
| 19 |
| Todos los estados |
estadoValor para | Código en respuesta |
| 4 |
(sin query param) | 5 (En proceso, solo en respuesta) |
| 6 |
| 9 |
| 12 |
| 13 |
| 14 |
| 15 |
| Todos los estados |
La API usa ddmmaaaa. Ejemplos: 07042026 → 7 de abril de 2026.
npm login
npm publish # ejecuta npm run build automáticamente (prepublishOnly)src/
├── main.ts # Bootstrap (modo stdio)
├── app.module.ts
├── common/
│ └── constants/
│ └── api.constants.ts # BASE_URL, endpoints, códigos de estado
├── mercado-publico/
│ ├── interfaces/mercado-publico.interfaces.ts # Tipos de parámetros
│ ├── helpers/query-builder.helper.ts # Construcción de query params
│ ├── mercado-publico.service.ts # Cliente HTTP
│ └── mercado-publico.module.ts
└── mcp/
├── constants/tool-schemas.constants.ts # Campos Zod reutilizables
├── tools/
│ ├── licitaciones.tools.ts
│ ├── ordenes-compra.tools.ts
│ ├── empresas.tools.ts
│ ├── estructura.tools.ts
│ └── ayuda.tools.ts
├── mcp-server.ts
├── mcp.service.ts
└── mcp.module.tsEste MCP no tiene acceso a los archivos adjuntos de las licitaciones ni de las órdenes de compra (bases de licitación, anexos, especificaciones técnicas, resoluciones, etc.).
La API de Mercado Público no retorna links de descarga ni el contenido de los documentos. Solo expone los datos estructurados (metadatos) de cada proceso: montos, fechas, estados, ítems, organismos, etc.
Para acceder a los documentos debes ingresar directamente al portal: mercadopublico.cl
Las limitaciones descritas a continuación no son impuestas por este servidor MCP, sino por la API oficial de Mercado Público (ChileCompra). Este servidor las respeta y documenta para que los usuarios las conozcan antes de usar el servicio.
El ticket se solicita mediante formulario oficial seleccionando la opción "Solicitud de Ticket".
Debe completarse con datos reales: nombre, apellido, RUT y correo electrónico.
Se entrega un único ticket por persona. Datos inconsistentes pueden derivar en limitación o suspensión del acceso.
ChileCompra usa los datos personales únicamente para operación, control y administración del servicio — no los comparte con terceros, salvo mandato judicial.
10.000 solicitudes diarias por ticket — no modificable.
El uso excesivo o abusivo puede derivar en suspensión temporal o bloqueo permanente.
La API incluye validaciones por dirección IP: múltiples solicitudes desde la misma IP pueden generar restricciones.
Para procesos de alta demanda o descarga masiva, usar horario nocturno (22:00–07:00 hrs, Chile).
Soporte únicamente a través del formulario de sugerencias del sitio web de ChileCompra.
Plazo de respuesta: máximo 3 días hábiles.
No se atienden solicitudes informales ni por correo institucional directo.
La API es un servicio adicional y voluntario — ChileCompra puede modificarla, suspenderla o darla de baja sin previo aviso.
ChileCompra no se hace responsable de la información publicada por terceros mediante aplicaciones que usen la API.
Al publicar datos obtenidos desde la API sin modificarlos, debe indicarse que la fuente es la Dirección ChileCompra.
Documentación oficial: chilecompra.cl/api
Datos de Mercado Público, Dirección ChileCompra, Ministerio de Hacienda, Gobierno de Chile.
Muestra la guía completa de uso del MCP Mercado Público: todas las herramientas disponibles, sus parámetros, ejemplos de uso, referencia de estados y límites de la API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes a read-only, informational operation of displaying a guide. This is transparent for a help tool, though it could mention if authentication or rate limits apply (likely not).
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 sentence that is front-loaded with the main purpose. It is concise, with no unnecessary words, and covers the key aspects of what the tool does.
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 (no parameters, no output schema), the description is fairly complete. It explains what it shows. It could mention whether the guide is dynamic or static, but overall it is adequate.
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?
There are zero parameters, and schema coverage is 100% trivially. Baseline for no parameters is 4. The description adds no parameter info because none exist.
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 shows a complete guide of the MCP, listing all tools, parameters, examples, states, and API limits. The verb 'muestra' and resource 'guía completa' are specific, and it distinguishes from sibling tools that are search-oriented.
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 obtaining help or learning about the MCP. It does not explicitly state when not to use or alternatives, but the sibling tools list makes it clear this is the help tool. A bit more explicit guidance would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca licitaciones en Mercado Público (ChileCompra). Sin parámetros opcionales retorna las licitaciones del día actual. Puedes filtrar por fecha, estado, proveedor u organismo. Para buscar por organismo usa nombreOrganismo (nombre o parte) o codigoOrganismo (código numérico). Sin fecha y con organismo/proveedor, busca automáticamente los últimos 30 días. Estados válidos: activas (publicadas hoy), publicada, cerrada, desierta, adjudicada, revocada, suspendida, todos. Códigos en la respuesta: Publicada=5, Cerrada=6, Desierta=7, Adjudicada=8, Revocada=18, Suspendida=19.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | No | Tu ticket de acceso a la API de Mercado Público. Puedes obtenerlo en https://api.mercadopublico.cl/modules/IniciarSesion.aspx. Si el servidor fue configurado con la variable de entorno MERCADO_PUBLICO_TICKET, este parámetro es opcional. | |
| fecha | No | Fecha en formato ddmmaaaa (ej: 07042026 para el 7 de abril de 2026). Si se omite, se usan los registros del día actual. | |
| estado | No | Estado de la licitación: activas | publicada | cerrada | desierta | adjudicada | revocada | suspendida | todos. Usa "activas" para ver todas las publicadas hoy. | |
| codigoProveedor | No | Código numérico del proveedor en Mercado Público (ej: 17793). Úsalo junto a "fecha". | |
| codigoOrganismo | No | Código numérico del organismo público comprador (ej: 6945). Úsalo junto a "fecha". | |
| nombreOrganismo | No | Nombre o parte del nombre del organismo comprador (ej: "Alto del Carmen", "Ministerio de Salud"). Se resuelve automáticamente a su código interno. Alternativa a codigoOrganismo cuando no se conoce el código numérico. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: default to current day, auto 30-day range, and valid states. However, it does not explicitly state read-only nature or rate limits, but given the search context, it is sufficiently transparent.
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 dense paragraph but front-loaded with core purpose. Each sentence provides essential information. Could be slightly more structured (e.g., bullet points) but overall concise 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?
Given 6 parameters, no required ones, and no output schema, the description covers behavior, defaults, and enumerations well. However, it lacks information about pagination, result limits, and the format/mapping of output fields, which would be helpful for a search 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 100%, but the description adds significant meaning beyond individual parameter descriptions: it explains state value meanings, the automatic 30-day behavior, and the relationship between fecha, codigoProveedor, codigoOrganismo, and nombreOrganismo. This adds value beyond the schema.
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 it searches licitaciones on Mercado Público (ChileCompra). It implicitly differentiates from sibling tools by specifying single-day default and filtering behavior, but does not explicitly name alternatives.
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?
Provides clear guidance on default behavior (today's results), filtering options (date, status, supplier, organization), and automatic 30-day search when no date is given with organization/supplier. Does not explicitly exclude other tools or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca licitaciones en un rango de fechas (máximo 30 días). Realiza una consulta por cada día del rango y consolida los resultados en un solo listado. Útil para análisis históricos o reportes de períodos específicos. IMPORTANTE: cada día consume una solicitud del cupo diario (10.000 requests/ticket). Para rangos grandes se recomienda horario nocturno (22:00–07:00 hrs Chile).
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | No | Tu ticket de acceso a la API de Mercado Público. Puedes obtenerlo en https://api.mercadopublico.cl/modules/IniciarSesion.aspx. Si el servidor fue configurado con la variable de entorno MERCADO_PUBLICO_TICKET, este parámetro es opcional. | |
| fechaInicio | Yes | Fecha de inicio del rango en formato ddmmaaaa (ej: 01042026). | |
| fechaFin | Yes | Fecha de fin del rango en formato ddmmaaaa (ej: 07042026). Máximo 30 días desde fechaInicio. | |
| estado | No | Filtro de estado: activas | publicada | cerrada | desierta | adjudicada | revocada | suspendida | todos. | |
| codigoOrganismo | No | Código numérico del organismo público comprador (ej: 6945). Úsalo junto a "fecha". | |
| codigoProveedor | No | Código numérico del proveedor en Mercado Público (ej: 17793). Úsalo junto a "fecha". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that each day consumes a request from the daily quota (10,000 requests/ticket) and recommends large ranges be run at night. It also states it queries per day and consolidates results. This is good transparency for rate limiting and performance, though it lacks details on error handling or output pagination.
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: two sentences plus an important note. It is front-loaded with the main purpose, followed by behavior and a usage tip. Every sentence earns its place with no redundancy or waste.
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 has no output schema and 6 parameters (2 required), the description covers the core behavior and rate limit implications. However, it does not describe the output format or provide examples, leaving some ambiguity about what the returned list contains. For a consolidation tool, this is a notable gap.
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 parameter formats and requirements. The description adds some contextual value by mentioning the 30-day max and per-day request consumption, but does not significantly enhance understanding of individual parameters beyond the schema.
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 title and description clearly state it searches for licitaciones by date range with a max of 30 days. It distinguishes from siblings like 'buscar_licitaciones' (a different search) and 'obtener_licitacion' (single tender), and the description explains it queries per day and consolidates results.
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 specifies it is useful for historical analysis or reports of specific periods. It includes a note recommending nighttime usage for large ranges due to daily request quota, which provides context. However, it does not explicitly state when not to use this tool or mention alternatives like 'buscar_licitaciones'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca órdenes de compra en Mercado Público (ChileCompra). Sin parámetros opcionales retorna todas las OC del día actual. Puedes filtrar por fecha, estado, proveedor u organismo. Para buscar por organismo usa nombreOrganismo (nombre o parte) o codigoOrganismo (código numérico). Sin fecha y con organismo/proveedor, busca automáticamente los últimos 30 días. Valores válidos para el parámetro estado: enviadaproveedor, aceptada, cancelada, recepcionconforme, pendienterecepcion, recepcionaceptadacialmente, recepecionconformeincompleta, todos. NOTA: el estado "en proceso" (código 5) solo aparece en la respuesta, no es filtrable como query param. Códigos en respuesta: EnviadaProveedor=4, EnProceso=5, Aceptada=6, Cancelada=9, RecepcionConforme=12, PendienteRecepcion=13, RecepcionadaParcialmente=14, RecepcionConformeIncompleta=15.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | No | Tu ticket de acceso a la API de Mercado Público. Puedes obtenerlo en https://api.mercadopublico.cl/modules/IniciarSesion.aspx. Si el servidor fue configurado con la variable de entorno MERCADO_PUBLICO_TICKET, este parámetro es opcional. | |
| fecha | No | Fecha en formato ddmmaaaa (ej: 07042026 para el 7 de abril de 2026). Si se omite, se usan los registros del día actual. | |
| estado | No | Estado de la OC: enviadaproveedor | aceptada | cancelada | recepcionconforme | pendienterecepcion | recepcionaceptadacialmente | recepecionconformeincompleta | todos. | |
| codigoProveedor | No | Código numérico del proveedor en Mercado Público (ej: 17793). Úsalo junto a "fecha". | |
| codigoOrganismo | No | Código numérico del organismo público comprador (ej: 6945). Úsalo junto a "fecha". | |
| nombreOrganismo | No | Nombre o parte del nombre del organismo comprador (ej: "Alto del Carmen", "Ministerio de Salud"). Se resuelve automáticamente a su código interno. Alternativa a codigoOrganismo cuando no se conoce el código numérico. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses default behavior, automatic date range, and non-filterable status. However, it does not mention rate limits, pagination, or authentication details beyond the ticket parameter description in the schema.
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 well-structured, front-loads the main purpose, and every sentence adds distinct information. It is detailed but concise given the complexity of the tool.
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?
No output schema is provided, and the description does not explain the return structure (e.g., list of OCs, pagination). It gives status codes but lacks completeness about what the response contains, which is important for a search 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 100%, so baseline is 3. The description adds value by explaining interaction between parameters (e.g., no date with org/proveedor triggers 30-day search) and providing example values. It repeats some schema info but provides behavioral context.
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 it searches for purchase orders in Mercado Público (ChileCompra). It specifies the default behavior (returns today's OC without parameters) and distinguishes itself from sibling tools like buscar_licitaciones by focusing on purchase orders.
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?
Provides explicit guidance on when to use parameters: without optional params returns today's OC; filtering by date, status, supplier, organization; automatic 30-day search when org/supplier is given without date; lists valid estado values and notes that 'en proceso' appears in response but is not filterable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca organismos públicos (municipios, ministerios, servicios, etc.) por nombre o parte del nombre. Útil para encontrar el CodigoOrganismo de una institución o municipio específico, como "Alto del Carmen", "Municipalidad de Santiago" o "Ministerio de Salud". El CodigoOrganismo retornado puede usarse directamente en buscar_licitaciones y buscar_ordenes_de_compra.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | No | Tu ticket de acceso a la API de Mercado Público. Puedes obtenerlo en https://api.mercadopublico.cl/modules/IniciarSesion.aspx. Si el servidor fue configurado con la variable de entorno MERCADO_PUBLICO_TICKET, este parámetro es opcional. | |
| nombre | Yes | Nombre o parte del nombre del organismo a buscar. La búsqueda es insensible a mayúsculas/minúsculas. Ejemplos: "Alto del Carmen", "Santiago", "Ministerio de Salud", "CONAF". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions case-insensitive search, partial name matching, and that the response includes a CodigoOrganismo. It lacks details on pagination or error handling, but for a simple search tool, this is sufficient.
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, front-loaded with purpose, no extraneous words. Every sentence earns its place, making it easy to scan 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 output schema, description compensates by mentioning the returned CodigoOrganismo and its integration with other tools. It covers all needed context for an agent to use this tool 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 100%, so baseline is 3. Description adds value by explaining that 'ticket' is optional if environment variable is set, and that 'nombre' is case-insensitive with examples, going beyond schema descriptions.
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 public organizations by name, provides concrete examples (e.g., 'Alto del Carmen', 'Ministerio de Salud'), and explains its utility for finding CodigoOrganismo. This distinguishes it from sibling tools like buscar_licitaciones.
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?
Description explicitly states the tool is useful for finding CodigoOrganismo to use in buscar_licitaciones and buscar_ordenes_de_compra, and gives example queries. It does not mention when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca un proveedor en el registro de Mercado Público por su RUT. Retorna el código numérico interno, nombre y datos de registro del proveedor. El código retornado (CodigoProveedor) puede usarse en buscar_licitaciones y buscar_ordenes_de_compra.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | No | Tu ticket de acceso a la API de Mercado Público. Puedes obtenerlo en https://api.mercadopublico.cl/modules/IniciarSesion.aspx. Si el servidor fue configurado con la variable de entorno MERCADO_PUBLICO_TICKET, este parámetro es opcional. | |
| rut | Yes | RUT de la empresa proveedora con puntos, guión y dígito verificador. Ejemplo: 70.017.820-k |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes a search operation returning data, which is likely non-destructive, but does not explicitly state behavioral traits like idempotency, authorization needs, or side effects. The description is adequate but could be more transparent.
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 with no wasted words. The first sentence states the core purpose, and the second provides actionable output information. Extremely concise and well-structured.
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, the description explains what is returned and how to use the result. It covers input sufficiently and provides integration context with sibling tools. Complete enough for a simple lookup 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 100%, baseline 3. The description adds value by clarifying that the ticket is optional if the MERCADO_PUBLICO_TICKET environment variable is set, and provides an example RUT format. This goes beyond the schema's raw descriptions.
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 a supplier by RUT, specifies the returned data (internal code, name, registration), and distinguishes its use from sibling tools by mentioning the returned code can be used in buscar_licitaciones and buscar_ordenes_de_compra.
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 the tool should be used to look up a supplier by RUT, and provides context that the result can feed into other tools. However, it does not explicitly state when not to use it or mention alternatives, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve CÓMO realizar las consultas: qué parámetros lógicos se aceptan y los anexos/diccionarios (ej: qué número es "Licitación Pública").
| Name | Required | Description | Default |
|---|---|---|---|
| entidad | Yes | Entidad para la cual deseas conocer los parámetros y anexos de consulta. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a safe read operation returning metadata, but does not elaborate on output format, scope, or any potential limitations.
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?
Single, clear sentence that is front-loaded and contains no extraneous information. Highly 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?
Given the tool's simplicity, the description is adequate but could mention the output format or that it provides dictionary mappings. Still well-functioning for its purpose.
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 100% with an enum and description for the parameter. The description adds no additional meaning beyond what is already in the schema.
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?
Description clearly states the tool returns metadata about how to perform queries and dictionaries. However, it does not explicitly distinguish it from sibling help tools like 'ayuda' or 'estructura'.
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 guidance on when to use this tool versus alternatives such as 'ayuda' or 'estructura'. The description lacks any conditional or comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Muestra ejemplos reales de URLs y rutas soportadas (JSON, XML) con sus combinaciones, para saber cómo se arma exactamente una ruta HTTP hacia la API.
| Name | Required | Description | Default |
|---|---|---|---|
| entidad | Yes | Entidad para la cual deseas conocer los ejemplos de llamados y URLs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions only that it displays examples, implying no side effects, but does not explicitly state read-only behavior or any other traits. Since the description carries the full burden, it lacks sufficient 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?
A single sentence that efficiently states the tool's purpose and what it does. It is front-loaded, with no extraneous content. Could be slightly improved with structure, but adequate.
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 simple tool with one parameter and no output schema, the description is fairly complete. It tells the user what the tool does and implies the output is a set of example URLs. Minor missing details like output format, but acceptable.
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 covers the parameter 'entidad' with a description and enum. The tool description does not add additional meaning beyond the schema; thus baseline 3 applies.
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 that the tool shows real examples of URLs and supported routes (JSON, XML) with their combinations to explain how to construct HTTP routes. The verb 'Muestra' and resource 'ejemplos de URLs y rutas' are specific and differentiate from sibling tools that perform actual API calls.
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 it is for learning URL construction, but fails to mention scenarios like 'when you need to see the exact format of an API endpoint' or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve única y exclusivamente la anatomía del JSON de respuesta que entrega la API (qué campos retornan, sus tipos, y estructura de anidación).
| Name | Required | Description | Default |
|---|---|---|---|
| entidad | Yes | Entidad para la cual deseas conocer su estructura de respuesta JSON. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It transparently states the tool only returns structural information, not actual data. There are no side effects or authorization notes, but for a read-only metadata tool this is adequate.
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?
A single sentence with no extraneous words. The verb 'Devuelve' is front-loaded, immediately indicating the action. Every word earns its place.
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 single parameter, no output schema, and no nested objects, the description fully covers what the tool does. It explicitly states the return type (JSON anatomy) and scope (fields, types, nesting).
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 100%, with the parameter 'entidad' described as 'Entidad para la cual deseas conocer su estructura de respuesta JSON.' The description adds no additional parameter details beyond the schema, so baseline 3 applies.
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 uses a specific verb ('Devuelve') and resource ('anatomía del JSON de respuesta'), clearly stating it returns the JSON structure (fields, types, nesting) for a given entity. The phrase 'única y exclusivamente' distinguishes it from data-fetching tools like obtener_licitacion.
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 when needing to understand the response format of a specific entity. It does not explicitly state when not to use it or name alternatives, but the focus on 'solo estructura' and sibling tool names (e.g., obtener_licitacion) provide implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retorna la lista completa de organismos públicos (compradores) registrados en Mercado Público. Incluye nombre y código numérico de cada organismo. El código (CodigoOrganismo) puede usarse en buscar_licitaciones y buscar_ordenes_de_compra. Para buscar por nombre de municipio o institución usa la herramienta buscar_organismo.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | No | Tu ticket de acceso a la API de Mercado Público. Puedes obtenerlo en https://api.mercadopublico.cl/modules/IniciarSesion.aspx. Si el servidor fue configurado con la variable de entorno MERCADO_PUBLICO_TICKET, este parámetro es opcional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the optional ticket parameter and that the ticket can be obtained from a specific URL. It implies a read-only operation and doesn't mention destructive behavior, which is appropriate for a listing tool.
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: first states purpose, second provides usage guidance and sibling reference. No wasted words, front-loaded.
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 simple tool with one optional parameter and no output schema, the description fully explains what it returns and how to use the code. It also references a sibling tool for different use cases.
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 100% with a detailed description for the ticket parameter. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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 it returns the complete list of public agencies (compradores) with name and numeric code. It distinguishes from sibling buscar_organismo which is for searching by name.
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?
Explicitly says when to use (for full list) and when not (use buscar_organismo for name search). Also explains how the code can be used in other tools.
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 una licitación específica por su código único. Formato del código: XXXX-X-XXXXX (ej: 1509-5-L114). Retorna info detallada: ítems, fechas, montos, organismo comprador, adjudicación y estado.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | No | Tu ticket de acceso a la API de Mercado Público. Puedes obtenerlo en https://api.mercadopublico.cl/modules/IniciarSesion.aspx. Si el servidor fue configurado con la variable de entorno MERCADO_PUBLICO_TICKET, este parámetro es opcional. | |
| codigo | Yes | Código único de la licitación. Formato: XXXX-X-XXXXX (ej: 1509-5-L114). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the retrieved data (items, dates, amounts, buyer, award, status) and implies a read-only operation ('obtiene el detalle'). It does not discuss side effects, permissions, or potential errors, but the read nature is clear.
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 concise sentences with no wasted words. The first sentence states the primary purpose, and the second adds format details and return data overview. Information is front-loaded effectively.
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 absence of an output schema, the description adequately outlines return fields (items, dates, amounts, etc.) and code format. It lacks error information or rate limits, but for a simple retrieval tool, it provides sufficient context for an AI agent to understand the scope.
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 baseline is 3. The description adds value by explaining the code format in context and listing the types of returned information, which supplements the schema's parameter descriptions.
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 retrieves the complete detail of a specific procurement (licitación) by its unique code. The verb 'Obtiene' and the resource 'licitación específica por su código único' are specific. Among siblings like 'buscar_licitaciones' (search), this tool is distinct as it targets a single known entity.
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 the code format and what information is returned, implying use when a specific code is known. It does not explicitly state when not to use or suggest alternatives, but the context of sibling tools (e.g., 'buscar_licitaciones') makes the intended usage clear.
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 una orden de compra por su código único. Formato del código: XXXX-XXX-XXXXX (ej: 2097-241-SE14). Retorna ítems, montos, proveedor, organismo comprador y estado.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | No | Tu ticket de acceso a la API de Mercado Público. Puedes obtenerlo en https://api.mercadopublico.cl/modules/IniciarSesion.aspx. Si el servidor fue configurado con la variable de entorno MERCADO_PUBLICO_TICKET, este parámetro es opcional. | |
| codigo | Yes | Código único de la OC. Formato: XXXX-XXX-XXXXX (ej: 2097-241-SE14). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It states the tool returns full details and lists return fields, but does not disclose authentication needs (besides ticket parameter), rate limits, or side effects. Basic 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?
Two sentences, front-loaded with purpose and format, no fluff. Every sentence adds 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?
For a retrieval tool with no output schema, the description lists key return fields, compensating for the lack of schema. Adequate given low complexity (2 parameters).
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 100%, so the schema already describes both parameters well. The description adds value by providing a code format example and clarifying return content, which aids understanding beyond the schema.
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 retrieves complete details of a purchase order by its unique code, including format example and return fields. This distinguishes it from sibling tools like 'buscar_ordenes_de_compra' which likely perform searches.
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 when a specific code is known but lacks explicit guidance on when not to use or alternatives. No mention of prerequisites or comparison to siblings.
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.0.4ayudabuscar_licitacionesbuscar_licitaciones_rangobuscar_ordenes_de_comprabuscar_organismobuscar_proveedorconsultasejemplos_urlestructuralistar_compradoresobtener_licitacionobtener_orden_de_compraScored across 12 tools
Each tool has a clearly distinct purpose: help, searching licitaciones (daily and range), purchase orders, organizations, suppliers, plus detail retrieval and auxiliary documentation tools. No two tools overlap in functionality, and descriptions are precise.
Tool names use consistent Spanish snake_case style. Most follow a verb_noun pattern (buscar_*, listar_*, obtener_*), though a few are noun-only (ayuda, consultas, estructura, ejemplos_url). This minor deviation is still predictable and readable.
12 tools is well-scoped for a public procurement data server. It covers essential operations: search, detail retrieval, and lookups, along with helpful documentation tools, without being overwhelming or too sparse.
The tool set covers the full lifecycle of procurement data querying: searching licitaciones and orders by various filters, retrieving details, looking up organizations and suppliers, listing buyers, and providing API reference tools. No obvious gaps for the intended domain.
Chile Government Procurement MCP — Mercado Público / ChileCompra (keyless-ish).
Brazilian public procurement (PNCP): search, deadlines, tender markdown, alerts and watches.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Search Brazilian government tenders and public procurement (PNCP): find notices and auctions by keyw