OpenAI-compatible API proxy and MCP server for ChatGPT web — drives Chrome via CDP
The server implements 16 well-defined tools with mostly complete schemas and descriptions. All tools have explicit input schemas with types and parameter descriptions. Most tool names follow verb_noun conventions (chat_completion, list_models, delete_conversation). Descriptions are generally 50-150 characters, within the 10-1024 character baseline range. However, several quality gaps prevent a higher score: (1) some descriptions lack actionable guidance about when/why to use a tool vs similar ones (e.g., chat_completion vs chat_with_gpt distinction unclear); (2) no documented output schemas for any tool, LLMs cannot predict return structure without explicit documentation; (3) error handling guidance is absent, no indication of retryability, user-fixable vs fatal errors, or recovery paths; (4) security risks around credentials (server connects to ChatGPT web via CDP, but parameter descriptions do not clarify if auth tokens/sessions are server-managed or exposed); (5) composition concerns, some tools could be batched (e.g., delete_conversation takes one ID at a time, no batch delete). The naming is clear (all tools are unambiguous), and parameter constraints are present (enums, defaults, min/max where relevant). This is a solid B-range implementation with good naming and schema coverage but missing the documentation depth required for A-range (output schema docs, error guidance, security clarification).
Archive or unarchive a conversation.
Send a message to ChatGPT and get a response. Continues the last conversation by default, or specify conversation_id to resume a particular conversation.
Send a message to a specific Custom GPT and get a response.
Create a new ChatGPT memory that persists across conversations.
Create a new ChatGPT project with custom instructions and memory scope.
Delete a conversation permanently.
Delete a ChatGPT memory permanently.
No documented output schemas for any tool. LLMs cannot predict return structure, required fields, or chaining IDs. For example, chat_completion should document that it returns {choices: [{message: {content: string}}], conversation_id: string} so agents can pass conversation_id to subsequent calls. This violates the response-shaper pattern.
Destructive tools (delete_conversation, delete_project, delete_memory) lack confirmation or dry-run support. No error guidance (retryable vs fatal). Descriptions do not warn that deletion is permanent or offer recovery paths. This violates the confirmation-request and recovery-guide patterns.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2025-06-18+ | v2 |
Delete a ChatGPT project permanently.
Retrieve the message history of a conversation. Messages are returned oldest-first. Use offset and limit to page through long conversations.
List recent conversations with pagination support.
List all available Custom GPTs that can be chatted with via chat_with_gpt.
List all ChatGPT memories that persist across conversations.
List all available ChatGPT models that can be used with chat_completion.
List all files attached to a ChatGPT project.
List all available ChatGPT projects with their gizmo IDs and custom instructions.
Update the custom instructions for a ChatGPT project.
Tool descriptions for discovery tools (list_models, list_projects, list_gpts, list_memories) do not explain dependency relationships or when they should be called. E.g., list_models should say 'Call this first to discover available model slugs before passing model parameter to chat_completion.' This violates the discovery-tool documentation pattern.
Distinction between chat_completion and chat_with_gpt is unclear in descriptions. chat_completion mentions 'ChatGPT' and chat_with_gpt mentions 'Custom GPT' but descriptions do not explicitly state the difference or when to use each. This violates the name-clarity pattern and creates ambiguity for LLM tool selection.
Credentials and authentication are not addressed in tool definitions. The server uses CDP to control a Chrome browser that connects to ChatGPT web, implying session/auth tokens are managed server-side. However, parameter descriptions do not clarify this or warn that credentials must not be passed as parameters. This creates potential for credential leakage if not clearly documented.
No error handling guidance in any tool description. For example, chat_completion does not document what happens on model errors, rate limits, or network failures. Tools should indicate whether errors are retryable or user-fixable. This violates the error-classification and recovery-guide patterns.
Pagination in list tools is documented (offset/limit), but no indication of total_count, has_more, or next_cursor fields in return values. The description says 'Page through by increasing offset by `limit` each call until has_more is false' but does not show that has_more is actually returned. This forces agents to guess the response structure.
Batch operations are not offered. Agents must call delete_conversation, delete_memory, etc. individually in a loop, wasting tokens and latency. No batch_delete_conversations or similar variants exist. This violates the composition pattern recommendation for batch variants.