Diagnose failed assistant actions across host, MCP tool, backend, and source of record with privacy-conscious evidence, safe replay, and a ticket template.
A customer asks ChatGPT to update an account record. The assistant says the change is complete, but the customer's CRM still shows the old value. A screenshot captures the reassuring response. It cannot show whether the request reached the CRM or what happened when it arrived.
For a plugin that exposes actions through the Model Context Protocol (MCP), that investigation crosses several systems: ChatGPT chooses a tool, the plugin's server processes the call, and a backend service writes to the system that stores the record. Support needs evidence linking the tool invocation to its backend job and the record's current state before it can explain the failure or recommend a retry.
Trace a missing update #
Suppose a customer asks the assistant to change Acme Manufacturing's renewal date to October 31. ChatGPT reports success, but the CRM still shows October 15. The host could have selected the wrong tool, or the tool could have received the right date with the wrong account identifier. The backend might have accepted a job that later failed. A successful change could also have been overwritten by another write.
OpenAI's troubleshooting guide recommends isolating the responsible layer: server, component, or ChatGPT client. For developers escalating an unresolved issue to OpenAI, it calls for server logs, component-console output, the tool-call transcript, the prompt, confirmation messages, and screenshots. Collect only the relevant evidence available to the developer and redact it before sharing. Those records help establish what the customer saw and how the request progressed; the CRM's own state establishes what was saved.
An identifier linking the report to backend work gives support a place to start. In this example, request req_7K2 arrived at 14:03:18 UTC and invoked update_renewal_date, using application tool schema version 2026-09-12. The sanitized arguments show account suffix …821 and date 2026-10-31. The tool returned accepted_async, but its queued job, job_91P, subsequently failed because of a CRM version conflict. A check at 14:05 UTC confirms that the renewal date remains 2026-10-15.
The evidence separates two problems. The queued write failed, and the customer received a completion message for work that had only been accepted. Fixing the CRM conflict addresses the failed write. The tool also needs a way to expose the job's final outcome, and its interaction with ChatGPT needs a test that catches premature success messages.
Record enough to investigate #
The example's identifiers and result categories are application instrumentation. Keep a backend record of the operations the service controls. When a customer has no reference ID, support can start with the customer's authenticated account or workspace, the tool involved, and an approximate time window. Restrict that lookup to records support is authorized to inspect. The OpenAI reference documents conversation metadata that can help correlate calls, but it does not replace application account identity or access checks.
A correlation ID can join the inbound tool call to its backend work and the subsequent record check. Alongside it, store the tool name and the version of its application schema, so an engineer can identify the contract in effect. Record the MCP protocol version separately; it does not identify the release of update_renewal_date. Start and end timestamps establish ordering and help distinguish a timeout from a later completion.
The same record should contain a sanitized summary of the intended operation and its outcome. Categories such as rejected, accepted, completed, timed out, and unknown distinguish an acknowledgement from a completed write. Capture the saved change, queued job state, downstream error class, or result of checking the source record.
OpenTelemetry traces provide an implementation model: spans carry trace and span IDs, parent relationships, timestamps, attributes, events, and status. Context propagation connects work across services. W3C Trace Context defines HTTP headers for passing that context between them. These standards can connect services inside the plugin's infrastructure; continuity through an external host still needs to be verified.
Keep the diagnostic record separate from what the model receives. OpenAI's plugin guidelines limit inputs to data needed for the task and prohibit requesting full conversation histories or raw transcripts as a precaution. Tool responses must exclude diagnostic identifiers and logging metadata unless strictly necessary to answer the user's query. Generate internal correlation at the backend boundary, and expose a customer-safe support reference only when that exception applies.
Existing implementations may also use MCP's legacy logging utility, which sends structured messages with severity, an optional logger name, and JSON data. Clients choose how to display those messages, and the specification excludes credentials, secrets, personal information, and internal details that could aid attacks. The 2026-07-28 revision deprecates this utility; it remains available during the deprecation period. The specification recommends that new implementations avoid it and that existing ones migrate to stderr for stdio or OpenTelemetry for structured observability. Support tickets need similar care: redact free text, retain identifiers only where policy and the investigation permit, and never request API keys, cookies, access tokens, or complete chats.
Reproduce the failed operation #
Repeating a prompt may produce a different tool choice or argument set, or no tool call at all. A useful reproduction therefore starts with the failed operation's contract and sanitized inputs. A test tenant or fixture can preserve their shape without risking another change to the production record.
For the renewal update, check that the schema accepts the date and that the backend distinguishes queue acceptance from job completion. Simulate the CRM version conflict and inspect how it reaches the result the model receives. OpenAI's plugin guidelines require clear errors or fallback behavior and call for safe retries where possible, with an explanation when repeating a call could repeat its effects.
If the write can finish within the call's timeout, return its confirmed success or failure. For longer work, one application design is to return a pending state with an opaque job handle and expose a read-only `get_update_status` tool. That tool should verify the caller's access to the job and return its current state, including a final outcome when available. The handle belongs in the result only because it is needed to check the requested update. Define the status tool's schema and usage clearly, then test the complete exchange with ChatGPT: a pending job must remain pending in the explanation, and a failed job must not be reported as complete. A changed result format alone does not guarantee the assistant's wording.
Keep that case in the plugin's regression checks. OpenAI's testing guide recommends direct, indirect, follow-up, write, and unsupported requests, recording the selected tool, arguments, result, errors, and confirmation behavior. It says to rerun those checks after changes to tool names, descriptions, schemas, or annotations.
Check the record before retrying #
A timeout leaves the write's outcome unresolved. Cancellation behavior also depends on the protocol revision and transport. MCP's 2025-06-18 lifecycle specification recommends configurable request timeouts and a cancellation notification when a response does not arrive. In the 2026-07-28 cancellation specification, Streamable HTTP clients cancel by closing the response stream, while stdio clients send notifications/cancelled. A cancellation notification can still arrive after completion or refer to work that cannot be cancelled. Neither a timeout nor a cancellation request establishes that a downstream write was rolled back.
For the renewal update, read the CRM record by ID and compare its current value and version with the intended change. If the date already matches, report that observed state without claiming which request caused it, and avoid a duplicate write. If it differs, confirm that the original operation is no longer in flight before retrying. Where the backend supports it, reuse the original idempotency key or make the retry conditional on the record version just read. An application idempotency key identifies one intended action across retries. Scope it to the authenticated account and operation, retain it for a documented retry window, and enforce deduplication at the write boundary. Repeated attempts with that key should return the existing operation's state or result; reject reuse with different inputs. A separately authorized action needs a new key, even if its inputs match an earlier one. After the key expires, reconcile the record before deciding whether another write is safe. MCP request IDs serve a different purpose: the 2026-07-28 protocol changes require a new request ID when reissuing a request after a broken Streamable HTTP response stream. That new ID does not make a repeated application write safe.
An unresolved write needs a named engineering owner while support manages the customer conversation. In this case, the update can explain that the request reached the service at 14:03 UTC, the CRM rejected a conflicting write, the renewal date remains October 15, and no retry has occurred while the state is under review.
A ticket template can preserve that evidence through the handoff:
Customer-visible report:
Customer account or workspace (verified internal reference):
Approximate time and timezone:
Plugin and tool name:
Support reference or request ID (if shown):
Expected source-of-record state:
Observed source-of-record state:
Confirmation shown to customer:
Sanitized arguments (no credentials or full chat): Result category and backend outcome:
Reconciliation completed? yes / no / unknown
Retry attempted? yes / no; idempotency protection:
Current owner and next customer update: