Campus Virtual MCP

download_resources

Download up to 10 campus files to a local folder, verifying course/module membership and validating each file with SHA-256.

Instructions

Descarga entre 1 y 10 archivos del campus a downloads/course-ID/module-ID/.

Verifica su pertenencia al módulo y a la materia con una consulta autenticada nueva. Usa la sesión de Lightpanda y un transporte HTTP binario del mismo origen. Valida respuesta HTTP y tamaño; calcula SHA-256 y detecta páginas de login/error de Moodle. Admite cualquier extensión y MIME; no valida el formato interno ni ejecuta archivos. No sigue redirecciones ni reemplaza archivos existentes. Devuelve rutas locales, tamaños, hashes y fallos por archivo. Solo archivos del campus, sin destinos externos. No modifica entregas del campus.

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": {
      "course_id": "<course_id>",
      "module_id": "<module_id>",
      "urls": "<urls>"
    },
    "name": "download_resources"
  }
}

Input Schema

Name	Required	Description
`urls`	Yes	Enlaces de archivo de get_course_resources, en el orden solicitado.
`course_id`	Yes	ID de la asignatura de Grado.
`module_id`	Yes	ID del módulo donde aparecen los archivos.

Output Schema

Name	Required	Description	Default
`files`	Yes
`course`	Yes
`complete`	Yes
`failures`	Yes
`module_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 2, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Rich disclosure well beyond the annotations: a new authenticated query verifies module/subject membership, Lightpanda session plus same-origin binary HTTP transport, HTTP response and size validation, SHA-256 hashing, login/error page detection, no redirect following, no overwriting of existing files, and no mutation of campus submissions. This is exactly the kind of operational context annotations cannot convey.

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 action, batch limit and destination before the behavioral details; each later sentence contributes a distinct constraint (validation, hashing, redirects, overwrite policy, return shape). It is dense but almost every clause earns its place; only the 'campus-only' statement is slightly reiterated across two sentences.

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 an output schema present, the description need not detail return values, yet it still summarizes them (local paths, sizes, hashes, per-file failures). Combined with the annotations and full schema coverage, an agent has everything needed to invoke this correctly.

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 already 100%, so baseline is 3, but the description adds real meaning: URLs are verified against module_id/course_id and the destination path is derived from those IDs, and the 1–10 bound on urls is reinforced. It does not clarify what happens when some URLs fail validation beyond returning per-file failures.

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 first sentence names a specific verb, resource, quantity limit and destination path: 'Descarga entre 1 y 10 archivos del campus a downloads/course-ID/module-ID/'. It also implicitly separates itself from upload_files/submit_assignment via 'No modifica entregas del campus', but it never names a sibling (e.g. get_course_resources) in the description itself, so differentiation is inferred rather than stated.

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 is implied: URLs must come from campus resources and belong to the given module/subject, and only campus files are allowed. However, there is no explicit 'use this when / use X instead' routing, and no stated prerequisites such as the need to be logged in first, even though a sibling login tool exists.

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

Deploy Server