MCP Mercado Público

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.4
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.1/5 across 12 of 12 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-mercado-publico MCP server](https://glama.ai/mcp/servers/NicolasAEV/mcp-mercado-publico/badges/card.svg)](https://glama.ai/mcp/servers/NicolasAEV/mcp-mercado-publico)

Score Badge

Copy to your README.md:

[![mcp-mercado-publico MCP server](https://glama.ai/mcp/servers/NicolasAEV/mcp-mercado-publico/badges/score.svg)](https://glama.ai/mcp/servers/NicolasAEV/mcp-mercado-publico)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NicolasAEV/mcp-mercado-publico'

If you have feedback or need assistance with the MCP directory API, please join our Discord server