Skip to main content
Glama
Sign In
Chispa MCP

Chispa MCP

by jeffercbs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Activar el curso elegido

activate_trial_course

Grant full access to a course selected by a trial user; confirm the course choice with the person before proceeding.

Instructions

[Administrador del aula] Da acceso completo al curso que eligió una persona que está en prueba. Confirma con la persona antes de hacerlo.

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

Input Schema

NameRequiredDescriptionDefault
user_idYesEstudiante
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 mutation/safety profile is covered structurally. The description adds the useful behavioral instruction to confirm with the person first, but says nothing about reversibility, what 'full access' entails, or what happens if the person is no longer in trial.

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?

Two short sentences, front-loaded with the actor role and ending with the confirmation requirement. Nothing is padded, though the bracketed role tag is the only structuring element.

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 simple two-parameter mutation with a fully documented schema and annotations covering the safety profile, the description supplies purpose plus a confirmation precondition. Only the post-activation effect (what access is granted, what errors occur for non-trial users) is left unspecified, which is a modest gap with no output schema to compensate.

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 100% with both UUIDs documented (Estudiante, Aula), so the schema does the heavy lifting. The description refers to the student and the chosen course only implicitly and adds no format, constraint, or pairing rules beyond the schema — baseline 3 applies.

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 in Spanish: granting full course access to a person who is in trial, plus the actor ([Administrador del aula]). An agent can tell this is not the same as decide_access_request or set_course_grants, though the description never names those siblings explicitly.

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 context is implied well enough — a trial user who has chosen a course — and it adds a real precondition ('Confirma con la persona antes de hacerlo'). However, it gives no guidance on when to prefer this over adjacent tools like decide_access_request or set_course_grants, and no exclusions or failure conditions.

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