aukro-mcp

Configure Aukro Session Cookies or OAuth2 Tokens

aukro_set_credentials

Idempotent

Supply or update Aukro.cz cookies or OAuth tokens at runtime without restarting the server, then immediately verify the credentials against Aukro.cz.

Instructions

Supply or update Aukro.cz authentication credentials at runtime without restarting the MCP server. Supports: (1) full cookieHeader copied from browser DevTools, (2) individual sessionCookie (SESSION cookie value from aukro.cz), (3) OAuth2 accessToken and/or refreshToken, and (4) optional username/password for interactive login pre-filling. Immediately verifies the credentials against Aukro.cz.

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_set_credentials"
  }
}

Input Schema

Name	Required	Description
`persist`	No	When true, saves cookies/tokens to ~/.config/aukro-mcp/credentials.json (0600 permissions)
`password`	No	Optional password to store in memory for `aukro_login_interactive`
`username`	No	Optional username/email to store for `aukro_login_interactive`
`xsrfToken`	No	Optional value of the `XSRF-TOKEN` cookie
`aukroToken`	No	Optional value of the `aukro-token` UUID cookie
`accessToken`	No	OAuth2 Bearer JWT `access_token`
`cookieHeader`	No	Full `Cookie` header string copied from browser DevTools on aukro.cz (e.g. 'SESSION=...; aukro-token=...; XSRF-TOKEN=...')
`refreshToken`	No	OAuth2 `refresh_token` (enables automatic passwordless/captchaless token renewal)
`sessionCookie`	No	Value of the `SESSION` cookie from https://aukro.cz

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 7, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Beyond the annotations (idempotent, non-destructive, open-world), the description discloses two real behaviors: values are verified against Aukro.cz immediately (an outbound call that can fail or be slow), and the schema's persist flag writes to a config file at 0600. It does not say what happens when verification fails — whether credentials are retained, rolled back, or an error is raised — nor that a password is held in memory.

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?

The purpose and the runtime/no-restart benefit are front-loaded in the first sentence, followed by a numbered enumeration of accepted inputs. Every sentence carries information; the only minor inefficiency is that the four-mode list partly restates parameter names documented in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, all-optional tool with no output schema, the description covers inputs well but leaves the outcome underspecified: it says credentials are 'immediately verified' without describing the result shape (success/failure, diagnostic message, current user). An agent cannot predict the return value or how to react to a failed verification.

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 every parameter is already documented inline; the description's added value is modest. It does add grouping that the flat schema lacks, presenting cookieHeader, sessionCookie, OAuth tokens, and username/password as four alternative input modes, but it does not clarify precedence when multiple modes are supplied together.

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?

The description uses a concrete verb and resource ('Supply or update Aukro.cz authentication credentials at runtime') and enumerates the four accepted credential forms, which lets an agent distinguish it from aukro_auth_status (read-only check) and aukro_login_interactive (interactive login). Sibling differentiation is present but only implicit — it never names those tools as alternatives.

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?

It states the key context that credentials are set 'without restarting the MCP server,' which implies when to reach for it (runtime re-auth instead of redeploy). However, there is no explicit guidance on when NOT to use it, no statement about which of the four modes to prefer, and no pointer to aukro_auth_status to check whether credentials are already valid.

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