This server provides MCP tools to interact with a Moodle-based virtual campus (TUPAD UTN), allowing AI assistants to retrieve course materials, deadlines, grades, forum posts, direct messages, notifications, and more.
List enrolled courses (listar_materias): Get all your subjects with IDs and progress percentages.
Browse course content (ver_contenido_materia): View materials, PDFs, videos, and assignments by unit; get an index first, then detailed content with file URLs.
Check upcoming deadlines (proximos_vencimientos): See all assignment and quiz closing dates across courses, sorted by date.
View practical assignments (ver_trabajos_practicos): Access TP instructions, due dates, and submission status; optionally filter to pending only.
Check grades (ver_notas): View item‑by‑item grades and instructor feedback for a course; optionally show only graded items.
Read forum announcements (leer_avisos_foro): Fetch recent posts from course forums; defaults to announcements, can include all discussion forums.
Download files (descargar_archivo): Save course files (notes, PDFs, presentations) locally using URLs from content browsing.
Read private messages: Access direct messages and conversation history.
View notifications: See system alerts about new content, corrections, etc.
See calendar events: Display Moodle calendar entries.
Get grade summaries: Calculate average grades across courses.
Track unit progress: View completed vs. pending activities per unit.
Review quiz corrections: Examine submitted quizzes question by question.
Provides tools to interact with a Moodle campus virtual, enabling AI agents to list courses, view content, check upcoming deadlines, manage assignments, read forum announcements, download files, and retrieve grades.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP-TUPAD ¿Qué se me vence esta semana?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP para consultar el campus virtual Moodle de la Tecnicatura Universitaria en Programación a Distancia (UTN) desde cualquier asistente de IA.
Conecta tu cuenta del campus con Claude Code, Claude Desktop, Cursor, VS Code o cualquier otro cliente compatible con MCP, para que puedas preguntar cosas como:
¿Qué se me vence esta semana? Explicame el apunte de la unidad 3 de Programación I. ¿Cómo vengo de notas en Matemática? ¿Hay avisos nuevos de los profesores, o alguien me escribió por privado? ¿Qué preguntas erré en el segundo parcial de Metodología? ¿Qué me quedó sin completar en la unidad 4?
Moodle expone una API REST oficial (la misma que usa su app móvil). Este servidor la traduce a herramientas MCP. Cada persona usa su propio token, y solo accede a lo que ya ve en el campus con su usuario.
No requiere permisos de administrador ni instalar nada en el servidor de la UTN.
Related MCP server: Moodle MCP Server
Node.js 20.12 o superior (node --version para verificar)
Una cuenta del campus con usuario y contraseña propios de Moodle
git clone https://github.com/brujoh88/MCP-TUPAD.git
cd MCP-TUPAD
npm installEjecutá esto reemplazando tus credenciales:
curl -s "https://tup.sied.utn.edu.ar/login/token.php" \
-d "username=TU_USUARIO" \
-d "password=TU_CONTRASENA" \
-d "service=moodle_mobile_app"Devuelve algo así:
{ "token": "a1b2c3d4e5f6..." }⚠️ Ese token equivale a tu contraseña. Quien lo tenga puede entregar trabajos prácticos y publicar en foros en tu nombre. Nunca lo compartas ni lo subas a un repositorio — cada compañero saca el suyo con sus credenciales.
cp .env.example .envAbrí .env y pegá tu token:
MOODLE_URL=https://tup.sied.utn.edu.ar
MOODLE_TOKEN=a1b2c3d4e5f6...El archivo .env está en .gitignore, así que nunca se sube al repo.
npm run probar-tokenDeberías ver tu nombre y el listado de tus materias con sus IDs. Si esto falla, el problema está en el token o la URL — no en el MCP.
El servidor es el mismo para todos los clientes; solo cambia dónde va la configuración.
Si abrís este proyecto, ya está: el archivo .mcp.json del repo se detecta
solo y Claude Code te pide aprobarlo al iniciar.
Para usarlo desde cualquier proyecto, registralo a nivel usuario:
claude mcp add --scope user --transport stdio moodle-tupad \
-- node /ruta/absoluta/a/MCP-TUPAD/src/index.jsCreá ~/.cursor/mcp.json (global) o .cursor/mcp.json (solo este proyecto):
{
"mcpServers": {
"moodle-tupad": {
"command": "node",
"args": ["/ruta/absoluta/a/MCP-TUPAD/src/index.js"]
}
}
}Editá claude_desktop_config.json (Configuración → Desarrollador → Editar
configuración):
{
"mcpServers": {
"moodle-tupad": {
"command": "node",
"args": ["/ruta/absoluta/a/MCP-TUPAD/src/index.js"]
}
}
}Creá .vscode/mcp.json con el mismo bloque mcpServers de arriba.
El servidor lee las credenciales del archivo
.envdel proyecto, así que no hace falta declarar variables de entorno en la configuración de ningún cliente. Si preferís pasarlas por entorno igual, tienen prioridad las que ya estén definidas en el sistema.
Herramienta | Qué hace | Parámetros |
| Tus materias con ID y porcentaje de avance | — |
| Índice de unidades; con |
|
| Entregas y cierres de cuestionarios de todas las materias, ordenados por fecha |
|
| TPs con consigna, fecha de entrega y si ya entregaste |
|
| Calificaciones, estado y devoluciones del profesor |
|
| Publicaciones de los foros de avisos |
|
| Mensajería privada: lista de conversaciones o el historial de una |
|
| Las notificaciones de la campanita (contenido nuevo, correcciones) |
|
| Eventos del calendario, incluidos los que el profesor carga a mano |
|
| Cuántas actividades llevás calificadas y el promedio, materia por materia |
|
| Actividad por actividad, qué está completado y qué falta |
|
| Corrección de un cuestionario rendido, pregunta por pregunta |
|
| Baja un archivo del campus a |
|
El flujo típico es empezar por listar_materias para obtener el ID de una
materia, y usar ese ID en las demás.
Para responder "¿hay algo nuevo?" hacen falta las tres vías de comunicación,
que son independientes entre sí: leer_avisos_foro (foros de la materia),
leer_mensajes_directos (mensajes privados de profesores y tutores) y
ver_notificaciones (avisos automáticos del sistema).
Detalles de diseño, por si los tocás:
ver_contenido_materia devuelve un índice por defecto. Las materias
tienen decenas de unidades y traer todo junto llena el contexto sin
necesidad. Primero el índice, después el detalle de la unidad que interese.
revisar_cuestionario sigue el mismo patrón: sin cuestionario, la lista.
proximos_vencimientos no usa el calendario de Moodle. Lo arma leyendo
las fechas reales de las entregas y los cuestionarios, porque el calendario
omite actividades ya completadas y devolvía listas vacías. ver_calendario
sí lo consulta, pero con core_calendar_get_calendar_events, que devuelve
todos los eventos del rango; la variante ..._get_action_events_by_timesort
filtra lo ya completado y viene vacía. Las dos herramientas se complementan.
ver_resumen_notas calcula el promedio a mano. El campus no llena el
total de cada materia (el ítem de tipo course viene siempre en -), así
que el promedio sale de las notas de cada actividad. Es una consulta por
materia: van de a tandas de 4, porque disparar más de diez juntas hace que el
campus corte la conexión.
revisar_cuestionario desarma HTML. Moodle no expone el enunciado, las
opciones ni la corrección como campos: vienen dentro de un bloque de HTML por
pregunta, con <script> de inicialización al final. Se recorta por el cierre
real de cada <div>, no por cantidad de caracteres, para que los bloques no
se pisen entre sí.
No todo lo que documenta Moodle está disponible con el token del servicio
moodle_mobile_app. Comprobado contra la UTN:
core_notes_get_course_notes responde nopermissions: las "notas" del
docente sobre el estudiante están deshabilitadas, así que no hay herramienta
para eso.
Para ver qué habilita tu campus, core_webservice_get_site_info devuelve en su
campo functions la lista completa de funciones que tu token puede llamar.
MCP es un protocolo abierto y agnóstico del modelo. Este servidor no contiene código específico de ningún proveedor: expone herramientas por JSON-RPC, y cada cliente las traduce al mecanismo de function calling de su modelo. Funciona igual con Claude, GPT, Gemini o cualquier modelo con soporte de herramientas.
invalidtoken — El token venció o se copió incompleto. Volvé a generarlo
con el curl del paso 2.
invalidlogin al pedir el token — Usuario o contraseña incorrectos. Probá
entrar al campus por el navegador para confirmar tus credenciales.
El cliente no ve el servidor — Verificá que la ruta en la configuración sea
absoluta y apunte a src/index.js. Probá primero npm run probar-token.
Una herramienta devuelve una lista vacía — Es normal si la materia no tiene
ese tipo de contenido (por ejemplo, ver_trabajos_practicos en una materia sin
TPs cargados).
No hay nada atado a la UTN en el código: cambiá MOODLE_URL en tu .env por la
URL de cualquier otro Moodle que tenga los web services habilitados.
Para verificar si un campus los tiene activos:
curl -s "https://EL-CAMPUS/login/token.php?username=x&password=x&service=moodle_mobile_app"Si responde invalidlogin, están habilitados (solo faltan credenciales válidas).
Si responde que el servicio no está disponible, el administrador tiene que
activarlos.
npm run typecheck # chequeo de tipos vía JSDoc, sin compilar
npm start # levanta el servidor a mano (habla MCP por stdin/stdout)El proyecto es JavaScript con anotaciones JSDoc y checkJs activado: tenés
autocompletado y verificación de tipos en el editor sin ningún paso de
compilación.
MIT
Baja un archivo del campus (apunte, PDF, presentación) usando la URL que devuelve ver_contenido_materia. Devuelve la ruta local para que después puedas leerlo. Si el archivo es de texto plano, también devuelve su contenido.
Por defecto lo guarda en la carpeta descargas/ del servidor. Pasá destino con una ruta de carpeta para guardarlo directamente donde lo necesites (por ejemplo, la carpeta de materiales de un repositorio de apuntes); se crea si no existe.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL del archivo, tal como la devuelve ver_contenido_materia | |
| nombre | No | Nombre con el que guardarlo (por defecto, el original) | |
| destino | No | Carpeta donde guardarlo. Absoluta, o relativa al directorio desde el que se lanzó el servidor. Por defecto, descargas/. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool downloads a file, returns the local path, and for plain text files returns the content. It notes the default save directory and that the destination folder is created if missing. However, it does not disclose whether the tool overwrites existing files, handles errors, or has any rate limits. This is adequate but leaves some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short paragraphs. The first sentence states the core action and return value. The second paragraph adds defaults and optional parameter guidance. Every sentence serves a purpose with no fluff, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the return values (local path, optional content for plain text). It explains default behavior and optional parameters. However, it omits potential errors, permissions, and file size limits. For a straightforward download tool, it is largely complete but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline is 3. The description adds value: for 'url' it clarifies it must come from ver_contenido_materia; for 'destino' it explains absolute/relative paths and that the folder is created if needed. For 'nombre' it only mentions default, matching schema. Overall, the description enriches the schema beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a file from the campus (apunte, PDF, presentación) using the URL from ver_contenido_materia. The verb 'baja' (download) and resource 'archivo del campus' are specific, and it distinguishes from sibling tools like listar_materias and ver_contenido_materia which are for listing and viewing, not downloading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool with the URL from ver_contenido_materia, providing clear usage context. It also explains the default save location and the optional 'destino' parameter. However, it does not mention when not to use it (e.g., for non-downloadable files or large downloads) or provide explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve las últimas publicaciones de los foros de una materia. Por defecto trae solo los foros de avisos y novedades, que es donde los profesores comunican cambios de fecha y consignas.
Usá esta herramienta cuando pregunten si hay novedades o avisos del profesor. Pasá todos_los_foros en true solo si además quieren ver los foros de consultas entre estudiantes, que suelen ser muchos.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Cuántas publicaciones traer por foro (por defecto 10) | |
| courseid | Yes | ID de la materia, obtenido de listar_materias | |
| todos_los_foros | No | Incluir también los foros de consultas (por defecto false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers default behavior (only news forums) and the effect of 'todos_los_foros', noting that student forums are numerous. It does not detail return format or side effects, but for a read tool this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences plus usage instructions. It is front-loaded with purpose and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently explains what the tool returns (latest posts) and covers the key parameter behavior. It is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline is 3. The description adds context: default forum scope, association of courseid with 'listar_materias', and guidance on 'todos_los_foros'. This extra information justifies a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the latest forum posts of a subject, specifying default behavior (news and announcements) and optional all forums. It distinguishes from sibling tools by focusing on forums.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use when asked about news or teacher announcements, and describes when to use the 'todos_los_foros' parameter (only if student consultation forums are desired). Provides explicit usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve las materias en las que estás inscripto, con su ID y el avance del cursado. Usá esta herramienta primero cuando necesites el ID de una materia para cualquier otra consulta.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the tool's behavior: returns enrolled subjects with ID and progress. It doesn't mention any side effects, but none are expected for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool, the description completely covers what the tool does and when to use it. It compensates for the lack of output schema by naming the return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage), so baseline is 3. The description adds value by specifying the returned fields (ID and progress), which helps the agent understand the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Devuelve' (returns) and the resource 'materias en las que estás inscripto', with specific details (ID and progress). It distinguishes from sibling tools that likely require a subject ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Usá esta herramienta primero cuando necesites el ID de una materia para cualquier otra consulta', providing clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista qué se vence próximamente en TODAS tus materias: entregas de trabajos prácticos y cierres de cuestionarios, ordenados por fecha. Usá esta herramienta cuando pregunten qué tienen pendiente, qué se vence esta semana o cómo organizar el estudio.
Si no hay nada dentro del rango pedido, igual informa cuál es el próximo vencimiento que viene después.
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | Cuántos días hacia adelante mirar (por defecto 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden and effectively discloses behavior: listing all subjects' assignments and quizzes ordered by date, plus fallback. It does not mention potential limitations like pagination, but for a simple list it is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: the first states purpose and usage, the second provides fallback behavior. Every sentence adds value and the structure is front-loaded with core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one optional parameter, no output schema), the description fully covers what the tool does, when to use it, and its behavior, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter (dias), so the baseline is 3. The description adds no extra semantics beyond the schema's definition; it does not mention the parameter at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Lista qué se vence') and resources (entregas de trabajos prácticos y cierres de cuestionarios), clearly distinguishing it from sibling tools like listar_materias or ver_trabajos_practicos, which focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (when asked about pending tasks, due this week, or study organization) and provides fallback behavior (informs next upcoming deadline if none in range), offering clear guidance on usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explora el material de una materia: apuntes, PDFs, videos, tareas y foros, organizados por unidad.
Sin el parámetro unidad devuelve el índice: la lista de unidades con cuántos recursos tiene cada una. Con unidad devuelve el detalle completo de esa unidad, incluidas las URLs de los archivos para bajar después con descargar_archivo.
Empezá siempre por el índice: las materias suelen tener decenas de unidades y pedir todo junto es innecesario.
| Name | Required | Description | Default |
|---|---|---|---|
| unidad | No | Nombre (o parte del nombre) de la unidad a detallar. Si se omite, se devuelve solo el índice. | |
| courseid | Yes | ID de la materia, obtenido de listar_materias |
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 transparently explains the two modes (index vs detail), that detail includes file URLs for later downloading with 'descargar_archivo', and implies a read-only operation. It does not explicitly state the tool is non-destructive, but the context strongly suggests it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written paragraphs plus a standalone guiding sentence. Every sentence adds value: first paragraph states purpose, second paragraph explains two modes and mentions file URLs, third sentence gives usage advice. No wasted words, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and no output schema, the description is remarkably complete. It covers the tool's dual behavior, the relationship with sibling tools (especially 'descargar_archivo'), and provides a best-practice invocation strategy. An agent can use this tool correctly without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described in schema). The description adds extra meaning: for 'unidad', it explains it accepts a name or partial name and that omitting it changes behavior to returning only the index. For 'courseid', it mentions it comes from 'listar_materias', providing valuable contextual sourcing. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool explores course material (apuntes, PDFs, videos, tareas, foros) organized by unit. It distinguishes two modes: returning just the index when 'unidad' is omitted, and returning the full detail including file URLs when 'unidad' is provided. This differentiates it from siblings like 'descargar_archivo' or 'ver_trabajos_practicos'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Empezá siempre por el índice: las materias suelen tener decenas de unidades y pedir todo junto es innecesario.' This tells the agent to first call without 'unidad' to get an index, then optionally with 'unidad' for details. It could be more explicit about when not to use this tool versus siblings, but the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve tus calificaciones en una materia, ítem por ítem, con la devolución del profesor cuando existe. Usá esta herramienta cuando pregunten por sus notas, por cómo vienen en una materia o por la corrección de una entrega.
| Name | Required | Description | Default |
|---|---|---|---|
| courseid | Yes | ID de la materia, obtenido de listar_materias | |
| solo_calificados | No | Si es true, omite los ítems que todavía no tienen nota |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds behavioral context (returns per-item grades and teacher feedback) but lacks details on side effects or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words, front-loaded with purpose and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains what is returned. Adequate for a simple read tool with two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds helpful cross-reference: courseid obtained from listar_materias. Optional parameter clearly explained in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns grades per item with teacher feedback, distinct from siblings like listing courses or assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: when asked about grades, course progress, or submission corrections. Does not mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve los trabajos prácticos de una materia con su consigna, la fecha de entrega y si ya los entregaste o no. Usá esta herramienta cuando pregunten por un TP puntual, por la consigna de una entrega o por qué les falta entregar en una materia.
| Name | Required | Description | Default |
|---|---|---|---|
| courseid | Yes | ID de la materia, obtenido de listar_materias | |
| solo_pendientes | No | Si es true, devuelve únicamente los que no entregaste |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns data but does not disclose any behavioral traits such as idempotency, side effects, permissions, or rate limits. The word 'Devuelve' implies a read operation, but that is not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first describes the output, second gives usage guidance. Both are front-loaded and to the point. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and no output schema, the description mentions the output fields (consigna, fecha de entrega, delivery status) but does not provide a concrete structure or format. For a simple retrieval, it is adequate but could specify the exact output format or any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description does not add any extra meaning beyond what the parameter descriptions already provide (courseid from listar_materias, solo_pendientes for filtering). It merely mentions output fields but not parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Devuelve' (returns) and the resource 'trabajos prácticos' (practical works), specifying the key output fields: assignment, due date, and delivery status. This distinguishes it from sibling tools like 'listar_materias' or 'ver_contenido_materia' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage scenarios: 'Usá esta herramienta cuando pregunten por un TP puntual, por la consigna de una entrega o por qué les falta entregar en una materia.' This gives clear guidance on when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0descargar_archivoleer_avisos_forolistar_materiasproximos_vencimientosver_contenido_materiaver_notasver_trabajos_practicosCada herramienta tiene un propósito claramente distinto: listar materias, ver contenido, vencimientos, trabajos prácticos, notas, foros y descargar archivos. No hay superposición entre ellas.
La mayoría sigue el patrón verbo_sustantivo (listar_materias, ver_contenido_materia, ver_trabajos_practicos, ver_notas, leer_avisos_foro, descargar_archivo). Una excepción es 'proximos_vencimientos', que es un sustantivo sin verbo.
Con 7 herramientas, la cantidad es adecuada para un asistente de gestión universitaria. Cubre las consultas principales sin ser excesivo.
Las herramientas son principalmente de consulta, faltan operaciones de creación o modificación (como entregar trabajos o publicar en foros). Para un asistente informativo es suficiente, pero hay ausencias notables para completar el ciclo de vida del estudiante.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP server for Muovi, Argentina's trust-first local services marketplace (6 tools).
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Carbon Voice MCP serves as a bridge that connects AI assistants like ChatGPT, Claude, and Cursor to a user's Carbon Voice account, turning voice messages and conversations into a private, on-demand knowledge base. It provides 28 specialized tools for comprehensive voice messaging management, including creating and sending messages, accessing conversation history with instant transcription, running AI actions (summarization, TLDR generation, meeting notes), and managing workspace collaboration through folders, contacts, and team communications.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/brujoh88/MCP-TUPAD'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
