Campus Virtual MCP

list_monthly_activities

Read-onlyIdempotent

Lists all monthly calendar activities for every subject in JSON, optionally filtered by year, month, or deadlines only. Use it to review visible course events and due/close dates for your account.

Instructions

Lista en JSON las actividades del calendario mensual de todas las asignaturas.

Omití year y month para consultar el mes actual en la zona del campus, o indicá ambos. Incluye nombre, asignatura, fechas ISO 8601 con hora y offset, y activity_url directo. deadline_at solo se completa para due/close; aperturas y asistencias conservan su tipo. No confirma entregas pendientes. Autentica con .env y consulta solo eventos visibles para la cuenta y sus filtros de calendario. No depende del idioma de la interfaz.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_monthly_activities"
  }
}

Input Schema

Name	Required	Description
`year`	No	Año; junto con month.
`month`	No	Mes entre 1 y 12.
`deadlines_only`	No	Solo vencimientos (due) y cierres (close).

Output Schema

Name	Required	Description	Default
`year`	Yes
`month`	Yes
`total`	Yes
`timezone`	Yes
`warnings`	Yes
`activities`	Yes
`fetched_at`	Yes
`source_url`	Yes
`deadlines_only`	Yes
`timezone_source`	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?

Annotations only declare read-only/idempotent/open-world; the description adds substantial context beyond them: authentication via .env, results limited to events visible to the account and its calendar filters, current-month default resolved in campus timezone, deadline_at semantics per activity type, and language-independence. This is exactly the kind of behavioral detail 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 purpose and default behavior, then progressively finer detail; every sentence carries information. Mild redundancy in enumerating returned fields (name, asignatura, ISO 8601 dates, activity_url) that an output schema already covers.

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?

Covers everything an agent needs: scope of subjects, default time range and its timezone, authentication, visibility filtering, and the deadline field semantics, while the output schema handles return structure. Nothing material is missing for correct invocation.

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, but the description adds meaning the schema does not: null year/month resolve to the current month in the campus timezone and the two must be supplied together, plus how deadline-type filtering interacts with activity types. deadlines_only itself is left to the schema, which documents it adequately.

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?

States a specific verb and resource: lists calendar activities for a month across all subjects, returned as JSON. It is unambiguous on its own, though it never explicitly contrasts itself with siblings such as get_submission_status, so sibling differentiation is only implicit.

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?

Gives concrete usage rules for the date parameters (omit both for the current month, or supply both) and clarifies the scope boundary 'No confirma entregas pendientes', which hints that submission status belongs elsewhere. However, it never names an alternative tool or states when-not-to-use, so guidance is implied rather than explicit.

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

Deploy Server