Pixel Bridge MCP — lets Claude Code generate images through your existing ChatGPT / Gemini web accounts via a persistent, manually-authenticated browser session.
Pixel Bridge MCP demonstrates solid tool design with clear naming, comprehensive descriptions, and well-structured schemas. All 7 tools follow verb_noun conventions (generate_image, edit_image, get_generation_status, etc.). Descriptions are detailed and contextual (150-300 chars), explaining not just WHAT but WHEN and WHY. Input schemas use Zod with proper type constraints (enums, regex patterns, min/max bounds). However, output schemas are not formally documented in the code, responses are JSON-serialized JobView objects without explicit schema declarations. Error handling is present but generic (errorResult wraps exceptions). Tool composition is clean: each tool has one responsibility, and job_id chaining enables multi-step workflows. Security is strong: no credentials in parameters, file I/O is sandboxed with overwrite guards, and path traversal is mitigated via saveImage(). Minor gaps: no tool annotations (readOnlyHint/destructiveHint), no pagination (not applicable here), and no explicit recovery guidance in error messages.
Non-destructive check: is the persistent session for a provider logged in and usable? Returns the current URL and a human-readable explanation of what was detected.
Copy a completed job's image(s) to a new location (e.g. to move them out of the temp cache or to share them). Does not re-generate; the job must already be finished.
Edit an existing local image via a logged-in web provider: uploads the image, sends the edit instructions, and saves the edited result locally. Same job semantics as generate_image.
Generate an image via a logged-in web provider (ChatGPT web or Gemini web) and save it locally. Waits inline up to wait_seconds; if generation is still running, returns a job_id to poll with get_generation_status. The MCP does NOT judge quality — after completion, you (the caller) should view the saved file and decide whether to keep it or regenerate with a better prompt.
Generate the same concept with BOTH providers (ChatGPT web + Gemini web) in parallel and save both images locally, so you can visually compare them and pick the winner. Each provider can succeed or fail independently.
Output schemas not formally documented. JobView structure is inferred from code; LLMs cannot see the response schema in tool registration. This violates pattern:tool and pattern:response-shaper, agents cannot plan downstream operations without knowing what fields to expect.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). generate_image and edit_image are destructive (write files); get_generation_status and check_provider_session are read-only. Annotations help LLMs reason about side effects and retry safety.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Check a generation/edit job started by generate_image, edit_image or generate_with_both. Returns status, saved file paths when finished, error details on failure, and recent job logs.
Open a provider's site in a headed browser and wait for you to authenticate manually (credentials, CAPTCHA, MFA — all handled by you, never by this tool). The persistent profile will keep this session for future runs. Timeout is configurable via PIXEL_BRIDGE_LOGIN_TIMEOUT_S (default 5 min).
Error messages are generic (errorResult wraps exceptions as JSON). No recovery guidance. E.g., if provider_login fails due to timeout, the error should suggest 'Increase PIXEL_BRIDGE_LOGIN_TIMEOUT_S or check browser availability.' Pattern: recovery-guide.
provider_login description lacks detail on prerequisites and side effects. Does it require a headed browser? What happens if already logged in? Does it persist the session? Agents need explicit guidance.
No dry-run or confirmation step for destructive operations (generate_image, edit_image, download_generated_image all write files). Agents could accidentally overwrite important files. Pattern: confirmation-request.