Skip to main content
Glama
Sign In
Chispa MCP

Chispa MCP

by jeffercbs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Crear o editar una pregunta de autoevaluación

save_self_check_question

Create an open-ended self-assessment question and answer in a classroom lesson, or update an existing one by supplying its question ID. Use it to add or edit lesson self-check questions.

Instructions

[Equipo del aula] Crea una pregunta de autoevaluación (pregunta y respuesta abiertas) en una lección o edita una existente (envía question_id).

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>",
      "session_id": "<session_id>",
      "question": "<question>",
      "answer": "<answer>"
    },
    "name": "save_self_check_question"
  }
}

Input Schema

NameRequiredDescriptionDefault
answerYesRespuesta
positionNo
questionYesPregunta
session_idYesLección
question_idNoPregunta a editar
classroom_idYesAula

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the description's remaining job is to explain effects. It adds the '[Equipo del aula]' scope marker, implying a classroom-team permission context, which is useful. It stops short of saying that an update overwrites the existing question and answer, or what happens to 'position' when an item is re-saved.

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?

A single sentence with no filler, front-loading the create case and then the edit variant. The scope tag and the mode switch are packed into one clause each without redundancy.

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?

Six parameters, four of them required, with no output schema and an upsert semantics: the definition is adequate but leaves the read-back shape and the update-vs-create required-field interaction unstated. For an upsert tool the description should at minimum clarify that an edit still needs question and answer resent.

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 description coverage is 83%, so the schema already documents classroom_id, session_id, question_id, question and answer. The description's only real semantic addition is that supplying question_id selects edit mode, which the schema field 'Pregunta a editar' already largely conveys. The optional 'position' parameter is left entirely unexplained in both places.

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 una pregunta de autoevaluación') and clarifies the content shape (open question and answer) plus the target container (a lesson). It does not differentiate itself from closely named siblings such as save_quiz_question, save_flashcard or save_exam_question, so an agent must infer the distinction from the tool name alone.

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?

The parenthetical '(envía question_id)' gives a workable rule for switching between create and edit modes, which is the main ambiguity for this tool. However, there is no guidance on when to choose this tool over the sibling question/flashcard savers, and no note that question_id is required for updates while the other four parameters are also still required.

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