Skip to main content
Glama
Sign In
Educa Navarra

Educa Navarra

by vTanco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Iniciar sesión en Educa

educa_login
Read-only

Opens Educa in the teacher's browser and initiates sign-in, using saved credentials when available or waiting for manual Educa, Cl@ve, or certificate login.

Instructions

Abre Educa en una ventana de navegador del ordenador del profesor e inicia sesión. Si el profesor ha guardado sus credenciales en el fichero local de credenciales, el formulario se rellena solo (un único intento); si no, espera a que inicie sesión él mismo (usuario de Educa, Cl@ve o certificado). La contraseña nunca pasa por el modelo. Si ya hay sesión (el perfil del navegador la recuerda), vuelve enseguida.

Llámala antes que cualquier otra herramienta. Avisa al profesor de que debe iniciar sesión en la ventana que se abre.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "educa_login"
  }
}

Input Schema

NameRequiredDescriptionDefault
wait_minutesNoMinutos máximos de espera al login manual (por defecto 5)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only supply readOnlyHint and openWorldHint, so the description carries most of the burden and does so well: it discloses the single auto-fill attempt, the fallback to human interaction, that the password never passes through the model, that an existing browser-profile session returns immediately, and the side effect of opening a window the teacher must act in. These are exactly the operational traits an agent needs and none are derivable from the annotations.

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?

The purpose and the ordering constraint are front-loaded in the first and second sentences, and every following sentence carries distinct operational information (auto-fill attempt, password handling, session reuse, teacher notification). There is no filler or restatement 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?

With no output schema and only one optional parameter, the description covers the important ground: it is interactive, it may block on a human, and it is a prerequisite for the other tools. The one gap is failure behavior — what the agent sees if the wait expires or the login fails — which matters for a blocking, human-in-the-loop tool.

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% and the single wait_minutes parameter (0.1–15, default 5) is fully documented in the schema. The description only implies waiting exists ("espera a que inicie sesión él mismo") without tying it to the parameter, so it adds little beyond what the schema already provides — the baseline 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?

"Abre Educa en una ventana de navegador del ordenador del profesor e inicia sesión" names a specific verb and resource, and the rest of the description separates this tool from the rest of the educa_* family by explicitly stating it must run before any other tool. The description also distinguishes its two internal modes (auto-fill from a local credentials file vs. manual login), so an agent understands exactly what it gets.

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?

"Llámala antes que cualquier otra herramienta" gives an unambiguous ordering rule, and the description names the accepted manual login methods (usuario de Educa, Cl@ve o certificado) plus the operator instruction to warn the teacher. It stops short of naming any sibling (e.g. educa_status) as the alternative for checking whether a session already exists, so it is strong but not fully exhaustive on 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