Skip to main content
Glama
corith37

ChatGPT Subscription MCP

by corith37

chatgpt_ask

Ask an OpenAI assistant a question or continue a conversation using your ChatGPT subscription, then poll the returned background job for the answer.

Instructions

Ask the subscription-backed OpenAI assistant a question or continue its conversation. Uses plan limits. Returns a background job; poll chatgpt_job for the answer.

Input Schema

NameRequiredDescriptionDefault
modelNoOptional model ID from chatgpt_status. Defaults to the account default.
promptYesThe complete question, generation prompt, or image-edit instructions.
conversation_idNoContinue a conversation returned by this bridge.
reference_imagesNoAbsolute local paths to PNG, JPEG, or WebP reference images. Only attach files the user intends to share.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover openWorldHint, idempotentHint=false and destructiveHint=false. The description adds genuinely useful behavior not in the annotations: subscription-backed auth, 'uses plan limits' (quota constraint), and the asynchronous contract returning a background job that must be polled via chatgpt_job.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, then the quota caveat, then the async follow-up. Every sentence carries a distinct fact with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an async tool with no output schema, the description supplies the critical missing piece: it returns a job, not an answer, and chatgpt_job is how to retrieve it. Minor gaps remain (whether the job handle is returned inline, whether conversation_id is echoed back), but the agent can call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents prompt, model, conversation_id, and reference_images including the 4-image cap. The description only gesture at the conversation parameter via 'continue its conversation', adding no format or constraint detail beyond the schema — baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ('Ask the subscription-backed OpenAI assistant a question') and adds the continue-conversation mode. It does not explicitly distinguish itself from chatgpt_generate_image, even though reference_images makes that boundary relevant, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the two modes ('a question or continue its conversation') and the follow-up instruction to poll chatgpt_job. There is no explicit when-not guidance or named alternative for image generation versus text prompting, which an agent must infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.