Compra Ágil MCP Server

by ssolis-ti

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation5/5
Each tool targets a distinct function: auditing desiertas, searching, document handling, quotation generation, monitoring, details, order verification, and opportunity scoring. No two tools have overlapping purposes, and descriptions clearly differentiate them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in Spanish (e.g., 'auditar_compras_desiertas', 'buscar_compras_agiles', 'generar_borrador_cotizacion'). The naming is predictable and aids an agent in understanding tool roles.
Tool Count5/5
With 13 tools, the set is well-scoped for the domain of Chilean public procurement (Compra Ágil). Each tool addresses a specific need without redundancy, covering search, detail, document handling, analytics, and recommendations.
Completeness4/5
The tool surface covers the core lifecycle: searching, obtaining details, auditing, generating quotations, monitoring changes, and verifying orders. Minor gaps exist, such as lack of tools to directly list all orders for a buyer or manage user profiles, but these are not essential for the primary use case.
Average 4/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 14 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It describes download and extraction but omits details on error handling, return format, or caching. The max_caracteres parameter context is a plus.
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 that front-load the action and context. Every sentence adds value with no redundant information.
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 no output schema or annotations, the description is adequate but incomplete. It doesn't specify return format, failure scenarios, or what happens with non-PDF documents. More detail would improve completeness.
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 covers 100% of parameters with good descriptions. The tool description adds minimal new semantic beyond the schema, such as the purpose of max_caracteres to avoid context saturation. Baseline 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 the tool downloads, extracts text, and returns it to the LLM for auditing Mercado Público documents. It specifies the source and format, and distinguishes from siblings like 'obtener_enlace_documento' which only gets a link.
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 mentions a use case ('auditar requisitos técnicos de una oferta') but provides no explicit guidance on when not to use or mention alternatives. Usage is implied but not fully delineated.
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 of behavioral disclosure. It explains the tool calculates net, tax (19% IVA), gross amounts, and suggests market prices, which is helpful. However, it does not clarify whether the draft is saved temporarily or permanently, if it modifies any state, or what authentication or authorization is required. This leaves notable gaps.
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 two sentences: first sentence defines purpose, second explains key behaviors. It is front-loaded with the core action and avoids redundancy. However, the second sentence is somewhat dense, packing three clauses. Minor improvement could split it, but overall it is efficient 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 the tool has 6 parameters, no output schema, and no annotations, the description covers the essential aspects: what it does, automatic calculations, and fallback behavior. It lacks details on the output structure (JSON format but no shape) and side effects, but these are partially compensated by the schema parameter descriptions. Overall, it is sufficiently complete for an agent to understand the tool's role.
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 baseline is 3. The description adds overall context (e.g., automatic calculation, market price fallback) but does not provide additional semantics for individual parameters beyond what the schema already offers. For instance, 'precio_unitario_personalizado' is well-described in the schema, and the description only reiterates its effect. Thus no extra value.
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 generates a structured JSON draft for a formal quotation on an active 'Compra Ágil' call. It uses a specific verb ('genera') and resource ('borrador ... para presentar una cotización formal'), and distinguishes itself from siblings like 'buscar_compras_agiles' and 'obtener_detalle_compra' by focusing on quotation creation.
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 for quoting on a Compra Ágil by explaining automatic calculations and market price suggestion, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites. The context is clear but guidance on when-not-to-use is missing.
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 provided, so the description carries full burden. It describes the action but does not disclose error handling (e.g., invalid ID), permissions needed, or that it is a read-only operation. For a simple tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main action and includes necessary details (Mercado Público, attachment types, document ID). No wasted words, and it earns its place.
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 simplicity (1 param, no output schema), the description explains what the tool does but does not clarify the return format (e.g., returns a URL string) or error behavior. It is adequate but missing explicit output details.
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%, so baseline is 3. The description does not add additional meaning to the parameter beyond what is already in the schema's description. No extra context like validation or format is provided.
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 verb (generates), the resource (official public download link), and the context (for attachments in Mercado Público using document ID). It distinguishes itself from siblings like 'descargar_y_leer_documento' which downloads content, not just generating a link.
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 needing a public download link, but does not explicitly state when to use this tool over alternatives like 'descargar_y_leer_documento' or 'consultar_documentos_locales'. No exclusions or prerequisites are mentioned.
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 provided, so description must disclose behavior. It mentions parallel queries limited by rate limiter, which is helpful. But it does not state whether the tool is read-only (likely safe), what side effects exist, or any authentication requirements. More details on behavior are missing.
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?
Description is concise, with two short paragraphs. Main purpose is front-loaded. Could be slightly more compact, but no unnecessary sentences. The note about rate limiter is relevant.
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?
The description does not explain what the tool returns (output format) and there is no output schema. For a tool with 4 parameters and no required fields, the lack of return value information is a gap. However, the context about using historical data and the rate limiter is complete enough for basic usage.
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 covers all 4 parameters with descriptions. The description adds minimal extra meaning beyond the schema: it explains the purpose of the tool but doesn't elaborate on how parameters are used in the analysis. With 100% schema coverage, a baseline 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?
Description clearly states the function: analyzing historical closed Compra Ágil processes to recommend an optimal unit or total price for bidding. The verb 'analiza' and resource 'procesos históricos' are specific. It distinguishes from sibling tools like 'auditar_compras_desiertas' (which audits deserted processes) and 'buscar_compras_agiles' (which searches for active processes).
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 explains when to use: for estimating a competitive price before bidding. It provides input alternatives (codigo_compra or q) and notes the parameter 'limite_analisis' to control API quota. However, it does not explicitly state when not to use or contrast 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?
No annotations are provided, so the description must carry the burden. It discloses it searches and reads documents (read-only behavior), but does not mention authentication needs, rate limits, or limitations on file size/encoding. Adequate but minimal.
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, front-loaded sentence that conveys the main purpose, supported formats, and scope. No wasted words.
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?
The description lacks details on the return structure (e.g., whether it returns snippets or full paragraphs, how matches are presented). With no output schema, this is a gap. Also, no error handling info. But given the tool's simplicity, it is minimally acceptable.
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%, baseline 3. The description adds value by clarifying that omitting 'query' lists available documents. For 'max_caracteres', it restates the schema description but adds 'de cada coincidencia' for 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 and reads information from local manuals, regulations, and guides in the docs/ folder, supporting .pdf, .txt, .md formats. It distinguishes from sibling tools like 'descargar_y_leer_documento' which likely handles external documents.
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?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies local document search, but does not exclude cases where another tool might be better.
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 bears full burden. It discloses a critical behavioral trait: detailed quotes are only shown from the 'Cerrada' state on the second call onward. This adds significant value beyond a simple read operation.
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 front-loaded with the core purpose in the first sentence, then lists included details concisely. The behavioral note is appropriately placed. A minor improvement would be bullet formatting for the list.
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 detail-retrieval tool with one parameter and no output schema, the description covers all major aspects: process, products, suppliers, budget, delivery, order status, sustainability flags, and a behavioral note. It is comprehensive enough for an agent to understand what the tool returns.
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 input schema already describes the 'codigo' parameter with format and example. The description adds 'por su código único' but no additional semantics beyond the schema, consistent with high schema coverage.
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 verb 'Obtiene' (gets) and resource 'detalle completo de una Compra Ágil específica', identifying the unique code as identifier. It distinguishes from sibling tools like 'buscar_compras_agiles' (search) and 'obtener_detalle_orden_compra' (purchase order detail).
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 purchase detail is needed by its code, but provides no explicit guidance on when to use vs. alternatives (e.g., searching vs. detail retrieval) or when not to use the tool.
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 and explains the scoring algorithm (lack of bidders, budget, hours). It discloses it only works on active published processes. It does not mention rate limits, authentication, or error behaviors, but the core behavior is well covered.
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 two sentences, front-loading the action and then explaining the formula. Every word earns its place with no superfluous content.
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 no output schema, the description lacks details on the return format (fields like ID, score, etc.) and ordering. It mentions prioritization but not pagination or error handling. Adequate but incomplete.
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%, so each parameter is documented. The description adds no extra semantics beyond the schema. The baseline is 3, and the description does not enhance parameter understanding.
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 scans, scores, and classifies active 'Compra Ágil' processes using a 'Hot Score' formula. It distinguishes itself from siblings like 'buscar_compras_agiles' by emphasizing prioritization and ease of winning.
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 for finding convenient and easy-to-win opportunities but does not explicitly state when to use this tool versus alternatives like 'buscar_compras_agiles'. No exclusions or when-not-to-use guidance is provided.
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 must fully convey behavioral traits. It implies a read-only analysis by mentioning comparisons and API quota limits, but it does not explicitly state that no data is modified or require authentication. The parameter 'limite_analisis' hints at API usage, but more direct transparency would improve safety.
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 concise with two sentences, but the second sentence repeats input options already in the schema. It is well-structured and front-loaded with the primary purpose.
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?
The description explains the action and inputs but lacks details on the output format (e.g., what kind of report is generated). Without an output schema, the AI agent may not know what to expect, reducing completeness for a tool that likely returns structured analysis.
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 documents all parameters. The description adds value by explaining that 'codigo_compra' and 'q' are alternative inputs, and that 'limite_analisis' controls API quota usage. This contextual information goes beyond the schema's basic 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 audits a 'Compra Ágil' that ended with no offers, identifying reasons like tight deadlines, low budget, or restrictive requirements, and compares with successful similar processes. It distinguishes itself from siblings like 'buscar_compras_agiles' and 'obtener_detalle_compra' by focusing on post-hoc analysis.
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 indicates when to use the tool (for deserted processes) and how to input data (code or search term). However, it does not explicitly mention when not to use it or provide comparisons with alternative tools, but the context is clear enough for selection.
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 must cover behavioral traits. It implies a read-only operation (statistics and quota) but does not explicitly state it is safe or describe side effects. The description is adequate but lacks depth (e.g., authentication needs, exact output structure).
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 core function, second adds practical use case. No unnecessary words, front-loaded, and perfectly concise.
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?
The tool has no output schema, so the description should clarify what the returned statistics include. It only mentions 'usage statistics' and 'daily quota' vaguely. More detail (e.g., fields like requests limit, used, reset time) would improve completeness. Given no sophistication in schema/annotations, this is a gap.
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?
The input schema has no parameters (0 params), so schema description coverage is 100%. Per guidelines, baseline is 4. The description adds no parameter info, which is fine as there are none.
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 obtains API usage statistics and daily quota status. The verb 'obtiene' and specific resources 'estadísticas de uso' and 'cuota diaria' exactly match the tool name. It is distinct from siblings, which focus on procurement tasks.
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 explicitly states it is useful for monitoring remaining requests, providing clear context. However, it does not mention when not to use it or alternative tools, but since no sibling overlaps, this is acceptable.
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 must carry the burden. It states the return format (summary list with code, name, status, budget, institution) but does not disclose whether the tool is read-only, requires authentication, or has rate limits. It adequately describes what it returns, but lacks deeper behavioral context.
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 five sentences with no filler. First sentence states purpose, second lists filters, third describes return, fourth is a key note, fifth lists valid values. Front-loaded with purpose and 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 11 parameters and no output schema, the description covers purpose, filters, return fields, mutual exclusivity, and valid values. It doesn't explain pagination details (covered by schema), but is otherwise complete for a search tool. Could mention ordering default but not critical.
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 beyond schema by noting mutual exclusivity of 'q' and 'id', providing region code examples (e.g., 13 for Metropolitana), and listing valid statuses. This enriches the agent's understanding of parameter relationships.
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 starts with 'Busca procesos de Compra Ágil en Mercado Público de Chile.' which clearly states the action (search) and resource (agile purchase processes). It distinguishes from sibling tools by focusing on searching/filtering, while siblings like 'obtener_detalle_compra' retrieve specific details.
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 filters (keywords, status, region, date range) and explicitly notes mutual exclusivity of 'q' and 'id'. Lists valid statuses and region codes. However, it does not explicitly state when to use this tool over alternatives, though it is implied by its search nature.
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 provided, so the description carries the full burden. It discloses that the tool returns information about amounts, buyer, supplier, and product list, implying a read-only retrieval. However, it does not explicitly state side effects, permissions, or other behavioral traits.
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 two sentences, thoroughly informative without unnecessary words. It efficiently conveys the tool's purpose, input, and output, earning its place.
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 a simple tool with one parameter, no annotations, and no output schema, the description adequately explains what it returns (amounts, buyer, supplier, line items). It is complete for its complexity level.
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?
The schema has 100% coverage for the single parameter, and the description adds value by explaining that it accepts both numeric ID and alphanumeric code, with an example format (e.g., '1057532-156-AG26'). This goes beyond the schema's description.
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 full detail of a purchase order from Chile's Mercado Público, specifying accepted inputs (numeric ID or alphanumeric code) and output fields (amounts, buyer, supplier, line items). This specificity distinguishes it from sibling tools.
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 when you have an order code and need complete details. It does not explicitly state when not to use or provide alternatives, but the context is clear and the input description guides appropriate use.
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 internal conversion of minutes to milliseconds and hints at pagination via parameters. However, it does not mention rate limits or output format, but overall it adds useful behavioral context.
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 three sentences with no wasted words. It is front-loaded with the core functionality, followed by ideal use and an internal detail. Highly concise and well-structured.
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?
The tool has 5 optional parameters and no output schema. The description explains the purpose and filter combinations but does not describe the output structure (fields returned, pagination behavior). It is adequate but leaves gaps for an agent to fully understand the response.
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%, giving a baseline of 3. The description adds value by explaining the conversion of 'minutos' to milliseconds and providing usage examples (e.g., '60 = última hora'), beyond the schema's documentation.
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 verb 'Busca' (searches) and the resource 'Compras Ágiles' with a specific time filter (creadas o modificadas en los últimos N minutos). It distinguishes itself from siblings like 'buscar_compras_agiles' which likely lacks the time filter.
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 says 'Ideal para monitoreo de nuevas oportunidades de negocio y alertas en tiempo real', providing clear use cases. It also mentions combinability with state and region filters, but does not explicitly state when not to use or contrast with alternatives.
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?
Since no annotations are provided, the description carries the full burden. It explains the tool's workaround behavior: consulting process details and cross-referencing with the Órdenes de Compra API. It does not mention permissions or side effects, but the behavior is clearly described for a verification 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 with no redundant information. The key limitation is highlighted using 'IMPORTANTE', making it easy to scan. Every sentence adds value.
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 single parameter and no output schema, the description adequately covers the tool's purpose and behavior. It could be improved by specifying the output format (e.g., boolean or OC id), but it is still complete for the tool's complexity.
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?
The only parameter (codigo) is fully described in the schema, but the description adds value by providing the required format with an example (XXXXXX-YYY-COTXX), which helps agents construct correct inputs.
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's purpose: verifying whether a specific 'Compra Ágil' has an issued purchase order. It includes a specific verb (verifica), resource (Compra Ágil), and output (OC emitida). This distinguishes it from sibling tools like 'obtener_detalle_compra' and 'obtener_detalle_orden_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 explicitly warns that the API's 'oc_emitida' status does not work in practice, advising agents to use this tool instead. While it does not list all alternatives, it provides clear context for when to use this tool over other methods.
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:

[![compra-agil-mcp MCP server](https://glama.ai/mcp/servers/ssolis-ti/compra-agil-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ssolis-ti/compra-agil-mcp)

Score Badge

Copy to your README.md:

[![compra-agil-mcp MCP server](https://glama.ai/mcp/servers/ssolis-ti/compra-agil-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ssolis-ti/compra-agil-mcp)

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/ssolis-ti/compra-agil-mcp'

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