mcp-rosario-municipal

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Tools fall into clear categories (general query, search sources, domain-specific info), but buscar_fuentes, buscar_instructivos, and buscar_web_oficial share overlapping search purposes and could be confused without careful description reading.
Naming Consistency4/5
Most tools follow a verb_noun pattern (buscar_*) or domain_info pattern (*_info), but detalle_fuente and consulta_ciudadana deviate slightly from this convention, making the naming less uniform.
Tool Count5/5
With 10 tools, the server is well-scoped for a municipal information assistant, providing enough coverage without unnecessary redundancy.
Completeness4/5
The server covers the core citizen-information lifecycle well, including source search, news, procedures, and orientations. It intentionally omits transactional actions, but could add directories or event searches to be fully comprehensive.
Average 3.5/5 across 10 of 10 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 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?
Since no annotations are provided, the description carries full responsibility for disclosing behavior. It fails to mention whether this is a read-only lookup, what actions are performed, whether it returns external links or generates text, or any side effects or prerequisites. This is a severe gap for any tool, especially one without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It consists of a single vague phrase that does not carry enough information to be useful. While every word is purposeful, it omits essential details, so it only earns a low score.
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 has one optional parameter, no output schema, and no annotations, the description is the only source of guidance. It is far too minimal to allow an agent to understand what the tool returns or how to invoke it effectively. The sibling tools provide some context, but that is external and not stated in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'consulta' with no description, and the tool description does not explain what should be passed in it. With 0% schema description coverage, the description should compensate, but it never mentions the parameter. The agent has no way to know the expected format or content of 'consulta'.
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 uses a verb 'Orientar' (to guide) and identifies a resource (municipal procedures and official search engines), but it is vague about what the tool actually does—whether it searches, retrieves links, or provides summaries. It does not distinguish itself from siblings like consulta_ciudadana or buscar_fuentes, which likely overlap in purpose.
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 its siblings. The phrase 'generales' implies it is for general cases, but there is no explicit comparison or exclusion, such as 'for specific complaints, use reclamos_info'.
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?
It discloses that the tool is read-only and uses official URLs, which is useful since annotations are absent. However, it doesn't explain what happens if no adapter exists or describe any error/performance characteristics.
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 brief and front-loaded, conveying live search, adapter condition, and read-only nature in three short sentences. No redundant 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 lack of annotations and output schema, the description leaves gaps about expected results, error behavior, and the adapter concept. It's adequate for a simple tool but lacks full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'consulta' with 0% coverage in the description. The description doesn't add any extra meaning beyond the parameter name, which is self-explanatory as a search query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs live searches on official websites using adapters, which distinguishes it from sibling search tools like buscar_noticias or buscar_fuentes. The condition 'cuando existe adaptador' adds some ambiguity but doesn't obscure the core purpose.
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 an adapter is available, but it doesn't provide explicit guidance on when to choose this tool over alternatives like buscar_fuentes or consulta_ciudadana. No exclusions or when-not cases 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses limitations (not personal debt, not processing payments), which is positive transparency, but it does not describe what the tool actually returns or how it operates. The term 'orientar' suggests informational output, but no specifics are given.
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, concise sentence that front-loads the purpose and includes clear boundaries. Every part is useful and there is no redundant information.
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 simple structure (one parameter, no output schema, no annotations), the description should still compensate for the complete lack of parameter information. It does not, leaving the agent with an uninterpretable 'consulta' parameter. The description is too minimal to fully support invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'consulta' with no description and schema description coverage is 0%. The tool description does not explain what this parameter should contain, such as whether it expects a free-text question or a specific code. This is a significant gap given the low schema coverage.
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 states the tool's purpose: 'Orientar sobre pagos/tasas/tributos' (guide on payments/fees/taxes), using a specific verb and resource. It also distinguishes itself by stating limits: 'no consulta deuda personal ni procesa pagos' (does not consult personal debt nor process payments), which differentiates from potential sibling tools. However, 'orientar' is a slightly vague verb compared to more explicit actions like 'list' or 'create'.
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 provides implicit usage boundaries by stating what the tool does NOT do (personal debt consultation, payment processing). This helps an agent decide when not to use it, but it does not explicitly state when to use it or name alternative tools. The context signals show sibling tools like 'consulta_ciudadana' and 'turnos_info', but no explicit comparison is made.
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 must disclose behavioral traits. It only mentions the function and implies URLs are returned, but omits any details about read-only status, output format, pagination, or limitations. This is a significant gap for a search tool with no annotation support.
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 efficiently conveys both purpose and usage. It is front-loaded and contains no redundant information, earning a perfect score.
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 covers the core purpose and a usage condition, but lacks details about the return format, result count, or any prerequisites. Given the absence of an output schema and annotations, more information is needed for full contextual completeness, though the tool's simplicity keeps it at a minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely repeats the parameter names ('consulta/categoría') without explaining their meanings, expected values, or how they interact. It does not help an agent construct correct inputs beyond the schema's basic type declarations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches official public sources by query/category, using a specific verb and resource. It also mentions the use case of citing exact URLs, which distinguishes it from sibling tools like 'buscar_noticias' or 'buscar_web_oficial'.
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 says 'Usar antes de contestar si necesitás citar URLs exactas', providing a clear condition for use. It does not name alternative tools, but the context is sufficient for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add 'Read-only' as a safety indication, which is useful, but it does not describe the return format, pagination, or any side effects. The behavioral disclosure is 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?
The description is a single sentence plus 'Read-only.' It is extremely concise, front-loaded with the main purpose, and contains no unnecessary 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 tool is simple (one parameter, no output schema), and the description covers the basic purpose and read-only nature. However, it lacks parameter semantics and any indication of output structure or examples. The condition about the municipality's public API adds some context, but overall it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'consulta' with no description, and schema description coverage is 0%. The description does not explain what this parameter means or how to use it, only that the tool searches for news. The parameter name offers some inference (query), but explicit semantics are missing.
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 'Buscar noticias oficiales' (search official news), which is a specific verb+resource combination. This distinguishes it from sibling tools like consulta_ciudadana or buscar_fuentes, which serve different purposes.
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 a clear usage condition: 'cuando el municipio expone API pública' (when the municipality exposes a public API). However, it does not explicitly mention alternatives or when not to use this tool, so it lacks some exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states a key non-behavior: 'No envía el reclamo' (does not send the complaint), which clarifies that the tool only provides guidance, not actual submission. This is valuable beyond what the name suggests, though it omits other potential details like rate limits or authentication.
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 short sentences, front-loaded with the core action and immediately followed by a critical caveat. Every word earns its place with no redundancy, 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?
For a simple one-parameter tool with no output schema, the description adequately conveys the main purpose and outcome (official channels and data suggestions). However, it lacks specifics on how results are presented (e.g., links, formatting) and does not elaborate on the parameter, making it minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The only parameter 'tema' is not explicitly explained beyond the tool's overall purpose. The phrase 'sugerir qué datos preparar' hints at the output but does not clarify what the 'tema' input should contain or its format, leaving the parameter semantically under-defined.
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: to redirect complaints/reports to official channels and suggest what data to prepare. The verb 'Derivar' is specific and distinguishes this tool from siblings like pagos_info or turnos_info, as it deals specifically with reclamos/denuncias.
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 user wants to file a complaint, this tool will help by providing official channels and data preparation tips. However, it does not explicitly state when to use this over alternatives (e.g., consulta_ciudadana) or mention any exclusions, leaving the usage context somewhat implicit.
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 provided, the description carries the full burden of behavioral disclosure. It does disclose a key limitation: the tool does not reserve or confirm appointments. However, it lacks details on what kind of information is returned, whether it uses live data, or any side effects. The single sentence adds some context beyond the name but is not rich.
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, concise sentence that front-loads the purpose and includes a limiting clause. Every word earns its place; there is no redundant or filler 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?
For a simple informational tool with one optional parameter and no output schema, the description provides a minimal viable explanation: it informs about appointments without booking. However, it omits guidance on the query parameter and what constitutes a successful response, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the 'consulta' parameter, and the description text does not mention it. The param name 'consulta' (query) hints at a free-text question, but the agent receives no guidance on how to format or use it. The description fails to compensate for the schema's lack of parameter 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 uses a specific verb ('orientar') and resource ('turnos/atención'), and clearly differentiates from siblings by stating it does not reserve or confirm appointments. This distinguishes it from other info tools like reclamos_info, pagos_info, and tramites_info by topic and scope.
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 clearly implies when to use this tool: for information about appointments (turnos), and explicitly excludes reservation/confirmation use cases. It does not name specific alternative tools, but the context of sibling info tools makes the usage context clear, and the 'no reserva ni confirma' phrase acts as a when-not guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 explicitly states the tool is read-only, lists actions it does not perform, and describes the output components (intention, sources, suggested actions, limits). This provides a comprehensive behavioral model beyond the schema, making it highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the primary purpose and immediately followed by read-only constraints and output content. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema/annotations, the description is fairly complete: it covers purpose, safety, exclusions, and output structure. However, it omits any guidance on parameter usage and does not explicitly mention when to prefer this over sibling tools, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate by explaining either parameter ('consulta' or 'tono'). There is no guidance on what should be in the query, how the tone affects the response, or any constraints. The description adds no semantic value beyond the parameter names themselves.
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 with a specific verb ('Responder') and resource ('consulta ciudadana'), and distinguishes it from siblings by explicitly listing what it does not do (no turnos, reclamos, pagos) and what it includes (intención, fuentes, acciones sugeridas, límites). This makes the tool's scope unambiguous.
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 gives clear context on when to use the tool: for general citizen queries using official public sources. It also provides explicit exclusions ('no reserva turnos, no envía reclamos/denuncias ni procesa pagos') indicating when not to use it. However, it does not name specific alternative tools, so it falls short of the full 5-point requirement for 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?
With no annotations provided, the description carries the full burden. It discloses return behavior ('Devuelve fragmentos y URLs oficiales') and includes a critical safety guardrail ('no inventar requisitos fuera de los fragmentos'). This adds meaningful behavioral context beyond a bare search operation, though it does not cover aspects like rate limits or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: what the tool searches, when to use it, and what it returns with a safety instruction. It is front-loaded with the main verb and resource, and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with no output schema or annotations, the description covers purpose, usage scenarios, output format, and a behavioral constraint. It does not mention result count or pagination, but these are minor for this context and the description is otherwise self-contained.
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 has one parameter, 'consulta', with no description and 0% schema coverage. The tool name and description make it reasonably clear that 'consulta' is the search query, but the description does not explicitly define expected input format or examples. It partially compensates through context but not fully.
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 opens with a specific verb and resource: 'Buscar en índice documental oficial generado desde páginas/PDFs públicos.' It clearly states the tool searches an official document index derived from public pages/PDFs, and the use cases (requisitos, documentación, obras, licencias, tasas, trámites) differentiate it from sibling tools like buscar_noticias or buscar_web_oficial.
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 lists when to use the tool ('Usar para requisitos, documentación, obras, licencias, tasas y trámites'), which is strong contextual guidance. However, it does not mention any exclusions or alternative tools, so it stops short of full decision support.
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 burden of disclosing behavior. It indicates a read-only operation ('ver'), but does not mention any potential side effects, error conditions, or additional behavioral nuances. For a simple detail lookup, this is 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?
The description is a single, clear sentence that conveys the purpose and source of the ID without extraneous words. It is perfectly concise and front-loaded.
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 tool with one parameter and no output schema, the description provides sufficient context: the tool is a detail-view operation for a source, and the ID comes from a specific sibling tool. It lacks information about return format, but the simplicity of the tool makes this 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?
The description adds semantic meaning to the 'id' parameter by specifying it is a public source ID returned by 'buscar_fuentes'. This is valuable context beyond the schema's bare 'string' type and minLength constraint, even though the described coverage is low.
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 function: view details of a public source by ID. The verb 'Ver' (view) is specific, and the resource 'fuente pública' (public source) is identified. It also distinguishes from sibling tool 'buscar_fuentes' by referencing an ID from that search tool.
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 ties usage to an ID returned by 'buscar_fuentes', providing clear context on when to use this tool (after searching). It implies this is not for searching but for retrieving details, though it does not explicitly exclude other scenarios or name alternatives beyond 'buscar_fuentes'.
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-rosario-municipal MCP server](https://glama.ai/mcp/servers/ruizechesortubenjamin/mcp-rosario-municipal/badges/card.svg)](https://glama.ai/mcp/servers/ruizechesortubenjamin/mcp-rosario-municipal)

Score Badge

Copy to your README.md:

[![mcp-rosario-municipal MCP server](https://glama.ai/mcp/servers/ruizechesortubenjamin/mcp-rosario-municipal/badges/score.svg)](https://glama.ai/mcp/servers/ruizechesortubenjamin/mcp-rosario-municipal)

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/ruizechesortubenjamin/mcp-rosario-municipal'

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