Inputs
| Field | Type | Description |
|---|---|---|
url | string | The URL you want to test. Supports localhost and any valid URL. |
messages | array | Full conversation history. Each entry has role (user or assistant) and content (string). Append each new message and resend the whole array on every call. |
Output
The assistant’s next response. Includes aisReadyToTest boolean and, once the scenario is finalized, a testConfig with the generated scenario string.
The relay rule
This is important — the MCP client must not answer the assistant’s questions on your behalf. When the assistant asks “What does success look like?”, Cursor must show you the question verbatim and wait for your answer. Only words you actually typed should appear asrole: "user" messages.
If you notice the client inventing answers or skipping your input, stop it and tell it to relay the assistant’s question back to you.
Typical loop
- Client calls
chat_scenariowithrole: "user"saying what you want to test. - Assistant replies with a clarifying question.
- Client displays the question to you verbatim.
- You answer.
- Client appends
role: "user"androle: "assistant"messages to the history and calls again. - Repeat until
isReadyToTest: true. - Client shows you the final scenario for approval.
- On approval, client calls
run_usability_testwith the scenario astask.
When to use it
Whenever you want Cursor to help you build a scenario — anytime you’re about to kick off a test and don’t have an exact scenario in mind. Even if you do, running this tool gives you a sharper, more testable version of your idea.Example prompt in Cursor
“Help me test the checkout flow at http://localhost:3000/checkout. I want to make sure the guest checkout path works.”
Cursor will call chat_scenario and start the Q&A with you.