Skip to main content
Glama
Sign In
Chispa MCP

Chispa MCP

by jeffercbs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Cargar tarjetas de repaso

add_flashcards

Adds up to 200 flashcards to a classroom lesson in one all-or-nothing call, accepting JSON or line-based text and optionally validating with dry_run before saving.

Instructions

[Equipo del aula] Carga tarjetas de repaso en una lección (hasta 200 por llamada). Envía cards (JSON) o cards_text (una por línea: «anverso | reverso»). Todo o nada; dry_run=true valida sin guardar. Quedan visibles en la lección y en el mazo del curso.

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

Input Schema

NameRequiredDescriptionDefault
cardsNo
dry_runNo
cards_textNoTexto compacto, una tarjeta por línea
session_idYesLección
classroom_idYesAula

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the safety profile (not read-only, not destructive, closed-world). The description adds real behavior beyond that: all-or-nothing atomicity ("Todo o nada"), a 200-card cap, a non-persisting validation mode, and the downstream effect that cards become visible in both the lesson and the course deck.

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 distinct information: scope, input modes, atomicity/validation, and resulting visibility. The batch limit is front-loaded and there is no filler or repetition of the title.

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 mutation with no output schema, the description covers input formats, limits, failure semantics, and persistence effects, which is enough to invoke it correctly. It does not say what a dry_run result or partial validation error looks like, which would fully close the loop.

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 60%, and the description compensates by explaining the two mutually exclusive input shapes and the exact line syntax for `cards_text` ("anverso | reverso"), a separator the schema does not document. It also defines what dry_run=true does, though it leaves the required classroom_id/session_id pairing implicit.

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 and resource ("Carga tarjetas de repaso en una lección") plus a batch scope of up to 200 per call, which implicitly separates it from the single-card sibling save_flashcard. An agent can tell what this does and that it is a bulk-load operation without opening the schema.

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 clear operational routing: send `cards` (JSON) or `cards_text` (one per line), and use dry_run=true to validate without saving. It does not explicitly contrast with save_flashcard or state when a single-card call is preferable, so it stops short of naming alternatives.

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