Lightpanda vs Skyvern

Lightpanda

Version 1.0.2 runs locally with no account, and its 32-tool MCP server has typed schemas, an annotation on every tool and guidance to treat pages as untrusted. Telemetry is on by default, the CDP and HTTP MCP servers have no authentication, the cloud documents its token in the URL, and no status page or cloud terms were found.

Skyvern

The hosted MCP server annotates every tool as read-only or destructive and can advertise a 29 or 32-tool subset in place of 114, and the API has a written six-month deprecation policy. Every key and OAuth token carries full organisation authority, with no read-only or scoped credential, and no request rate limits are documented.

Lightpanda

1. Set LIGHTPANDA_DISABLE_TELEMETRY=true in the server's environment if usage data, the IP address and an instance ID shouldn't leave the machine.
2. Treat text from markdown, html, tree and links as untrusted page content, never as instructions.
3. Pass credentials as $LP_* placeholders in tool arguments and call getEnv without a name; naming a variable returns its value.
4. Check httpStatus in structuredContent after goto, since a 404 page or a load timeout is still reported as a successful navigation.
5. Keep lightpanda serve and lightpanda mcp --port on 127.0.0.1 or a Unix socket; neither checks who connects.

Skyvern

1. Connect to https://api.skyvern.com/mcp/x/lean or /x/operate, or send X-Skyvern-Scope, so the client loads 32 or 29 tools. The scope filters the list and does not limit permissions
2. Use a separate Skyvern organisation for each blast radius. Any key or OAuth token can read and write stored credentials and delete workflows
3. Never pass passwords to skyvern_act or skyvern_type. Store them as credentials and call skyvern_login
4. Set max_steps on tasks, or x-max-steps-override on agent runs, to cap credits. A run that reaches the cap ends as timed_out
5. On 503 from POST /v1/run/agents, wait Retry-After seconds. No run was created, so resubmitting is safe