Campus Virtual MCP

upload_files

Uploads and verifies assignment files in a temporary area, returning a 30-minute receipt without submitting; enforces allowed types, sizes, and quantities.

Instructions

Carga y verifica archivos en el área temporal de una tarea abierta; devuelve un recibo.

Respeta los tipos, tamaños y cantidad admitidos por la actividad. Admite archivos de cualquier tipo permitido, incluidos ZIP; rechaza carpetas y reemplazos de entregas. No guarda ni envía la entrega. El recibo dura 30 minutos en este proceso MCP.

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>",
      "activity_id": "<activity_id>",
      "files": "<files>"
    },
    "name": "upload_files"
  }
}

Input Schema

Name	Required	Description
`files`	Yes	Rutas locales de archivos regulares; no carpetas.
`course_id`	Yes	ID de la materia o módulo, según el parámetro.
`activity_id`	Yes	ID de la materia o módulo, según el parámetro.

Output Schema

Name	Required	Default
`files`	Yes
`stage`	No	temporary
`limits`	Yes
`message`	No	Archivos verificados en el área temporal; la entrega no se guardó.
`verified`	No
`course_id`	Yes
`upload_id`	Yes
`activity_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 2, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=false, openWorld=true, idempotent=false) by disclosing that files land in a temporary staging area, that the receipt expires after 30 minutes, that folder paths and replacement submissions are rejected, and that the delivery is neither stored nor sent. These are exactly the operational traits an agent needs and none of them are derivable from structured fields.

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 action and the return value are front-loaded in the first clause, followed by constraints and the TTL caveat. Every sentence carries information, though the type/size/quantity constraint phrased as "según la actividad" is vague enough to be nearly filler.

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?

Output schema exists so return shape need not be described, yet the description still explains what the receipt is worth in time. Combined with the exclusion rules and the non-persistence statement, an agent has everything needed to call this correctly and set expectations afterwards.

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?

Schema coverage is 100%, so each parameter is already documented, and the description only reinforces the files constraint (no folders). It does not resolve the schema's own ambiguity where activity_id repeats the description of course_id, nor does it explain how the per-activity type/size limits map to the files array. Baseline 3 applies.

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?

Names a specific verb and resource (upload and verify files into a task's temporary area) plus the return value (a receipt), and explicitly distinguishes the operation from actually submitting work ("No guarda ni envía la entrega"), which separates it from siblings like prepare_submission and submit_assignment.

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?

Gives clear context for use: it must target an open task, it rejects folders and resubmissions, and it does not persist the submission, which implies the follow-up step. It does not, however, name the sibling tools to use before or after (prepare_submission / submit_assignment), so routing is left partly to inference.

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

Deploy Server