Skip to main content
Glama
Sign In
Educa Navarra

Educa Navarra

by vTanco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Escribir las notas (sin guardar)

educa_fill_grades
Idempotent

Writes approved grades from a preview plan into Educa gradebook fields for teacher review, skipping rows not marked for writing and leaving Save-button screens unsaved until the teacher confirms.

Instructions

Escribe en los campos de Educa las notas de un plan de educa_preview_grades, solo las marcadas "se escribirá". En pantallas con botón Guardar NO lo pulsa: los cambios quedan en pantalla para que el profesor los revise. En el Cuaderno de aula de Educa-Gestión no hay botón Guardar (cada nota se guarda al elegirla), así que ahí exige confirm_autosave=true. Comprueba antes que la tabla sigue siendo la misma (mismos alumnos) y después relee cada campo.

Úsala solo después de que el profesor haya visto la vista previa y dado el visto bueno.

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": {
      "plan_id": "<plan_id>"
    },
    "name": "educa_fill_grades"
  }
}

Input Schema

NameRequiredDescriptionDefault
plan_idYesplan_id devuelto por educa_preview_grades
include_fuzzyNoEscribir también las filas emparejadas por nombre aproximado (solo si el profesor las ha confirmado)
confirm_autosaveNoObligatorio (true) cuando la pantalla guarda cada nota al elegirla, como el Cuaderno de aula de Educa-Gestión: confirma que el profesor ha autorizado que las notas queden guardadas

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, it discloses the key behavioral split: on Save-button screens changes remain unsaved for teacher review, while on the Educa-Gestión Cuaderno de aula each grade autosaves and confirm_autosave=true is required. It also adds a pre-check (verify the table still lists the same students) and a post-check (re-read each field), which is exactly the kind of context annotations cannot convey.

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?

Content is front-loaded with the core action and the no-Save rule, then the autosave exception, then verification and the usage precondition. It is dense but every sentence carries operational meaning; the closing usage sentence could have been placed earlier for slightly better flow.

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 mutation tool with annotations present and no output schema, the description covers safety-relevant behavior, the autosave exception, and verification steps. The one gap is that it never says what the tool returns after re-reading the fields (confirmation, diff, or errors), leaving the agent to discover the result shape on first call.

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 100%, so all three parameters are already documented in the schema, including the autosave rationale for confirm_autosave and the fuzzy-match caveat for include_fuzzy. The description restates that autosave context rather than adding new semantics such as plan_id lifecycle or fuzzy-match edge cases, so the baseline of 3 applies.

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?

The description states a specific verb and resource (writes grades into Educa fields from a plan produced by educa_preview_grades) and narrows scope to rows marked "se escribirá". It also explicitly separates itself from a save operation by saying it does NOT press the Save button, which distinguishes it from educa_save_grades without needing the sibling 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?

It gives a clear precondition ("Úsala solo después de que el profesor haya visto la vista previa y dado el visto bueno") and a screen-specific rule for when confirm_autosave=true is mandatory. It stops short of naming the follow-up tool the agent should call to actually persist changes on Save-button screens, so the alternative path is implied rather than stated.

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