Skip to main content
Glama
Sign In
Chispa MCP

Chispa MCP

by jeffercbs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Crear un examen completo con sus preguntas

import_exam

Creates a draft exam or quiz and loads up to 200 questions in one all-or-nothing call. Validate first with dry_run=true before saving.

Instructions

[Equipo del aula] Crea un simulacro o examen y carga todas sus preguntas en una sola llamada (hasta 200). Es todo o nada: si algo falla no queda un examen a medias. Formato de texto: una pregunta por línea «enunciado | opción | *correcta | opción | explicación: … | tema: … | lección: 2». Usa dry_run=true primero para validar sin guardar. Queda en borrador.

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>",
      "module_id": "<module_id>",
      "title": "<title>"
    },
    "name": "import_exam"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleYesTítulo
dry_runNo
module_idYesMódulo
questionsNoPreguntas en JSON
repeatableNoSi se puede repetir cada cierto tiempo
descriptionNoInstrucciones
repeat_daysNo
review_modeNoexplicaciones
classroom_idYesAula
max_attemptsNo
pass_percentNo
questions_textNoPreguntas en texto compacto
time_limit_minutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare a non-destructive write in a closed world; the description adds substantial behavior beyond that: atomic all-or-nothing semantics ('si algo falla no queda un examen a medias'), the 200-question cap, the draft end-state, and the dry_run validation path. '[Equipo del aula]' also signals the access scope.

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, then atomicity, then the format spec, then the dry_run recommendation and draft state — a sensible priority order with no filler. The format sentence is dense and pipe-heavy but every clause carries operational meaning.

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 13-parameter, no-output-schema mutation, the description covers the critical risks: partial writes, size limits, validation before commit, and the resulting state. Remaining gaps are the untranslated operational params (review_mode enum values, repeat/repeat_days interplay) and any note on what the response contains.

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 only 54% and questions_text is documented merely as 'Preguntas en texto compacto', yet the description spells out the full pipe-delimited line format including markers (* for correct, 'explicación:', 'tema:', 'lección: 2'). That resolves the hardest parameter; the remaining 10 unannotated params (review_mode, repeat_days, pass_percent, time_limit_minutes, max_attempts) get no mention.

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 ('Crea un simulacro o examen y carga todas sus preguntas') plus the key differentiator 'en una sola llamada (hasta 200)'. It never names the siblings create_exam / add_exam_questions, so the two-step alternative has to be inferred rather than read.

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 operational guidance: use dry_run=true first to validate without saving, and notes the result lands in draft (implying set_published is a later step). It stops short of saying when to prefer this over create_exam + add_exam_questions, or when 200 is too many.

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

Deploy Server

Other Tools