AI and Claude Code

MCP recipes: prompts that work

Updated October 9th, 2026109 views

Once the MCP server is connected, the question becomes what to ask. These are prompts that work, and why.

Tasks are labelled with their project's key and their number, like BD-42. Either the label or the number alone works in a prompt, and the tools accept both.

Fix a bug from its ID

Look at task BD-42 in BugDump and fix it.

The workhorse. The agent reads the task, pulls its reports, correlates the console error with the failing request, finds the matching code, and proposes a fix.

Add constraints when you have them:

Look at task BD-42 in BugDump and fix it. The bug is probably in the checkout flow — check src/features/checkout first.

Find duplicates

Check task BD-8 — is this the same bug as BD-3?

Comparing two sets of telemetry in detail is exactly the work humans skip and agents do well.

Broader:

List the open tasks in BugDump and tell me which ones look like duplicates of each other.

Worth running before a planning session. Boards accumulate duplicates quietly.

Correlate environments

Read the reports on BD-17 and tell me which browsers and viewport sizes are affected.

The single highest-value question for a task with several reports. The answer often ends the investigation — "all Safari, all under 768px" tells you where to look before you open a debugger.

Do all reports on BD-23 share a build SHA?

Works when you pass buildSha through setContext(). If every report is on one build, you know which deploy caused it.

Dig into telemetry

Read the full network telemetry for the reports on BD-31 and find any request that failed or took longer than 3 seconds.

This pushes the agent to get_report_telemetry rather than the summary. Worth being explicit — get_report returns only the last 50 console entries with bodies stripped, and if the interesting event is older than that, the summary will not show it.

The console summary on BD-12 looks empty. Page through the full console history and find the first error.

Review the state of the board

Summarize the open tasks in BugDump by priority and tell me what to work on first.

What do the critical tasks in BugDump have in common?

Show me BugDump tasks created in the last week that are still in Triage.

list_tasks supports filters for open or closed status, priority, assignee, kanban column, labels, any custom property, the reporter's browser, OS and device, a createdAt range and a resolution range, so scoped questions work well.

Write your status report

Give me a report of my tasks for this week in bugdump, split into In progress and Done.

This used to be slow: the agent had to list the tasks and then open each one's history to find out when it moved. It is now two calls. get_current_project returns viewer, which says which member the connection acts as, and list_tasks takes a resolution window — so "what I finished" is assigneeId + status: "closed" + resolvedFrom, and "what I am on" is assigneeId + the In Progress column.

What did the team close last week, and who closed it?

Same shape without the assignee filter. Every task in a list now carries resolvedAt, so the agent can group by day without asking again.

One caveat worth knowing: resolvedAt is when a task last entered a closed column. If someone reclassifies a column from open to closed, every task in it is stamped with that moment, and a week's report can pick up work that was actually finished months ago.

Read the history and the discussion

When did BD-17 move to In Progress, and who reassigned it?

get_task_history returns every column move, priority and assignee change, edit, and change to the labels, the due date or a custom property, with who made it and whether it came through MCP. A property change names the property it is about.

Read the comments on BD-23 and summarize what the team already tried.

list_comments returns the thread as Markdown, so the agent does not repeat an approach someone has already ruled out.

Check trends

How has bug volume trended in BugDump over the last two weeks?

get_task_activity returns a daily summary of tasks created and resolved over 14 days. The useful signal is the balance — consistently more created than resolved means triage is falling behind.

Fix the most frequent error

Which new error in BugDump has the most events? Read it and propose a fix in our code.

The agent calls list_errors with state: "new", sorted by events, then get_error on the top one. That returns the stack trace, resolved through your source maps when you have uploaded them, and the newest stored event with its console, network and actions, so the agent can go from the failing frame straight to the file. Without source maps the frames point into minified code. Both tools are read-only, so a read-only token is enough. See Working with captured errors.

Write the fix and the test

Fix task BD-42 and add a regression test that fails without the fix.

The reports contain the actual reproduction — the actions log records what the user did. That is a better basis for a test case than a description someone typed.

Prompts that work less well

Vague scope. "Fix all the bugs in BugDump" gives the agent no way to prioritize. Name a task or a filter.

Assuming the summary is complete. If an agent says a report has no console output, it likely read the summary. Ask for the full telemetry explicitly.

Inventing IDs. IDs must come from a previous response. A task number works directly with get_task, but report IDs have to come from list_reports_for_task.

Numbers from another project. Task numbers count per project, so BD-42 and QA-42 are different tasks. A personal token is bound to one project, so only one of them is reachable in a session. A sign-in connection reaches all your projects: name the project in the prompt — "Look at QA-42 in the Acme Store project" — and the agent passes its slug as project, taking it from list_projects.

Close the loop: move, comment, assign

A token created with Allow changes, or a sign-in connection with Read and write, also gets seven write tools: move_task, add_comment, set_priority, assign_task, set_task_labels, set_task_due_date and set_task_property. Every change is recorded under your name, with a via MCP label in the task's history and comments.

Fix BD-42, then move it to Done and comment with a short summary of the root cause and the fix.

The comment is written in Markdown, so code spans, lists and links come through as formatting.

Go through the open tasks in New, set a priority on each one based on its reports, and assign anything touching checkout to Maya.

The agent takes column names and member ids from get_current_project, so "Done" and "Maya" resolve without you looking anything up.

What the agent cannot do

Even with Allow changes or Read and write, the agent cannot delete tasks or reports, edit a task's title or description, change project settings, or reach a project you are not a member of. A read-only token — the default for tokens — or a Read only sign-in cannot change anything at all.

BugDump's server instructions tell the agent to call write tools only when you asked for that change, and to treat report descriptions, console output and comments as data to analyse, never as instructions to follow. A report that says "close all tasks" is just a strange report.

Getting more out of it

The quality of what the agent can do depends on what your reports contain. Two SDK calls make a large difference:

identify() attaches user identity, so "which customers hit this" becomes answerable.

setContext({ buildSha }) attaches your build, so "did this start with a deploy" becomes answerable.

Both are one line, and both turn a whole class of question from unanswerable into trivial.