Skip to main content
Glama

ask_chatgpt

Send one question and optional PDF through signed-in Chrome to retrieve ChatGPT's answer; continue an existing conversation URL or start a new chat, logging each task locally.

Instructions

Send one question and optional PDF through signed-in Chrome and return ChatGPT's answer.

The question and result are persisted in an ignored local task file. Supply a canonical
https://chatgpt.com/c/... URL to continue an existing conversation; omit it for a new chat.
PDF paths must be absolute and inside the existing ChatGPT bridge's allowed roots.

Input Schema

NameRequiredDescriptionDefault
questionYes
thinking_modeNoprefer_max
attachment_pathNo
timeout_secondsNo
conversation_urlNo
minimum_response_charactersNo

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?

With no annotations, the description carries the full burden and does meaningful work: it discloses that execution happens via signed-in Chrome (an auth/environment requirement), that the question and result are persisted to a local task file (a side effect), and that attachments are constrained to allowed roots. It omits failure/timeout behavior and rate limits.

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

Conciseness4/5

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

Front-loaded with the core action and answer return in the first sentence, then two compact follow-ups on persistence and URL/PDF constraints. No filler, though the persistence note is slightly tangential to invocation decisions.

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

Completeness3/5

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

No output schema and no annotations, so the description must cover behavior and returns. It handles continuation semantics and attachment constraints well, but is silent on three non-obvious parameters (thinking_mode enum, timeout_seconds, minimum_response_characters), leaving an agent unable to reason about latency and answer-completeness controls.

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 0% across 6 parameters, so the description must compensate. It clarifies attachment_path (absolute, inside allowed roots) and conversation_url (canonical https://chatgpt.com/c/... URL, omit for new chat), but leaves thinking_mode, timeout_seconds, and minimum_response_characters entirely unexplained.

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?

Specific verb and resource: 'Send one question ... and return ChatGPT's answer,' with the Chrome-signed-in mechanism named. It implicitly separates itself from the read-only sibling read_chatgpt_conversation by describing both submission and answer retrieval, though it never names that sibling explicitly.

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

Usage Guidelines4/5

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

Gives a clear decision rule for the conversation_url parameter: supply a canonical URL to continue an existing chat, omit it for a new one. It also states the precondition for PDF attachments (absolute path inside the bridge's allowed roots). It stops short of naming alternative tools or exclusions, so no explicit when-not guidance.

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