Skip to main content
Glama

Cargar preguntas en un examen

add_exam_questions

Loads up to 200 multiple-choice questions into an exam or practice test in one call, validating everything before saving and flagging any failing line.

Instructions

[Equipo del aula] Carga preguntas de opción múltiple en un simulacro o examen (hasta 200 por llamada). Envía questions (JSON) o questions_text (una por línea: «enunciado | opción | *correcta | opción | explicación: … | tema: … | lección: 2»). Es todo o nada: si una pregunta falla no se guarda ninguna y se indica la línea. Usa dry_run=true para validar sin guardar. Con replace=true sustituye todas las existentes (confirma antes con la persona).

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": {
      "classroom_id": "<classroom_id>",
      "exam_id": "<exam_id>"
    },
    "name": "add_exam_questions"
  }
}

Input Schema

NameRequiredDescriptionDefault
dry_runNotrue solo valida y muestra qué se guardaría
exam_idYesExamen
replaceNotrue borra primero todas las preguntas actuales
questionsNoPreguntas en JSON
classroom_idYesAula
questions_textNoPreguntas en texto compacto, una por línea

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.4/5.0
Behavior2/5

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

Beyond the annotations it discloses valuable behavior: all-or-nothing atomicity, line-number error reporting, the 200-item cap, and the dry-run validation mode. However, it states that replace=true 'sustituye/borra primero todas las preguntas actuales', which is a destructive update, while the annotations declare destructiveHint=false — a direct conflict an agent could rely on incorrectly.

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?

Four dense sentences, front-loaded with scope and the destructive replace warning trailing appropriately. The inline format example is long but earns its place because it defines a custom text grammar; no filler or repetition.

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?

For a 6-parameter mutation with no output schema and full schema coverage, the description covers input formats, validation mode, atomicity, and the overwrite caveat. The only real omission is what a successful call returns (count of loaded questions) and the permission/profile requirements behind '[Equipo del aula]'.

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%, yet the description adds meaning the schema does not: the compact questions_text grammar with pipe separators, '*correcta' marking the right option, and inline 'explicación:'/'tema:'/'lección:' fields. It also clarifies the mutual role of `questions` vs `questions_text` and the effect of dry_run and replace.

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: 'Carga preguntas de opción múltiple en un simulacro o examen', with a volume cap of 200 per call. The exam target is explicit, but the description never names the adjacent single-question or quiz tools (save_exam_question, add_quiz_questions), so the boundary is only implied by 'simulacro o examen'.

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?

It gives strong in-tool guidance: dry_run=true to validate without saving, replace=true to overwrite, and 'confirma antes con la persona'. What is missing is routing between this bulk loader and the sibling tools that also add question content, so the agent must infer that this is the bulk path rather than the single-item one.

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