Skip to main content
Glama

iniciar-sesion

Opens a Chromium browser on the elempleo login page for manual sign-in, then saves session cookies to the MCP data folder and closes the window.

Instructions

Abre un navegador basado en Chromium (Chrome, Edge, Brave o Chromium) en la página de inicio de sesión de elempleo para que el usuario entre a mano (hay reCAPTCHA y verificación en dos pasos). Al detectar la sesión guarda las cookies en la carpeta de datos del MCP y cierra la ventana.

Input Schema

NameRequiredDescriptionDefault
espera_max_segundosNoTiempo máximo de espera (por defecto 300 s).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that a visible browser window opens, that human interaction is required, and that cookies are persisted to the MCP data folder as a side effect. It omits what happens when espera_max_segundos is exhausted (failure mode, whether the window is left open) and whether the call blocks until detection.

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?

Two sentences, both load-bearing: the first establishes the action and the manual-interaction constraint, the second establishes the completion side effect. The most decision-relevant constraint (manual login required) 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 tool with no annotations and no output schema, the description covers the essential flow and the persistent side effect. The remaining gap is timeout behavior and what the agent gets back on success vs. timeout, which matters for an operation that can run up to 15 minutes.

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 the single parameter (espera_max_segundos, default 300, range 30-900) is fully documented in the schema. The description adds nothing about the timeout parameter or what reaching it means, so the 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 — opens a Chromium-based browser at the elempleo login page — plus the outcome (saves cookies, closes window). An agent can tell what it does immediately, but it never names the sibling estado-de-sesion, which is the natural adjacent tool, so sibling differentiation is left implicit.

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 parenthetical '(hay reCAPTCHA y verificación en dos pasos)' implies why this tool exists — manual login is unavoidable — which gives implied usage context. However there is no explicit 'use this when not authenticated', no 'check estado-de-sesion first', and no stated conditions under which the tool should be avoided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.