Prompts Reference

MCP prompts are ready-made instructions a server offers to your agent. The model decides when to call a tool; you decide when to run a prompt, and your host adds its messages to the conversation.

The Scenario server registers one prompt, diagnose, which turns a failing or surprising session into a report for Scenario support.

diagnose

Recap your Scenario tool calls (inputs + outputs), run diagnostics, and produce a copy-paste report for support.

When to Use It

• A Scenario tool call failed and your agent cannot resolve it. Failed calls start with a line such as ⚠ Scenario error (trace_id: mcpt_…), and the prompt collects those ids for support.
• A call succeeded but the result is not what you expected, and you want Scenario support to look at it.
• Scenario support asks you for a diagnostic report.

Run it in the conversation where the problem happened: the report is built from that conversation's Scenario tool calls.

Running the Prompt

How a prompt appears depends on your host. Hosts that support MCP prompts read the server's prompt list and offer each prompt by name or title, often in a slash-command or prompt menu. Pick diagnose there; it takes no arguments.

If your host does not offer MCP prompts, ask your agent to call the diagnostics_run tool directly. You get the self-test and the trace ids, without the goal recap and tool-call transcript the prompt adds.

What It Asks Your Agent to Do

1. Recap your goal in one or two sentences.
2. Write a chronological transcript of every Scenario tool call in the conversation, with its inputs and outputs. Redaction is minimal: credentials are stripped, base64 and binary data become a placeholder that notes the size, and only long free text is truncated.
3. Collect the real trace ids visible in the conversation, mostly from the ⚠ Scenario error lines on failed calls.
4. When no trace id was seen, estimate how many minutes ago the Scenario activity happened and over what span. The prompt carries the server time of the moment you run it, so the agent can reason about relative timing without a clock of its own.
5. Call diagnostics_run with the observed ids and the timing estimate, using the same team_id and project_id as the calls that went wrong.
6. Assemble one copy-paste report and tell you to send it to Scenario support.

What the Report Contains

• Your goal and the transcript of Scenario tool calls.
• A first-pass diagnosis: authentication, tenant scope, model choice, quota, or a gap between what you expected and what happened.
• The diagnostics_run output, with its self-test result and trace ids. Confirmed ids, seen in the conversation, come first; ids reconstructed from timing appear only as a labelled fallback.

The transcript keeps tool inputs as they were sent, including model, asset, team and project ids and generation parameters. Read the report before you send it.

diagnose and diagnostics_run

The prompt is a set of instructions; the diagnostics_run tool does the live checks. It runs a self-test with your own credentials and names the failing layer:

• auth: the credentials were rejected.
• tenant-scope: team_id or project_id is missing or invalid for an OAuth session.
• api-unreachable: the Scenario API could not be reached.
• healthy: the infrastructure works, so the cause is more likely the model, usage or expectations.

The tool also returns confirmed and candidate trace ids and a markdown report of its own. The prompt builds on it, adding your goal, the tool-call transcript and the agent's first-pass diagnosis, which is why the tool's description recommends the prompt for a full report.

Prompt Text

The message the prompt adds to the conversation, as the server sends it. The server fills in its current time on every run.

You are helping a Scenario MCP user produce a support diagnosis. Current server time: [server time when you run the prompt].

Do the following, then output ONE copy-paste report:

1. Recap the user's goal in 1-2 sentences.

2. Build a chronological transcript of EVERY Scenario MCP tool call in this conversation, with its actual INPUTS and OUTPUTS — as complete as possible (this is the most valuable debugging signal). For each call include: the tool name and order; the full input arguments (keep model_id, team_id/project_id, asset_id, dimensions, seeds, params verbatim); and the output (returned ids, status, and error messages verbatim). Apply only MINIMAL redaction: strip credentials; replace base64/binary with a placeholder noting size (e.g. "[base64 image omitted — ~1.2 MB]"); truncate only genuinely long free text with "…[truncated]". Do NOT drop arguments or results just to be concise.

3. Collect REAL trace ids first: scan the conversation for any "mcpt_" ids visible in the session — primarily the "⚠ Scenario error (trace_id: ...)" lines shown on errors. These are observed/real and take priority over anything reconstructed.

4. If no real ids were seen (e.g. an error-free "bad result" session), estimate the Scenario activity timing relative to the server time above: roughly how many minutes ago it happened and over what span.

5. Call the diagnostics_run tool, passing the real ids as observed_trace_ids and the estimate as activity_age_minutes / activity_span_minutes. Run it with the SAME team_id/project_id used when the problem occurred.

6. Assemble ONE copy-paste report containing: the goal recap, the tool I/O transcript from step 2, your first-pass diagnosis (auth? tenant scope? model choice? quota? expectation mismatch?), and the diagnostics_run output. Lead the trace-id section with confirmed (real) ids; include candidate (reconstructed) ids only as a clearly labelled fallback — never blend the two. Tell the user to paste the whole report to Scenario support.