Skip to main content
Glama
Sign In
Chispa MCP

Chispa MCP

by jeffercbs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Editar examen

update_exam

Update an exam's settings by sending only the fields to change, then confirm before publishing; activating requires at least 10 questions.

Instructions

[Equipo del aula] Cambia la configuración de un simulacro o examen. Solo se modifica lo que envíes. Confirma con la persona antes de publicar. Para activar el simulacro el examen necesita al menos 10 preguntas.

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": "update_exam"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleNo
exam_idYesExamen
publishedNo
repeatableNoSi se puede repetir cada cierto tiempo
descriptionNoInstrucciones (omítelo para no cambiarlo; "" lo borra)
repeat_daysNo
review_modeNo
classroom_idYesAula
max_attemptsNo
pass_percentNo
practice_maxNo0 quita el máximo
practice_minNo
repeat_hoursNo
feedback_failNoMensaje si no aprueba (omítelo para no cambiarlo; "" lo borra)
feedback_passNoMensaje si aprueba (omítelo para no cambiarlo; "" lo borra)
practice_enabledNo
time_limit_minutesNo0 quita el límite

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-destructive, closed-world, so the bar is lower; the description still adds genuine behavior: it is a patch (omitted fields are untouched) and publishing carries a 10-question precondition plus a human-confirmation requirement. It doesn't describe what a successful response looks like or side effects on already-published exams.

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?

Four short sentences, each carrying a distinct, load-bearing fact (scope, patch semantics, confirmation, activation precondition), with the core purpose front-loaded.

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

Completeness3/5

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

For a 17-parameter mutation tool with no output schema and under-half schema coverage, the description covers the most dangerous operation (publishing) but says nothing about how to verify success or about the many undefined configuration fields. Adequate to call it safely, not adequate to call it well.

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 47%, so the description needs to compensate, and it does partially by establishing patch semantics for all 17 fields and by tying the 'published' flag to the 10-question rule. However, most parameters (title, repeatable, repeat_days, repeat_hours, review_mode, max_attempts, pass_percent, practice_enabled, practice_min) get no added meaning beyond their names.

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: it changes ('Cambia') the configuration of an exam/simulacro, and 'Solo se modifica lo que envíes' makes it clear this is a partial update rather than a replace. It doesn't differentiate from the sibling set_published, which can apparently also toggle the published flag that this tool accepts.

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 real operating guidance: include only the fields you want changed, confirm with the user before publishing, and the exam needs at least 10 questions to be activated. It never says when to prefer this over set_published for publishing, nor when update_exam is the wrong tool, so the alternative routing is left implicit.

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