MCP server that executes tasks within secure GoLogin browser sessions, preloading and saving cookies while leveraging AI agents for automated browser automation
Single tool 'run_task' has significant structural and documentation deficiencies. Tool is registered with a schema but critical parameter descriptions are missing entirely. The schema object shows properties (profile_id, task, max_steps) but only the top-level tool has a description, individual parameters have no descriptions whatsoever, violating the baseline that 100% of A+ tool params must be described. The tool description is adequate (140 chars, within 10-1024 range) but parameter documentation is completely absent. Input schema lacks type specifications beyond the object level for individual properties, falling short of JSON Schema best practices. No output schema is documented. Error handling in the code returns generic ValueError messages with minimal guidance for LLM recovery. No structured output schema definition. This server exhibits the hallmarks of a rapid prototype rather than production-grade tooling.
Executes a specified task within a secure GoLogin browser session. Preloads cookies before execution and saves them to the cloud upon completion. Returns the actions performed during the session.
All input parameters lack descriptions. profile_id, task, and max_steps have no descriptions in the schema, violating the baseline that 100% of A+ tools must describe every parameter.
Input schema missing type specifications for individual properties. The schema declares properties but does not specify type:'string' or type:'number' for profile_id, task, or max_steps. JSON Schema is incomplete.
No output schema documented. The tool returns JSON-serialized agent history via TextContent, but the response structure is not documented. LLMs cannot plan downstream data extraction without knowing the output shape.
Credentials (LLM_API_KEY, GOLOGIN_API_KEY) are hardcoded via environment variables without secret injection pattern enforcement. The code checks os.getenv() directly in the handler, exposing credential access paths.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | - | v1 |
No parameter constraints or enums. 'max_steps' accepts any number; no min/max bounds documented. LLMs can pass 0, negative, or absurdly large values (e.g., 1000000) without validation.
Vague tool name 'run_task' lacks action verb specificity. Does it execute, simulate, schedule, or queue a task? Compare against baseline naming: get_, create_, update_, delete_, search_, list_, send_. 'execute_browser_task' or 'run_gologin_task' would be clearer.
Error messages are generic and non-recoverable. 'Error processing task: <str(e)>' tells the LLM nothing about whether to retry, call a different tool, or abort. No error classification (retryable vs. fatal) or recovery guidance.