Skip to main content
Glama
Sign In
utn-mcp

utn-mcp

by nialvape
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

aula_open

Read-only

Open a virtual classroom address to retrieve its contents: course sections and modules, files and due dates, forum discussion indexes or full messages, with activity details and navigation links.

Instructions

Entra a una dirección del aula virtual y devuelve lo que hay ahí: un curso con sus secciones y módulos, un módulo con sus archivos y fechas, un foro con el índice de sus discusiones, o una discusión con sus mensajes completos.

Según el tipo de módulo trae además: en una tarea (assign), entrega con el estado, el vencimiento, lo que se subió y la devolución con la nota; en un cuestionario (quiz), cuestionario con la calificacionFinal ("0,00 / 10,00") y cada intento con su estado, comienzo, fin y nota; en una elección (choice) o selección de grupos (choicegroup), eleccion con las opciones y sus ids; en un foro, puedeAbrirHilo; en una discusión, el id, el autorId y las acciones permitidas de cada publicación. Es lo que piden las tools que escriben en el aula.

No hace falta armar la dirección: cada respuesta trae las direcciones de lo que hay adentro (direccion) y la de un nivel más arriba (padre), así que se navega pasando de vuelta una de esas. Para empezar, usar aula_list_courses o la dirección "/".

Buscar algo que puede estar en cualquier parte (una fecha de parcial, un aviso) se hace entrando al curso y abriendo lo que corresponda: el índice de un foro muestra los asuntos sin volcar los mensajes enteros, y archivos como un cronograma se leen con aula_read_file.

Los archivos vienen con una url, que sirve para leerlos con aula_read_file y también para dársela al usuario si quiere bajarlo: se abre con su sesión del aula.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "direccion": "<direccion>"
    },
    "name": "aula_open"
  }
}

Input Schema

NameRequiredDescriptionDefault
paginaNoSolo para foros: página del índice de discusiones, de 50 en 50. La respuesta avisa con `hayMasDiscusiones` cuando hay otra.
direccionYesDirección a abrir, sacada de una respuesta anterior. Ej: "/", "/curso/691", "/curso/691/mod/34806", "/curso/691/mod/34806/disc/421348".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.3

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), yet the description adds real behavior beyond them: the response carries `direccion`/`padre` links so traversal is self-describing, and file `url`s only open with the user's own classroom session. It does not cover failure modes (what happens with a stale or foreign `direccion`), which keeps it off a 5.

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?

Front-loaded with the core behavior, then layered detail in decreasing importance. The middle paragraph is a dense dump of returned JSON keys, which is long but earns its place given there is no output schema; a few clauses (e.g. repeating how files are read) could be trimmed.

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?

With no output schema and a return shape that varies by node type, the description carries the full burden of explaining return values and does so per module type (assign/quiz/choice/choicegroup/forum/discussion). The self-navigation model and the session-bound `url` caveat close the remaining gaps an agent would hit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds semantics the schema can't: `direccion` must be taken from a prior response rather than constructed, and `pagina`'s effect is tied to the `hayMasDiscusiones` signal in the response. Only the forum pagination detail is largely a restatement of the schema field.

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?

Opens with a concrete verb and resource ("Entra a una dirección del aula virtual y devuelve lo que hay ahí") and immediately enumerates the four polymorphic outcomes: curso, módulo, foro, discusión. This lets an agent identify the tool's role without inspecting the schema, and it names siblings (aula_list_courses, aula_read_file) that handle adjacent jobs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit entry point ("Para empezar, usar aula_list_courses o la dirección '/'"), explicit navigation rule (pass back `direccion` or `padre` from a response), and an explicit search strategy (enter the course, read the forum index rather than full threads, use aula_read_file for cronogramas). When-to-use and which-alternative are both stated rather than inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools