utn-mcp

aula_study_pack

Combines classroom PDFs into one study compilation with a clickable index and page-return links, saving it locally; skips non-PDF URLs and reports omissions.

Instructions

Une PDF del aula en un solo compilado de estudio con índice clickeable (cada entrada abre la página donde empieza ese material, y cada página tiene arriba un enlace para volver), guardado en la compu del usuario. Une ÚNICAMENTE PDF; si una URL pedida no es PDF, queda en omitidos con el motivo.

Conviene llamar antes a aula_open del curso: devuelve cada módulo con sus archivos (nombre, url, sección y tipo) y permite elegir los apuntes sin bajar nada. Es un compilado íntegro, no un resumen.

Hay topes por memoria: 150 archivos, 300 MB de descarga total y 30 MB el PDF final (estimado con los tamaños de entrada, para no bajar archivos de más). Lo que no entra queda en omitidos con el motivo: se pide el resto en otro pack. La respuesta trae la ruta en archivo y materiales con sección, módulo, páginas y página de inicio de cada uno.

La direccion del curso sale de aula_list_courses. Para leer o pasarle al usuario archivos que no son PDF, usá aula_open y aula_read_file.

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_study_pack"
  }
}

Input Schema

Name	Required	Description	Default
`archivos`	No	URL de los PDF a unir, tal como las devuelve aula_open del curso (conviene llamarlo antes y elegir: cada archivo trae nombre, sección y tipo). El pack sigue el orden del aula, no el de esta lista. Sin `archivos`, une todos los PDF del curso.
`direccion`	Yes	Dirección del curso, de aula_list_courses. Ej: "/curso/691".

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.3Oct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false with destructiveHint=false; the description fills in what that actually means — a file is written to the user's local disk, nothing is destroyed. It also discloses hard capacity limits (150 archivos, 300 MB de descarga, 30 MB de PDF final), that overages are not errors but land in `omitidos` with a reason, and that the final-size cap is estimated from input sizes to avoid over-downloading. That is behavior an agent cannot infer from the annotations.

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 purpose, then prerequisites, then limits, then the response shape — a sensible order with no filler sentences. It runs long across four paragraphs and the aula_open pointer is repeated in two places (prerequisite paragraph and closing line), which costs a little tightness.

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?

There is no output schema, and the description compensates by naming the return fields (`archivo` ruta, `materiales` con sección, módulo, páginas y página de inicio, `omitidos` con motivo). Combined with the disclosed limits and the explicit non-goal ("Es un compilado íntegro, no un resumen"), an agent has everything needed to call it and to interpret the result.

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 the baseline is 3; the description earns a point by adding selection semantics the schema does not spell out — non-PDF URLs are silently dropped into `omitidos` rather than failing, the pack follows the aula's order rather than the caller's list, and the memory caps constrain how many requested files will actually be honored. It does not add syntax or format detail for `direccion` beyond the schema example.

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?

States a specific verb and output ("Une PDF del aula en un solo compilado de estudio con índice clickeable") plus the destination ("guardado en la compu del usuario"). Immediately bounds the scope ("Une ÚNICAMENTE PDF") and explicitly contrasts with the sibling that does something else, so an agent can distinguish it from aula_open/aula_read_file without opening a schema.

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?

Gives an explicit prerequisite ("Conviene llamar antes a aula_open del curso"), names where the required `direccion` comes from (aula_list_courses), and routes the agent elsewhere for the excluded case ("Para leer o pasarle al usuario archivos que no son PDF, usá aula_open y aula_read_file"). When-to-use, prerequisites, and alternatives are all present.

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

Deploy Server