siu-guarani-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools target specific resources (actas, cursadas, mesas, inscriptos), but generic tools like detalle_url_docente and operacion_docente overlap with the more specific detail and list tools. There is also potential confusion between inscriptos_cursada_docente and alumnos_cursada_docente, which both return students from different entry points.
Naming Consistency2/5
Naming mixes verbs (buscar, resolver, exportar), nouns (cursadas_docente, mesas_examen_docente, agenda_examenes_docente), and even an English term (login_check). While the _docente suffix is consistent, the lack of a uniform verb_noun pattern makes the set feel inconsistent.
Tool Count3/5
With 18 tools, the set is slightly heavy for a typical server, but the domain of university academic management justifies many variations. It sits at the upper boundary of acceptable scope without feeling bloated.
Completeness4/5
The tools cover the core read-only workflows for a teacher portal: listing, searching, detailing, exporting, and resolving operational links. Minor gaps exist for evaluation management and direct grade entry, but those are outside the apparent read-only purpose.
Average 3.7/5 across 18 of 18 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that the tool 'trae y parsea' (fetches and parses), but does not mention any side effects, authentication requirements, rate limits, or return behavior. This is a gap for a tool that appears to be a generic dispatcher.
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 main action and examples. Each word earns its place; there is no fluff or redundancy.
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?
Although the tool has only one parameter and an output schema, the description is incomplete for a generic operation runner. It does not enumerate supported operation values, clarify its relationship with sibling tools, or explain what 'parsea' implies for the output. This leaves the agent unable to select robustly between this and the many specific sibling tools.
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?
With 0% schema description coverage, the description must compensate but only gives three examples of possible operation values. It does not explain the expected format, validity constraints, or how the operation string maps to actual backend operations, leaving significant ambiguity.
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 states that the tool 'trae y parsea una operación arbitraria del perfil Docente', giving a clear verb+resource and examples. However, 'operación arbitraria' is vague and the examples (e.g., 'inscriptos_cursadas') do not directly match the sibling tool names (e.g., 'inscriptos_cursada_docente'), which weakens the 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 explicit guidance on when to use this generic operation tool versus the specific sibling tools (e.g., 'inscriptos_cursada_docente'). The examples imply some operations, but there is no explanation of when the generic tool is preferred over the specialized ones.
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 carry the full burden. It only says 'Busca' (search), which implies a read-only operation, but it does not explicitly state side effects, return behavior, error handling, or authentication requirements. There is no mention of what happens when the acta is not found or how results are presented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is efficient and directly states the core functionality. Every word contributes to the meaning, with no unnecessary detail or fluff.
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?
Although the tool has only one parameter and an output schema, the description lacks workflow context and does not clarify its role among sibling tools. It mentions 'dentro de Reporte de Actas' but does not explain prerequisites, when to use it, or how it relates to 'detalle_acta_cursada_docente' and other related tools. This incompleteness could lead to incorrect tool selection.
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%, and the description adds only 'por número' (by number), which is redundant with the parameter name 'numero_acta.' It does not explain the expected format, constraints, or how the number should be provided (e.g., string length, leading zeros). The parameter type is already 'string' in the schema, but the description offers no additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for a course acta by number ('Busca un acta de cursada por número'), pinpointing the specific verb and resource. It also adds the context 'dentro de Reporte de Actas.' However, it doesn't explicitly differentiate this from sibling tools like 'detalle_acta_cursada_docente,' which may also involve searching by number.
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. The phrase 'dentro de Reporte de Actas' hints at a context but does not explain when to choose this tool over siblings like 'detalle_acta_cursada_docente' or 'resolver_cursada_docente'.
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 fully disclose behavioral traits. It mentions filtering options and the meaning of origen, but does not explicitly state that the operation is read-only, how it behaves without filters (e.g., returns all), pagination, or any side effects. The description lacks transparency about the tool's behavior beyond the basic list function.
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 very concise, with two sentences that front-load the purpose and then add filter details. No unnecessary words. It is well-structured and information-dense.
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?
The tool has 3 optional parameters, no annotations, and an output schema, but the description is minimal. It covers the basic purpose and filter names but lacks contextual guidance on when to use this tool vs siblings, behavioral details, and full parameter semantics. The presence of an output schema reduces the need to explain returns, but the description still feels incomplete for distinguishing itself in a crowded toolset.
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, so the description must compensate. It provides substantial meaning for 'origen' by explaining R, E, P values, and explicitly identifies 'periodo' and 'actividad' as filters. However, it does not clarify the format or expected values for 'periodo' and 'actividad', leaving partial gaps.
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 function with a specific verb + resource: 'Lista actas de Reporte de Actas con filtros opcionales' (Lists grade reports from Reporte de Actas with optional filters). It also provides the scope of the origen parameter with R/E/P values, distinguishing it from similar listing tools. However, it does not explicitly contrast with sibling tools like buscar_acta_cursada_docente, so it does not fully differentiate them.
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: to list actas with optional filters, and it explains the origen filter values. However, it does not state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The usage context is implied but not explicitly spelled out, fitting the 'implied usage' level.
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, the description must carry the full burden of behavioral disclosure. It states it lists data, implying a read operation, but it does not disclose authentication requirements, scope of the 'agenda', or any potential side effects. The mention of 'desde agenda_examenes' is cryptic and adds little 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, front-loaded sentence starting with the verb 'Lista'. It conveys the core action and resource without any wasted words, making it highly concise and easy to parse.
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, zero-parameter tool with an output schema, the description is minimally adequate. However, it lacks context about what 'agenda_examenes' refers to and whether any filters apply, making it less complete than similar high-scoring tools that clarify scope and alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is 4. The description adds meaningful context by indicating 'del docente', implying the tool uses the logged-in teacher implicitly. This goes beyond the empty schema and clarifies the intended scope.
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 'Lista agenda de exámenes del docente' clearly states a specific verb (Lista) and resource (exam agenda for the teacher). It distinguishes from siblings like 'detalle_mesa_docente' and 'inscriptos_examen_docente' by focusing on the agenda view, though it does not explicitly contrast with 'mesas_examen_docente'.
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 only gives the basic purpose without mentioning any prerequisites, context, or exclusions, leaving usage decisions entirely to the agent.
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 transparency. It indicates that the tool searches and returns detail rows, but it does not disclose whether authentication is required, whether it is a read-only operation, potential error conditions, or any side effects. This is a significant gap for a lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately conveys the tool's purpose and output. There is no redundant information or filler, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description does not need to detail return values. For a simple one-parameter lookup, the description adequately explains what the tool does and what input it requires. However, it lacks usage guidance and behavioral details (e.g., error handling, authentication), which prevents a higher score.
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 'numero_acta' with no description (0% coverage). The description adds some meaning by stating that the tool searches 'por número', aligning the parameter with the acta number. However, it does not clarify the exact format expected (e.g., leading zeros, length) or provide additional constraints beyond the schema's basic type and title.
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: 'Busca un acta de cursada por número y devuelve sus renglones de detalle.' It uses specific verbs ('busca', 'devuelve') and identifies the resource ('acta de cursada') and the specific output ('renglones de detalle'). This distinguishes it from sibling tools like 'buscar_acta_cursada_docente' which likely returns the acta itself, not the detail lines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description implies usage when you have an acta number and need detail lines, but it does not mention exclusions or compare with sibling tools such as 'detalle_cursada_docente' or 'buscar_acta_cursada_docente'. The usage context is only implied, not stated.
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 'metadatos de la mesa', which adds some content context, but it does not disclose whether the operation is read-only, whether authentication is required, or what side effects (if any) exist. For a detail endpoint, this is a notable 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, front-loaded sentence that conveys the essential purpose without filler. Every word contributes to understanding the tool's scope and source location.
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?
With a single parameter and an output schema available, the description is reasonably complete for a simple detail endpoint. However, given the lack of annotations and the existence of closely related sibling tools, it would benefit from explicitly stating the read-only nature and when to use this tool over 'detalle_url_docente'. It is minimally viable but not rich.
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 and only one parameter, 'url'. The description adds meaning by specifying that the URL should be from 'zona_examenes/home/<hash>', which explains the expected input format. However, it does not provide an example or clarify whether the hash is mandatory, so it only partially compensates for the schema's lack of detail.
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 retrieving details/metadata of an exam board ('mesa de examen') from a specific zone URL path. It distinguishes itself from sibling list tools like 'mesas_examen_docente' by focusing on a single item's detail, and from other detail tools by specifying the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you have a URL from 'zona_examenes/home/<hash>'. However, it does not explicitly state when to prefer this over alternatives like 'detalle_url_docente' or provide exclusion criteria. Usage context is implied but not fully articulated.
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 for behavioral disclosure. It mentions the need for specific URLs but does not state that the tool writes files to the output directory, whether it overwrites existing files, or any side effects. The output behavior is only vaguely implied by the output_dir parameter, leaving significant 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 two sentences long with no filler. The first sentence front-loads the core purpose, and the second adds a critical prerequisite. Both sentences provide essential information without redundancy.
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?
Although the output schema exists, the description lacks context on the file-writing side effects and full parameter semantics. For a tool that exports and likely creates files, the absence of any mention of where files are written or what happens to them makes the description incomplete. It would benefit from clarifying that files are generated in output_dir with a given basename.
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 0% description coverage, so the description must compensate. It explains the format for the two required URL parameters but does not clarify the meaning of 'basename' or 'output_dir', which have defaults but still need context. Half of the parameters remain effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Exporta' (exports), the resource 'alumnos + notas de una cursada' (students + grades of a course), and the output formats 'CSV, XLSX y JSON'. This distinguishes it from sibling tools like 'alumnos_cursada_docente' and 'notas_cursada_docente' which likely retrieve data without exporting to multiple file formats.
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: use this tool when you need to export student and grade data to CSV, XLSX, or JSON. It also specifies required input URLs with a format hint ('zona_clases/home/<hash> y zona_comisiones/home/<hash>'), though it does not explicitly mention alternatives or situations to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the accepted URL patterns and portal restriction, which is useful. But it does not describe potential side effects, authentication requirements, or behavior for invalid/malformed URLs, leaving some transparency 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?
Two sentences: the first states purpose with examples, the second adds a constraint. No unnecessary words, clearly 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 one-parameter tool with an output schema, the description covers what the tool does, what input it expects, and an important constraint. Minor gaps remain around the exact meaning of 'resume' and error handling, but overall it's sufficiently contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a 'url' string with no description. The description enriches this by specifying the required URL format with examples and the portal restriction, giving essential context for calling the tool correctly.
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 summarizes detailed URLs from the Guaraní Docente portal and provides concrete URL pattern examples, distinguishing it from sibling tools that target specific detail types (cursada, mesa, etc.). The verb 'resume' is slightly ambiguous but contextually means 'summarize/resolve'.
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 the agent has a detail URL and needs summary data, and explicitly limits input to URLs from the configured portal. However, it does not explicitly contrast with sibling detail tools (e.g., detalle_cursada_docente) or state when to prefer this over them.
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 only states the source 'desde zona_clases' and the listing action, which implies read-only behavior but does not disclose things like authentication requirements, whether only active courses are returned, pagination, or response characteristics. This is a minimal behavioral disclosure.
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 one concise, front-loaded sentence. It includes the action, object, and source without any fluff or repetition. Every word adds value, making it an efficient and well-structured description.
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 zero-parameter listing tool with an output schema available, the description is mostly complete. It tells the agent what is listed and from where. It doesn't specify whether the list includes all courses or only current/active ones, but that is a minor gap given the tool's simplicity and the existence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is nothing for the description to explain about parameters. The schema has 100% coverage trivially. The baseline of 4 for zero-parameter tools is appropriate because no additional parameter meaning is needed.
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 'Lista' (lists) and explicitly names the resource (cursadas/comisiones del docente desde zona_clases). It clearly distinguishes this listing tool from sibling tools like detalle_cursada_docente, exportar_cursada_docente, or inscriptos_cursada_docente, which have different actions.
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 when to use the tool—when you need to list a teacher's courses/commissions—but it does not explicitly state alternatives, when-not-to-use, or conditions like 'use detalle_cursada_docente for a single course'. Usage context is only implicit from the listing verb.
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 behavioral disclosure. It communicates a read-only list operation, a visibility filter ('visibles'), and an authentication requirement. However, it does not elaborate on potential side effects, pagination, or return format, leaving some transparency gaps for a no-parameter read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('Lista') and the resource. It contains no redundant or filler words, earning a perfect score for conciseness.
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, parameterless tool with an output schema, the description adequately covers the essential context: what is listed, for whom, and under what visibility constraints. It could optionally explain 'zona_clases' or the return format, but these are secondary given the output schema.
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 zero parameters, and schema coverage is trivially 100%. Per the rubric baseline, a 4 is appropriate; the description adds no parameter details, but none are needed.
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 the specific verb 'Lista' (lists) with the resource 'períodos lectivos' and adds scope ('visibles en zona_clases para el docente autenticado'), making its purpose clear and distinguishable from sibling tools that focus on cursadas, mesas, actas, etc.
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 implies usage context (for the authenticated teacher, in zona_clases) but provides no explicit guidance on when to choose this tool over alternatives, nor does it mention any exclusions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the output structure (metadata + categorized classes) but does not disclose side effects, authentication needs, or other behavioral traits. Since it's a detail tool, it's implied read-only, but that is not explicitly stated.
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, focused sentence that states the resource, source, and output structure without unnecessary words.
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 parameter) and the presence of an output schema, the description provides sufficient information about the purpose and output structure. It doesn't cover edge cases or prerequisites, but for this level of complexity it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single `url` parameter with no description. The tool description compensates by indicating the URL should be from `zona_clases/home/<hash>`, providing semantic context for the parameter.
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 identifies the tool as providing details of a cursada from a specific URL path, including metadata and classes grouped by category. It distinguishes from sibling tools like detalle_mesa_docente by specifying the course context and URL source, though the verb is implied rather than explicit.
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 a clear context: it is for retrieving details of a course from the zona_clases/home/<hash> URL. It does not explicitly mention alternatives or when-not-to-use, but the context is specific enough to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly discloses the default PII exclusion and the include_pii option, as well as the accepted URL formats. This provides meaningful behavioral insight beyond the schema, though it does not mention pagination or output 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 two sentences, front-loaded with the core purpose and immediately followed by the key PII behavior. 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?
The description is complete for a list-retrieval tool with two parameters and an existing output schema. It covers purpose, source paths, and PII behavior. Minor omissions like auth requirements or exact response format are mitigated by the output schema and sibling context.
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 compensates by giving URL patterns for the 'url' parameter and explicitly explaining include_pii's default false value and effect. Both parameters are effectively described, though the url parameter is conveyed indirectly through 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 lists enrolled students for an exam mesa, with specific URL patterns. It distinguishes from siblings like inscriptos_cursada_docente through the explicit 'mesa de examen' context, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining what the tool does and how to include PII, but it does not explicitly state when to use this tool over siblings nor provide exclusions. The URL patterns give some context, but no direct comparison with alternatives.
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 bears the full burden of disclosing behavioral traits. It mentions the input URL formats but does not state whether the operation is read-only, requires authentication, or how it handles invalid URLs. For a listing tool, this is a notable 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, focused sentence that immediately states the action and the key input constraint. Every word earns its place, and it is front-loaded with the verb 'Lista'.
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?
With only one parameter, no annotations, and an output schema present, the description covers the essential contextual needs: purpose, input format, and scope. It could mention error behavior or prerequisites, but for a simple listing tool with an output schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'url' as a generic string with 0% description coverage. The description compensates by specifying exactly which URL patterns are accepted (zona_comisiones/home/<hash> or inscriptos_cursadas/info_comision/<hash>), adding significant meaning beyond the schema. It does not explain the hash parameter, but the format guidance is valuable.
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: listing enrollees (inscriptos) of a commission (comisión). It specifies the exact URL formats accepted, which distinguishes it from sibling tools like inscriptos_examen_docente (exam enrollees) and alumnos_cursada_docente (course students).
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 on when to use the tool: when you have a single URL matching the specified patterns. It emphasizes 'SOLA URL' (single URL), giving a concrete constraint. However, it does not explicitly mention when not to use it or name alternatives, 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?
The description discloses the main behaviors: validating login and switching to the Docente profile. However, with no annotations, it fails to mention potential side effects, prerequisites (e.g., existing session), or failure modes, leaving the agent with an incomplete behavioral picture.
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 efficiently conveys the tool's purpose without filler. It is front-loaded and easy to parse, earning full marks for conciseness.
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 no parameters and a simple purpose, the description is almost complete. It covers the core action and target profile, though it could benefit from noting whether any session or context is required. The presence of an output schema (not shown) may further supplement return info, raising the completeness score.
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 zero parameters, so the schema fully covers parameter semantics (vacuously). The description adds no parameter details, but there is nothing to add, making the baseline 4 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Valida login') and a specific resource ('perfil Docente de SIU Guaraní UNR'), distinguishing it from sibling tools which all perform post-login operations like 'buscar_acta' or 'detalle_mesa'.
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?
Usage context is implied: the tool likely serves as a prerequisite for the other docente-related tools. However, it does not explicitly state when to use it or mention alternatives, relying on the agent to infer its role from the description.
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 must disclose behavioral traits. It only mentions input and output (resolves URLs), but does not state whether authentication is required, whether it makes network calls, what happens on invalid URLs, or any side effects. This is a significant gap for a tool that operates on external URLs.
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, well-structured sentence that leads with the main verb, includes input format examples, and lists outputs. It contains no fluff and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (one parameter) and an output schema exists, so the description does not need to explain return structures. It covers the essential input constraints and output categories. Minor omission: no mention of error handling or prerequisites, but given the output schema and simplicity, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 0%, the description explicitly explains the expected format of the 'url' parameter with concrete examples (zona_clases/home/<hash> etc.). This adds crucial semantic meaning beyond the bare schema definition, effectively compensating for the 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 clearly states the tool's function with a specific verb ('Resuelve') and resource ('cursada'), and enumerates the output link types (Cargar Notas, Alumnos, Evaluaciones, Actas, Asistencia). It distinguishes itself from sibling tools that focus on single actions or details, making its 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?
Provides clear context for when to use the tool: when given a single URL following specific patterns (zona_clases/home/<hash> or zona_comisiones/home/<hash>). It implies this tool is the entry point to obtain operational links. However, it does not explicitly state when not to use it or mention alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds useful behavioral details: the default date range, the optional override, and the date format. However, it does not disclose potential side effects, authentication needs, pagination, or result limits—important context for a listing tool even if not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by concise parameter/default behavior. No redundant or extraneous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, list operation) and the presence of an output schema, the description covers the essential behavioral info. It could mention whether an empty result is possible or if any auth is implied, but for the scope it is largely complete.
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 provides no descriptions (0% coverage), but the description compensates by explaining that 'desde/hasta' are optional, accept dates in dd/mm/aaaa format, and are used to override the default range. This adds meaningful semantics 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 clearly states the tool lists 'mesas de examen operables del docente' from 'zona_examenes', using a specific verb and resource. It uniquely identifies this as a listing operation for the teacher's operable exam boards, distinguishing it from sibling detail/action tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by specifying the default wide date range (-90/+180 days) and the optional use of 'desde/hasta' parameters. However, it does not explicitly mention when to use this tool versus alternatives like 'agenda_examenes_docente' or 'detalle_mesa_docente', so it stops short of full exclusion 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 the transparency burden. The verb 'Lista' implies a read-only operation, and the URL patterns are disclosed, but it does not explicitly state whether the operation is side-effect-free or if authentication is required. This adds useful but limited behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no filler. Every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with an output schema, the description adequately covers purpose and URL constraint. It does not mention pagination or that only grades available at those specific pages are returned, but the output schema likely covers return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'url' parameter with no description (0% coverage). The description compensates by specifying that the URL must match one of the two allowed path formats, giving the parameter concrete meaning 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 states a specific verb ('Lista') and resource ('notas cargadas de una cursada'), clearly distinguishing it from sibling tools like detalle_cursada_docente (course details) or inscriptos_cursada_docente (enrolled students). It also pinpoints the exact URL contexts.
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 provides clear contextual guidance by restricting use to URLs from zona_comisiones/home/<hash> or cursada/edicion/<hash>. However, it does not explicitly describe when to use this tool over alternatives like buscar_acta_cursada_docente, so it stops short of full when/when-not 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 provided, the description carries the full burden. It describes what the tool does (reads a URL and returns a list) and what fields are returned, giving transparency into the output. It does not mention authentication, rate limits, or error behavior, but for a simple read/list operation the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly-worded sentence that fronts the primary action and resource, then provides the input format and output fields. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, list output) and the presence of an output schema, the description is complete. It covers the input source format and the meaningful return fields, which is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a 'url' parameter with no description. The tool description compensates fully by specifying the exact URL patterns accepted (zona_clases/home/<hash> or asistencias/<hash>) and what data is extracted from them. This adds significant meaning 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 clearly states the tool lists students from a course using a specific URL from zona_clases/home/<hash> or asistencias/<hash>, and enumerates the returned fields (nombre, legajo, hash interno, presente). This specific verb and resource scope distinguish it from sibling tools like inscriptos_cursada_docente or detalle_cursada_docente.
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 provides a clear trigger: use when you have a URL from zona_clases/home/<hash> or asistencias/<hash>. The mention of 'presente para la clase mostrada' implies this is for a specific class session, differentiating it from enrollment lists. However, it does not explicitly name alternatives or say when not to use 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:

[![siu-guarani-mcp MCP server](https://glama.ai/mcp/servers/jpmanson/siu-guarani-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jpmanson/siu-guarani-mcp)

Score Badge

Copy to your README.md:

[![siu-guarani-mcp MCP server](https://glama.ai/mcp/servers/jpmanson/siu-guarani-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jpmanson/siu-guarani-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jpmanson/siu-guarani-mcp'

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