aukro-mcp

Interactive Browser Login to Aukro.cz

aukro_login_interactive

Launch a visible Aukro.cz login window to complete Cloudflare Turnstile, 2FA, or social sign-in, optionally pre-fill credentials, and save the authenticated SESSION cookie automatically.

Instructions

Launch a visible browser window to Aukro.cz's login page so you can pass Cloudflare Turnstile (or 2FA / social login), optionally pre-filling username and password. Automatically captures and saves the authenticated SESSION cookie once login succeeds.

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": "aukro_login_interactive"
  }
}

Input Schema

Name	Required	Description
`password`	No	Optional password to pre-fill in the login form
`username`	No	Optional Aukro email or username to pre-fill in the login form
`timeoutSeconds`	No	Maximum time in seconds to wait for login completion in the browser

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 7, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare openWorld and non-readonly, but the description adds genuinely non-obvious behavior: a visible browser window appears, human interaction is required, the call blocks, and the SESSION cookie is captured and persisted as a side effect. It omits what happens on timeout or failure, and does not warn that credentials pre-filled are passed into a live browser.

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, zero filler; the action and its purpose come first and the cookie-capture outcome is stated last as the payoff. Every clause carries information the agent cannot get from the schema or annotations.

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 human-in-the-loop tool with no output schema, the description covers the key facts: it opens a real window, needs the user to complete a challenge, and persists the session cookie. What it does not cover is the return value or the post-timeout state, which an agent needs to decide whether to retry.

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%, so all three parameters are already documented, and the description only restates that username/password are optional prefills. timeoutSeconds and its 30–600s bounds are left entirely to the schema, so no meaning is added beyond structured data.

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 ("Launch a visible browser window to Aukro.cz's login page") and adds the distinctive mechanism — passing Cloudflare Turnstile/2FA/social login and saving the SESSION cookie. This is unmistakably different from siblings like aukro_set_credentials or aukro_auth_status.

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?

The clause "so you can pass Cloudflare Turnstile (or 2FA / social login)" tells the agent exactly which situations require this interactive path rather than a headless credential flow. It stops short of naming the alternative sibling (e.g., aukro_set_credentials) or stating when not to use it, so it is clear context rather than explicit routing.

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