Skip to main content
Glama
Sign In
Chispa MCP

Chispa MCP

by jeffercbs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Cargar varias lecciones con su quiz y tarjetas

import_module_content

Creates up to 30 lessons at the end of a module, each with quizzes and cards, in one all-or-nothing call; validate with dry_run first and publish only after confirmation.

Instructions

[Equipo del aula] Crea hasta 30 lecciones al final de un módulo, cada una con su quiz y sus tarjetas, en una sola llamada. Es todo o nada. Usa dry_run=true para validar primero. Quedan en borrador salvo publish=true (confirma con la persona antes de publicar).

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>",
      "lessons": "<lessons>"
    },
    "name": "import_module_content"
  }
}

Input Schema

NameRequiredDescriptionDefault
dry_runNo
lessonsYes
publishNo
module_idYesMódulo
classroom_idYesAula

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only say it is not read-only and not destructive; the description adds substantial context on top: all-or-nothing atomicity, append-at-end placement, draft-by-default state, and the dry_run validation path. It does not say what happens to partial failures beyond 'todo o nada' or what is returned, but the behavioral picture is strong.

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, zero filler, ordered from what it does to the limit, the atomicity caveat, the validation path, and the publish gate. Everything is front-loaded.

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 5-parameter bulk-creation tool with a deeply nested lessons array and no output schema, the description covers limits, atomicity, validation and publishing. Only the return behavior (e.g., created lesson identifiers) is unaddressed, which is a minor gap.

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 description coverage is 40%, so the description must compensate, and it does for the two behavior-bearing flags: dry_run as a validation pass and publish as the draft-to-live switch with a confirmation caveat. The lessons structure (quiz, tarjetas) is named but its sub-field semantics are left entirely to the schema.

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 (creates), resource (up to 30 lessons, each with quiz and cards), scope (appended at the end of a module) and mode (single call). This clearly separates it from the single-item siblings create_lesson, add_quiz_questions and add_flashcards.

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 concrete operating guidance: run dry_run=true to validate first, and confirm with the person before publish=true. It does not explicitly name the single-item sibling tools as the alternative for one-off creation, so the when-not-to-use case is only implied.

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