Verified against Cursor · 2026-08-04
Route a Cursor Agent task through a connected MCP server instead of letting it guess at an API
A task brief that names the specific MCP server and tool Cursor's Agent mode should call for a task that touches an external system, with an explicit fallback rule for when the tool's response doesn't match what was expected, so the agent doesn't silently paper over an unexpected result from a system it can't fully inspect.
The prompt
Ready to copy — highlighted parts are example details you can swap.
This task involves the Linear issue tracker, which is available through the the Linear MCP server MCP server connected to this workspace. Use that connection rather than writing code that calls the external system's API directly from assumptions about its shape.
TASK
When a PR is merged to main, create a follow-up Linear issue in the "Tech Debt" project referencing the PR number, tagged with the "cleanup" label.
MCP TOOL(S) TO USE
create_issue and list_labels from the Linear MCP server.
EXPECTED RESPONSE SHAPE
create_issue should return { id, identifier, url } for the newly created issue.
RULES
- Call the named MCP tool(s) rather than hand-writing an HTTP request or SDK call to the Linear issue tracker yourself, even if you're confident you know its API — the MCP server's tool definitions are the source of truth for what's actually callable and what it actually returns right now, not your general knowledge of the service.
- If a tool call's response doesn't match EXPECTED_RESPONSE_SHAPE, stop and report the actual shape you got rather than reshaping your code to fit what you expected — the mismatch is information about the real API, and silently normalizing around it hides that from whoever reads this later.
- If the MCP server doesn't expose a tool that covers part of this task, say exactly what's missing rather than falling back to a direct API call to fill the gap without flagging that you did.
- Do not hardcode a credential, endpoint, or API key anywhere in the code you write for this task — if the MCP connection needs configuration to work, name what's missing rather than working around it with an inline secret.
When done, list every MCP tool call you made, what you asked for, and what came back, so the actual interaction with the Linear issue tracker is auditable without re-running the task.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
An agent asked to "create a Linear issue" without an MCP connection named will write code against its own general knowledge of Linear's public API, which is frequently stale relative to the actual current API version, and even when accurate requires the agent to also handle auth, rate limits, and error shapes it has no live visibility into — versus a connected MCP server, which exposes a small set of already-authenticated, already-scoped tools with their own defined input/output schema that the agent can call directly and get a real response from, not a guess about what the response should look like. Naming the specific MCP_SERVER_NAME and MCP_TOOLS_TO_USE up front removes the agent's discretion to choose between "call the tool" and "write a direct API call" — left to its own judgment, a model will often default to writing code, since that's the more familiar and more thoroughly represented pattern in its training data, even when a live tool call would produce a more accurate and more current result with far less code to get wrong. Requiring a stop-and-report on any response that doesn't match EXPECTED_RESPONSE_SHAPE matters because an MCP tool's actual behavior is something the agent discovers live, and its default instinct facing an unexpected shape is to write defensive code that quietly handles the mismatch — optional-chaining around a missing field, a fallback default value — which resolves the immediate error but hides a real signal that the tool's contract has changed or was misunderstood, information that's far more useful surfaced than silently absorbed. Requiring an auditable log of every actual call and response gives you something no code review of the resulting diff alone would show: not just what code was written to call the external system, but what the external system actually said back during this specific run, which matters most exactly when something about the integration behaves unexpectedly weeks later and the original interaction needs to be checked against what was assumed at the time.
Verified against
Cursor 2.2 · 2026-08-04
Changelog
- 2026-08-04 — Initial publish, verified against Cursor 2.2 Agent mode with a connected MCP server.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
