Skip to main content
Glama
zumaetaadriel2

BanqueUNT MCP

Generar simulacro

generar_simulacro

Generates a randomized mock exam from the question bank, avoids repeats, and prioritizes questions the student has not seen; returns numbered questions without answers for later grading.

Instructions

Arma un simulacro al azar con preguntas del banco, sin repetir y priorizando las que el alumno aún no vio. Devuelve un simulacro_id y las preguntas numeradas SIN respuesta. Muéstralas al alumno sin resolverlas y, cuando responda, llama a corregir_simulacro.

Input Schema

NameRequiredDescriptionDefault
aniosNoP. ej. ["2020", "2021"]
cursoNoId del curso; opcional si el servidor tiene uno solo
temasNoPartes del nombre del tema; basta con que coincida uno
cantidadNo
dificultadNo"Fácil", "Intermedio" o "Difícil"
especialidadesNoP. ej. ["Cardiología", "Nefrología"]
excluir_vistasNoPrimero preguntas que no salieron en simulacros anteriores; si no alcanzan, completa con vistas
solo_prioritariasNo

Output Schema

NameRequiredDescriptionDefault
cursoYes
totalYes
nuevasYes
expira_enYes
preguntasYes
repetidasYes
disponiblesYesPreguntas que cumplen los filtros
simulacro_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the load and does well: it discloses randomness, no-repeat selection, the unseen-first prioritization with a fallback, and critically that answers are stripped from the output. It omits any note on quotas (cantidad max 100), what happens with zero matches, or permission/course requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences in a strict priority order: what it builds, what it returns, what the agent must do next. No filler and no repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return shape needn't be spelled out, though the description usefully adds that answers are excluded. For an 8-param generation tool with all-optional inputs, the main remaining gap is that an agent isn't told what happens with no filters or when the bank can't satisfy the request.

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 75%, so the baseline is 3. The description's mention of 'priorizando las que el alumno aún no vio' gives behavioral meaning to excluir_vistas, but it never addresses solo_prioritarias, which has no schema description at all, nor how the filters (anios, temas, especialidades, dificultad) combine.

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 resource ('arma un simulacro al azar con preguntas del banco') and adds the two defining selection rules (sin repetir, priorizando no vistas). An agent can distinguish it from buscar_preguntas or estadisticas_banco without opening any schema.

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 explicit downstream routing: show the questions unresolved, and call corregir_simulacro once the student answers. Strong context, but it never states when NOT to use it (e.g., vs. buscar_preguntas for ad-hoc lookups) or that all filter params are optional.

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