MCP Argentina Datos

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting different data domains (diputados, dólares, eventos, feriados, salud, senado), but there is some overlap between 'diputados-actas' and 'diputados-actas-por-anio' where the latter could be seen as a filtered version of the former. Similarly for 'senado-actas' and 'senado-actas-por-anio'. However, the descriptions clarify the differences, so confusion is minimal.
Naming Consistency3/5
The naming is mixed with some patterns: most use snake_case, but there's inconsistency in verb usage (e.g., 'get-feriados' uses 'get' while others use 'devuelve' implicitly). Tools like 'dolares-por-casa' and 'dolares-por-casa-fecha' follow a logical structure, but overall, the conventions vary without a strict verb_noun pattern, making it readable but not highly consistent.
Tool Count4/5
With 13 tools, the count is reasonable for a server covering multiple Argentine data domains (legislative, currency, events, holidays, health). It's slightly on the higher side but well-scoped, as each tool serves a specific query without obvious redundancy, fitting the broad purpose effectively.
Completeness4/5
The tool set covers key areas like legislative data (diputados, senado), currency rates (dólares), events, holidays, and API health, with good granularity (e.g., year-specific queries). Minor gaps exist, such as no update or delete operations, but this is typical for a read-only data API, and agents can work around this for querying purposes.
Average 2.9/5 across 13 of 13 tools scored. Lowest: 2.2/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/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 only states what the tool does at a superficial level ('returns the deputies') without any information about permissions, rate limits, data format, pagination, or whether it's a read-only operation. This is inadequate for a tool with zero annotation coverage.
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 extremely concise—a single Spanish phrase—with no wasted words. It's front-loaded and gets straight to the point, though this brevity comes at the cost of completeness. For its length, every word earns its place in conveying the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and the presence of sibling tools, the description is incomplete. It doesn't explain what 'diputados' entails (e.g., current legislators, historical data, or something else), how results are returned, or how it differs from related tools like 'diputados-actas'. This leaves significant gaps for an AI agent to understand and use the tool effectively.
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 tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as the description doesn't contradict the empty parameter set and the schema fully covers the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Devuelve los diputados' (Returns the deputies) is a tautology that essentially restates the tool name 'diputados' in Spanish. It doesn't specify what kind of deputies (e.g., legislative, political party, timeframe) or what operation is performed (list, search, filter). While it indicates a retrieval action, it lacks specificity about scope or resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'diputados-actas' and 'diputados-actas-por-anio' that appear related, there's no indication of how this tool differs (e.g., whether it returns current deputies, all historical deputies, or basic information vs. detailed records). No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool returns events, implying a read-only operation, but does not specify aspects like data format, rate limits, authentication needs, or whether it's a query or static list. This lack of detail makes it insufficient for understanding the tool's behavior beyond a basic action.
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, clear sentence in Spanish: 'Devuelve los eventos presidenciales'. It is front-loaded with the core action and resource, with no unnecessary words or structural fluff. This makes it highly concise and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with no parameters) and the absence of annotations and output schema, the description is incomplete. It fails to explain what 'eventos presidenciales' includes (e.g., types of events, date ranges, or return format), leaving gaps in understanding the tool's full context and output.
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 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not add parameter details, which is appropriate since there are none to describe. This aligns with the baseline score of 4 for tools with zero parameters, as no additional semantic information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Devuelve los eventos presidenciales' (Returns presidential events) is a tautology that essentially restates the tool name 'eventos-presidenciales' in Spanish. It specifies a verb ('devuelve') and resource ('eventos presidenciales'), but lacks detail about what these events entail or how they differ from other political tools like 'diputados' or 'senadores'. This makes it vague and minimally informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, and fails to differentiate it from sibling tools such as 'get-feriados' or 'diputados-actas'. This absence of usage instructions leaves the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states that it returns senators, without mentioning any behavioral traits such as whether it's a read-only operation, if it requires authentication, rate limits, pagination, or what format the output takes. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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, straightforward sentence: 'Devuelve los senadores.' It's front-loaded and wastes no words, making it highly concise. However, it could be slightly improved by adding a bit more context without losing efficiency, but it's appropriately sized for its minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'returns the senators' entails—e.g., is it a list, details, current data? With no output schema and no annotations, the description should provide more context about the return value and behavior to be fully helpful, but it falls short.
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 tool has 0 parameters, and the input schema has 100% description coverage (though empty). With no parameters, the description doesn't need to add parameter semantics. The baseline for 0 parameters is 4, as there's nothing to compensate for, and the description doesn't contradict or confuse the parameterless nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Devuelve los senadores' (Returns the senators) states a clear verb ('devuelve') and resource ('senadores'), making the basic purpose understandable. However, it lacks specificity about what exactly is returned (e.g., list of senators, their details, current vs historical) and doesn't distinguish from sibling tools like 'senado-actas' or 'senado-actas-por-anio' that also relate to the senate. This makes it vague rather than specific.
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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to legislative data (e.g., 'diputados', 'senado-actas'), but the description doesn't indicate if this is for current senators, historical data, or how it differs from other tools. Without any context on usage scenarios or exclusions, it offers minimal practical help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool returns minutes but doesn't specify what 'actas' entails (e.g., format, content, or scope), whether it's a read-only operation, if there are rate limits, or how results are structured. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a no-parameter tool, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'actas' includes (e.g., metadata, full text, dates), how results are returned (e.g., list, pagination), or any constraints. For a tool that likely returns structured data, more context is needed to guide effective use.
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 tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional value is required, but it also doesn't compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Devuelve las actas de los diputados' (Returns the minutes/records of the deputies) clearly states the tool's purpose with a specific verb ('devuelve') and resource ('actas de los diputados'). However, it doesn't distinguish this tool from its sibling 'diputados-actas-por-anio' (deputies minutes by year), which likely serves a similar purpose with additional filtering. The description is adequate but lacks sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'diputados-actas-por-anio' or explain if this tool returns all minutes without filtering (e.g., by year) or has other contextual constraints. Without such guidance, users must infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. While it correctly describes a read operation ('Devuelve' - returns), it doesn't mention any behavioral traits like pagination, rate limits, authentication requirements, error conditions, or what happens when no data exists for the specified year. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a simple tool with one parameter and gets straight to the point. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what the return value contains (e.g., list of minutes, their structure, or metadata), nor does it address potential edge cases or error scenarios. For a data retrieval tool with no structured output documentation, the description should provide more context about what to expect from the response.
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 description adds minimal value beyond the input schema, which already has 100% coverage. It mentions the year parameter ('de un año específico') but doesn't provide additional context about valid ranges, format expectations beyond the schema's example, or how the year parameter affects the returned data. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate with meaningful parameter insights.
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 the verb ('Devuelve' - returns) and resource ('actas de los diputados' - deputies' minutes), making the purpose understandable. It specifies the scope ('de un año específico' - for a specific year), which helps distinguish it from the sibling tool 'diputados-actas' that likely returns all minutes without year filtering. However, it doesn't explicitly differentiate from other sibling tools like 'senado-actas-por-anio' which serves a similar function for senators.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'diputados-actas' (which likely returns all minutes without year filtering) or 'senado-actas-por-anio' (which serves senators instead of deputies). There's no indication of prerequisites, constraints, or typical use cases beyond the basic year parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose whether this is a read-only operation, what format the holidays are returned in, whether there are rate limits, or what happens with invalid years. 'Devuelve' implies a query operation but lacks operational details.
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, efficient sentence that directly states the tool's function with zero wasted words. It's appropriately sized for a simple parameterized query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the holidays are returned in (dates, names, types), whether the year parameter has constraints, or what happens with edge cases. The description alone doesn't provide enough context for reliable tool invocation.
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% with the parameter 'year' well-documented in the schema. The description adds that it's for 'un año específico' (a specific year) which aligns with but doesn't significantly expand beyond the schema's 'EJ: 2025' example. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Devuelve' - returns) and resource ('feriados' - holidays) with a specific scope ('de un año específico' - for a specific year). It distinguishes from the sibling 'get-feriados' by specifying the timeframe parameter requirement, though not explicitly contrasting functionality.
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 is provided on when to use this tool versus alternatives like 'get-feriados' or other date-related tools. The description only states what it does, not when it's appropriate or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool returns API health status, which implies a read-only, non-destructive operation, but it doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'health' entails (e.g., uptime, metrics). For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose. It's front-loaded with no wasted words, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (simple health check) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the return value includes (e.g., status codes, metrics), potential errors, or operational context. For a tool with no structured data beyond the input schema, more detail would be helpful.
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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description doesn't add parameter semantics, but that's appropriate here. Baseline is 4 for 0 parameters, as it avoids unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Devuelve el estado de la salud de la API' clearly states the tool's purpose (returns API health status) with a specific verb ('devuelve') and resource ('estado de la salud de la API'), but it doesn't distinguish this from any sibling tools. Since there are no obvious health-check siblings in the list, this is adequate but not exceptional.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or context for checking API health, nor does it reference any sibling tools for comparison. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool returns data ('devuelve'), implying a read-only operation, but doesn't clarify aspects like rate limits, authentication needs, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence: 'Devuelve las actas del senado de un año específico'. It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. Every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It lacks details on return values (e.g., format, structure), error cases, or behavioral traits. While concise, it doesn't provide enough context for an agent to fully understand how to use the tool effectively beyond the basic parameter.
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 description adds minimal meaning beyond the input schema. It mentions 'un año específico' (a specific year), which aligns with the 'anio' parameter documented in the schema with 100% coverage. However, it doesn't provide additional context like valid year ranges or format details. With high schema coverage, the baseline is 3, as the description doesn't compensate with extra insights.
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 the tool's purpose: 'Devuelve las actas del senado de un año específico' (Returns the senate minutes for a specific year). It specifies the verb ('devuelve' - returns) and resource ('actas del senado' - senate minutes), making the function unambiguous. However, it doesn't explicitly distinguish from sibling tools like 'senado-actas' (which likely returns all minutes without year filtering), missing full differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'senado-actas' (which might return all minutes) or 'senadores' (which might return senator data), nor does it specify prerequisites or exclusions. Usage is implied only by the parameter 'anio', but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool returns exchange rates but doesn't describe the return format (e.g., JSON structure, units), potential errors (e.g., invalid 'casa' values), rate limits, or authentication needs. For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the core function and appropriately sized for a simple tool with one parameter. Every part of the sentence earns its place by specifying what is returned and for what resource.
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's low complexity (one parameter, no nested objects, no output schema) and 100% schema coverage, the description is minimally adequate. However, without annotations or an output schema, it lacks details on return values, error handling, and behavioral context. For a data retrieval tool, this leaves room for improvement in completeness, but it's not critically 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?
The schema description coverage is 100%, with the single parameter 'casa' documented as 'EJ: blue, oficial, cripto, etc.' The description adds no additional parameter semantics beyond what the schema provides. Since the schema fully covers the parameter, the baseline score of 3 is appropriate, as the description doesn't need to compensate but also doesn't add extra value.
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 the tool's purpose: 'Devuelve las cotizaciones del dólar de la casa de cambio especificada' (Returns the dollar exchange rates for the specified exchange house). It specifies the verb ('devuelve' - returns) and resource ('cotizaciones del dólar' - dollar exchange rates), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'dolares-historico' or 'dolares-por-casa-fecha', which likely serve related purposes.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'dolares-historico' (likely for historical data) or 'dolares-por-casa-fecha' (likely for date-specific queries), nor does it specify prerequisites, exclusions, or appropriate contexts. The user must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('devuelve' - returns) but doesn't mention potential limitations like rate limits, authentication requirements, error conditions, or what happens with invalid dates/houses. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 perfectly concise - a single sentence that efficiently communicates the core functionality and includes the date format specification. Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose and parameter format but lacks guidance on usage context, behavioral constraints, and output expectations. The absence of annotations and output schema means the description should do more to compensate.
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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by specifying the date format (YYYY/MM/DD) and implying this is for exchange rate queries, but doesn't provide additional context about parameter semantics or usage examples.
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 the tool's purpose: 'Devuelve la cotización del dólar de la casa de cambio especificada en la fecha indicada' (Returns the dollar exchange rate of the specified exchange house on the indicated date). It uses specific verbs ('devuelve' - returns) and resources ('cotización del dólar' - dollar exchange rate), though it doesn't explicitly differentiate from sibling tools like 'dolares-historico' or 'dolares-por-casa'.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'dolares-historico' or 'dolares-por-casa', nor does it specify any prerequisites, exclusions, or contextual constraints beyond the basic parameter requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool returns senate minutes but doesn't describe any behavioral traits, such as whether it's read-only, if it requires authentication, rate limits, or what format the data is in. This is a significant gap for a tool with no annotation coverage.
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, clear sentence: 'Devuelve las actas del senado.' It is front-loaded with the core purpose, has no unnecessary words, and efficiently conveys the tool's function without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return values are (e.g., format, structure, or content of the actas), which is crucial for an agent to understand the tool's output. This leaves gaps in understanding how to use the tool effectively.
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 tool has 0 parameters, and the schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional value is required here.
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 'Devuelve las actas del senado' clearly states the tool's purpose: it returns the minutes/records of the senate. It uses a specific verb ('devuelve') and resource ('actas del senado'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'senado-actas-por-anio', which suggests a similar function with year filtering, so it misses full sibling distinction.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as how it differs from 'senado-actas-por-anio' (which likely filters by year). This lack of comparative information leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool returns exchange rates but does not specify behavioral traits like data freshness, rate limits, error handling, or authentication needs. For a tool with zero annotation coverage, this is a significant gap, as it leaves the agent guessing about operational details. The description does not contradict any annotations, but it lacks essential 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 a single, efficient sentence: 'Devuelve las cotizaciones de todas las casas de cambio.' It is front-loaded with the core purpose, has zero waste, and is appropriately sized for a tool with no parameters. Every word earns its place, making it 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?
Given the tool's complexity (simple, no parameters) and lack of annotations or output schema, the description is minimally complete. It states what the tool does but does not provide enough context for effective use, such as output format, data scope (e.g., historical vs. current), or error handling. With no output schema, the description should ideally explain return values, but it does not. This makes it adequate but with clear gaps, scoring a 3.
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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description does not need to add parameter semantics beyond the schema. According to the rules, 0 parameters baseline is 4, as the description appropriately focuses on the tool's purpose without unnecessary parameter details.
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 'Devuelve las cotizaciones de todas las casas de cambio' clearly states the tool's purpose: returning exchange rates from all exchange houses. It uses a specific verb ('devuelve') and resource ('cotizaciones'), but does not explicitly distinguish it from sibling tools like 'dolares-por-casa' or 'dolares-por-casa-fecha', which likely provide more specific data. This clarity earns a 4, as it's understandable but lacks sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, such as comparing it to sibling tools like 'dolares-por-casa' for per-house data or specifying if it returns historical or current rates. Without such information, the score is 2, as there is minimal implicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool returns holidays but doesn't disclose behavioral traits like whether it's read-only, requires authentication, has rate limits, returns structured data, or handles errors. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's function. It's appropriately sized and front-loaded with the core purpose, with no wasted words or unnecessary elaboration.
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's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It states what the tool does but lacks behavioral context, output details, or usage guidance. For a tool with no structured metadata, the description should do more to compensate, but it meets the bare minimum.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter semantics, and it correctly implies no parameters are needed by stating it returns holidays for the year without mentioning inputs. Baseline 4 is appropriate for zero-parameter tools.
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 'Devuelve los feriados del año' clearly states the verb ('devuelve' - returns) and resource ('feriados del año' - holidays of the year). It's specific about what the tool does, though it doesn't explicitly differentiate from its sibling 'get-feriados-timeframe' beyond the implied scope difference (year vs timeframe).
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 is provided on when to use this tool versus alternatives. While the name suggests it returns holidays for a year, there's no explicit comparison with 'get-feriados-timeframe' or indication of prerequisites. The description assumes usage context without stating it.
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-argentina-datos MCP server](https://glama.ai/mcp/servers/0xKoller/mcp-argentina-datos/badges/card.svg)](https://glama.ai/mcp/servers/0xKoller/mcp-argentina-datos)

Score Badge

Copy to your README.md:

[![mcp-argentina-datos MCP server](https://glama.ai/mcp/servers/0xKoller/mcp-argentina-datos/badges/score.svg)](https://glama.ai/mcp/servers/0xKoller/mcp-argentina-datos)

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/0xKoller/mcp-argentina-datos'

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