mcp-roldan-municipal

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Each tool has a clear target: general queries, search by type (sources, news, documents, live web), source details, and domain-specific guides. The four buscar_* tools overlap somewhat but descriptions specify the content scope, making them distinguishable.
Naming Consistency3/5
There is a mix of patterns: buscar_* for search, *_info for guidance, consulta_ciudadana as a noun phrase, and detalle_fuente as a noun-noun. This is not chaotic but lacks a single consistent verb_noun convention across all tools.
Tool Count5/5
With 10 tools, the server is well-scoped for a municipal information assistant. Each tool covers a distinct aspect without redundancy or bloat.
Completeness4/5
The set covers general queries, multiple search types, and guidance for complaints, payments, appointments, and procedures. It intentionally avoids write actions, which is clearly stated, so no major gaps exist, though a tool for location-based services could be a minor addition.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 2.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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it does not mention whether the tool is read-only, performs external searches, or returns specific types of information. This lack of detail leaves significant ambiguity about the tool's behavior.
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, concise sentence with no filler. It is front-loaded with the action and subject, earning its place, though it could be expanded with useful details without becoming verbose.
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 simplest tool with one optional parameter and no output schema or annotations, the description only provides a high-level purpose. It lacks info on input format, expected outputs, or how it differs from siblings, making it incomplete for an agent to use correctly.
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 description coverage is 0%, so the description must explain the 'consulta' parameter, but it only mentions the general topic. It does not specify what the parameter should contain (e.g., a question, a keyword, or a procedure name), leaving the user to infer it from the tool name.
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 with a verb ('Orientar' - to guide) and a resource ('trámites municipales generales y buscadores oficiales'). This distinguishes it from specific sibling tools like buscar_fuentes or detalle_fuente, but the verb 'orientar' is somewhat vague about the concrete action performed.
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 name any siblings, mention exclusions, or provide context for selecting it over more specialized tools like buscar_web_oficial or reclamos_info.
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 explicitly states 'Read-only' and 'con URLs oficiales', which are meaningful behavioral guarantees, and notes the live-search nature. It doesn't cover rate limits, authentication, or failure modes, but for a simple search tool it adds sufficient context beyond a bare description.
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 short sentences, front-loaded with the primary action, and contains no unnecessary filler. Every sentence earns its place by adding either the core purpose, a specific usage detail, or a safety/source guarantee.
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 explain what the search results look like, but it doesn't. It also doesn't address what happens when an adapter is missing or how to handle failures. However, it does cover purpose, usage context, and read-only nature, making it minimally viable but not 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 schema has one parameter 'consulta' with 0% description coverage, and the description never explicitly explains that 'consulta' is the search query or provides any format/constraint details. The meaning is inferable from the tool name, but the description adds no parameter-level 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 action: 'Buscar en vivo en el sitio oficial cuando existe adaptador' (search live on the official site when an adapter exists). It also adds a specific variant for Rosario's official HTML search, which helps distinguish it from sibling search tools like buscar_fuentes and buscar_noticias, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives conditional usage context ('cuando existe adaptador') and a location-specific behavior ('En Rosario usa el buscador HTML oficial'), indicating when this tool is appropriate. However, it does not explicitly reference sibling tools or provide when-not-to-use guidance, so it falls short of a 5.
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 that the tool is 'Read-only' and notes a dependency on the municipality's public API. This is useful behavioral context, though it does not describe error handling or return format.
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, consisting of two short sentences that front-load the core action and include the key behavioral trait. Every word earns its place with no redundancy.
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 search tool with one parameter and no output schema, the description covers the essential context: purpose, usage condition, and read-only nature. However, the lack of parameter explanation leaves a small gap, but overall it is sufficiently 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 the schema description coverage is 0%. The tool description does not explain what 'consulta' means or how it should be formatted, so it fails to compensate for the lack of parameter documentation.
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: 'Buscar noticias oficiales' (search official news), with a specific verb and resource. It also adds a scope condition ('cuando el municipio expone API pública'), but it does not explicitly distinguish from sibling tools, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'cuando el municipio expone API pública' (when the municipality exposes a public API). This tells the agent when to use the tool, but it does not mention when not to use it or name alternative tools, so it falls short of a 5.
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 burden of disclosing behavior. It does state that the tool does not process payments or consult personal debt, implying a safe, non-transactional nature. Yet it doesn't explicitly confirm it is read-only, nor does it describe return responses or side effects beyond these exclusions.
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, compact sentence that front-loads the main purpose and includes important limitations. Every word earns its place, with no redundancy or unnecessary detail.
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 simple structure (one param, no output schema), the description covers the tool's scope and exclusions well. However, it lacks explicit instructions on how to use the 'consulta' parameter and what the response looks like, making it incomplete for an agent that needs fully actionable guidance.
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 one parameter 'consulta' with 0% description coverage, and the tool description provides no explanation of what this parameter should contain. The name 'consulta' (query) hints at a free-text question about payments, but this is inferred rather than stated, leaving the agent without adequate guidance for filling the only parameter.
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 explicitly states a specific action ('Orientar' = guide) and a clear resource ('pagos/tasas/tributos'), and differentiates itself from sibling tools like 'reclamos_info' and 'turnos_info'. It also clarifies boundaries (no personal debt, no payment processing), making the tool's purpose 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 for when to use the tool (guidance on payments/fees/taxes) and explicitly states exclusions (not for personal debt, not for payment processing). However, it does not name alternative sibling tools, so it stops short of explicit 'use X instead' guidance.
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 full responsibility. It discloses the non-transactional nature of the tool, but gives no further detail on response format, data sources, or any other behavioral traits. This is minimal but not misleading.
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 immediately states the purpose and a key exclusion. Every word earns its place, with no unnecessary detail.
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 tool with low complexity (one parameter, no output schema), the description provides essential purpose and a key limitation. However, without an output schema, the lack of detail about what 'orientar' actually returns leaves ambiguity about the tool's response.
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 one parameter 'consulta' with 0% description coverage. The tool description does not explain what the parameter should contain, its format, or provide examples, leaving the agent to infer from the parameter name alone.
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: 'Orientar sobre turnos/atención' (guide about appointments/attention). It explicitly excludes actions ('no reserva ni confirma turnos'), distinguishing it from potential booking tools and clarifying its informational 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 implies use when a user needs orientation about appointments and attention, and explicitly states what the tool does not do (reserve or confirm). However, it does not name alternative tools or provide explicit when-not-to-use scenarios beyond the reservation/confirmation exclusion.
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 behavioral disclosure burden. It clearly states 'Read-only' and lists excluded actions, providing a strong safety signal. It also mentions that the response includes intention, sources, suggested actions, and limits, which gives a preview of the tool's output. It could add rate limits or specific output structure, but the core read-only 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 concise: three sentences cover purpose, exclusions, and output composition. Every sentence contributes necessary context without redundancy. It is well-structured and front-loaded with the primary action.
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 purpose, read-only behavior, exclusions, and output highlights, which is good for a simple informational tool. However, it omits critical detail about the 'tono' parameter, and the absence of an output schema makes this omission more impactful. The tool is not fully self-contained for an agent to use correctly without additional inference.
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. While 'consulta' is self-evident from the tool's purpose, the 'tono' parameter (with enum breve/normal/llamada) is entirely unexplained. The description does not clarify what tone/format options mean or how they affect the response, leaving a significant gap.
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 states a specific action: 'Responder una consulta ciudadana usando fuentes oficiales públicas' (respond to a citizen query using official public sources). It clearly distinguishes from sibling tools that focus on searching or retrieving specific types of information, and it outlines the output components (intention, sources, suggested actions, limits).
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 when not to use the tool: 'no reserva turnos, no envía reclamos/denuncias ni procesa pagos' (does not reserve appointments, send complaints, or process payments). This effectively excludes common alternative uses, though it does not explicitly name sibling tools like turnos_info or pagos_info.
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 of behavioral disclosure. It explicitly states a key limitation ('No envía el reclamo') which is a behavioral trait not evident from the tool name. It also reveals a likely behavioral pattern: the tool will direct users to channels and suggest data preparation. However, it does not explain what the tool returns (e.g., links, instructions) or how it processes the 'tema' parameter, leaving some behavioral aspects undisclosed.
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, each serving a distinct purpose: the first defines the main action and secondary benefit, the second clarifies a critical limitation. It is front-loaded with the primary verb and resource, and there is no redundant or filler content. Perfectly sized for the tool's simplicity.
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 (one optional parameter, no output schema, no annotations), the description covers the essential context: what it does, what it does not do, and what it suggests. It tells the user the tool is a referral/guidance tool, not a submission tool. However, it omits any detail about the output format or examples, which could be useful but is not strictly necessary for a simple text-based tool. Overall, sufficiently complete for its complexity.
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 a single optional parameter 'tema' with no description (0% schema description coverage). The tool's description does not explicitly explain what 'tema' should contain (e.g., the complaint topic, keywords). The phrase 'sugerir qué datos preparar' hints at the general function but does not map to the parameter. Since the schema leaves the parameter undefined and the description fails to compensate, parameter semantics are weak.
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 states a specific verb+resource: 'Derivar reclamos/denuncias a canales oficiales' (refer complaints/reports to official channels) and adds a clear secondary function ('sugerir qué datos preparar'). It also clarifies a critical exclusion with 'No envía el reclamo,' distinguishing it from any tool that might submit complaints. The name and description clearly separate it from sibling tools focused on payments, appointments, procedures, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when dealing with complaints/reports that need to be directed to official channels and when suggesting data to prepare. It also implicitly warns the user not to expect actual submission via 'No envía el reclamo.' However, it does not explicitly name alternative tools or mention 'when not to use' beyond the limitation, so it lacks explicit alternative guidance.
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 hay anotaciones, así que la descripción es la única fuente. Menciona que busca fuentes oficiales públicas y que se usa para obtener URLs exactas, lo que sugiere un comportamiento de solo lectura y retorno de URLs. Sin embargo, no especifica el formato de salida ni otros detalles de comportamiento.
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?
La descripción consta de dos oraciones que van al grano. La primera dice qué hace; la segunda, cuándo usarla. No hay palabras de relleno.
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?
Para una herramienta simple de búsqueda, la descripción cubre el propósito, el contexto de uso y los parámetros. La falta de un esquema de salida se mitiga porque se infiere que devuelve URLs exactas. Aun así, una mención explícita del tipo de retorno la haría más completa.
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?
El esquema no incluye descripciones, pero la descripción menciona 'por consulta/categoría', lo que explica que 'consulta' es la consulta y 'categoria' es la categoría. Cubre los dos parámetros aunque no detalla valores permitidos.
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?
El verbo 'buscar' y el recurso 'fuentes oficiales públicas' definen claramente la acción. La frase 'por consulta/categoría' delimita el alcance y lo distingue de otros buscadores como 'buscar_noticias' o '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?
La segunda oración indica cuándo usar la herramienta: antes de contestar si se necesitan URLs exactas. Da una condición clara pero no menciona alternativas ni cuándo no usarla.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns fragments and official URLs ("Devuelve fragmentos y URLs oficiales") and warns against inventing requirements outside those fragments ("no inventar requisitos fuera de los fragmentos"). This provides useful behavioral context, though it lacks details on authentication, rate limits, or error 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 three concise sentences, front-loaded with the main action, then usage, then output and caution. Every sentence adds value with no redundancy.
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?
Despite having no output schema or annotations, the description provides the essential context: what it searches, when to use it, what it returns, and a safety warning. For a simple one-parameter search tool, this is nearly complete, but it could mention pagination or result limits.
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 0% description coverage for the single parameter 'consulta'. The description implies the parameter is the search query by mentioning topics to search for, but it never explicitly defines 'consulta' or gives format examples. This is adequate compensation but not outstanding.
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 identifies the tool as searching an official documentary index sourced from public pages/PDFs ("Buscar en índice documental oficial"). The verb 'buscar' plus specific resource distinguishes it from sibling tools like buscar_noticias or buscar_web_oficial, which target different content types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: "Usar para requisitos, documentación, obras, licencias, tasas y trámites." This gives clear context for when to use the tool, though it does not mention alternative tools or exclusion scenarios, so it falls short of a 5.
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. 'Ver detalle' implies a read-only operation, but it does not disclose what the detail contains, error behavior, or whether any authorization is needed. For a simple retrieval tool, this is adequate but 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, short, front-loaded sentence with no filler or redundancy. Every word contributes to explaining the tool's purpose and usage.
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 one-parameter tool with no output schema and no annotations, the description covers the essential aspects: what it does and where the input comes from. It does not describe the return format, but 'detalle' reasonably implies a detailed object, making it sufficient for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by stating that the ID is the one returned by 'buscar_fuentes', which clarifies the provenance and expected value of the 'id' parameter beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Ver') and resource ('detalle de una fuente pública') and explicitly ties the ID to the sibling tool 'buscar_fuentes', making the purpose clear and distinguishing it from the 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?
It clearly implies the tool should be used after obtaining an ID from 'buscar_fuentes', providing useful context. It does not explicitly state when not to use it, but the reference to the sibling tool gives sufficient guidance for a simple detail lookup.
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-roldan-municipal MCP server](https://glama.ai/mcp/servers/ruizechesortubenjamin/mcp-roldan-municipal/badges/card.svg)](https://glama.ai/mcp/servers/ruizechesortubenjamin/mcp-roldan-municipal)

Score Badge

Copy to your README.md:

[![mcp-roldan-municipal MCP server](https://glama.ai/mcp/servers/ruizechesortubenjamin/mcp-roldan-municipal/badges/score.svg)](https://glama.ai/mcp/servers/ruizechesortubenjamin/mcp-roldan-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-roldan-municipal'

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