MCP server for AuthLoop — hand off OTP, captcha, and password challenges to humans
Two tools with well-structured schemas and detailed descriptions. authloop_to_human has comprehensive parameter documentation with nested context object and enum constraints (blocker_type). authloop_status has minimal input but clear blocking semantics. Both descriptions exceed 100 chars and explain WHEN/WHY to use. However, output schemas are not explicitly documented in the source code provided, only inferred from descriptions. Tool names use verb_noun pattern (authloop_to_human, authloop_status) but lack the standard action verb prefix (send_, wait_) that would improve LLM parsing. No error handling guidance visible in descriptions.
Wait (block) for the active AuthLoop session to reach a terminal state. Call this AFTER authloop_to_human and AFTER showing the session_url to the user. BLOCKS for up to 10 minutes (default session TTL) until the user resolves, cancels, or the session times out. Returns one of: resolved, cancelled, timeout, error. Sends progress notifications while waiting (clients can show 'waiting for user…' UI). Honors client cancellation — if the client aborts the request, the session is cancelled.
Hand off an authentication challenge (login, OTP, CAPTCHA, password, security question) to a human who solves it remotely on their phone or another browser. USE WHEN: you encounter ANY auth wall during browser automation. Don't ask the user to type credentials in chat — call this tool instead. RETURNS: a session_url. SHOW THIS URL TO THE USER IMMEDIATELY (in your reply, in chat, wherever you communicate with them). YOU MUST call authloop_status immediately after this tool, in the same turn. Skipping it will orphan the session and the user's work will be lost. REQUIREMENT: a CDP-enabled browser. Pass cdp_url (get it from chrome-devtools MCP, Playwright/Puppeteer wsEndpoint, or chrome --remote-debugging-port=9222), or set AUTHLOOP_CDP_URL env var.
Output schemas not documented. Descriptions mention return values (session_url, terminal states) but no formal schema definition visible in source. LLMs cannot plan downstream tool calls without knowing response structure.
Tool names lack standard action verbs. 'authloop_to_human' and 'authloop_status' are domain-specific but do not start with send_, wait_, or check_. LLMs rely on verb prefixes to infer intent before reading descriptions.
No error handling guidance in descriptions. authloop_status blocks for 10 minutes but descriptions do not explain what to do if timeout occurs, how to retry, or whether the session can be recovered. Agents need recovery paths.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2025-06-18+ | v2 |
authloop_to_human description includes procedural instructions ('YOU MUST call authloop_status immediately after') rather than declarative tool semantics. This is prompt-engineering leakage, the tool should be self-contained; orchestration logic belongs in the agent's planning layer.
context parameter in authloop_to_human is optional object with optional nested fields, but no guidance on which combinations are valid or recommended. Agents may omit all context fields, reducing UX clarity for the human solver.