List all testing-platform projects visible to the configured user. Use this when you don't know the project id, or to disambiguate a project name.

Resolve a free-text project name (e.g. "panda eats") to its id. Use before any other tool that takes a project, unless you already have the numeric id.

List issues (cards) in a project, optionally filtered. By default returns ACTIVE issues only (new / in_progress / in_review). Set include_archived=true (or status=done/wont_fix) to look at the Archive. Result is paginated; use limit/offset to walk it.

Read a single issue's full detail (description, status, priority, reporter, attachments, counts).

List comments on an issue, oldest-first.

Fetch a screenshot or image attachment uploaded to an issue and return it inline so you can actually SEE the picture. Call this after get_issue whenever the reporter said 'see screenshot', the description references a visual problem, or you need to confirm a UI bug visually before commenting.

Pass the url exactly as it came back in get_issue's attachments array. Only attachments served by this testing platform are allowed; arbitrary external URLs are refused.

Create a new issue in a project. Lands in the New column by default. Use to file bugs you've found, follow-ups from a conversation, etc.

AUDIENCE: titles and descriptions are read by non-developer testers (restaurant staff, project owners). Write them in plain English. Describe what the user sees and what's wrong, not the underlying mechanism. Skip jargon like 'NullReferenceException', 'CORS', 'state hydration', 'race condition', stack traces, or code snippets unless the reporter literally pasted them. Prefer 'The order screen freezes when you tap Add Item twice quickly' over 'POST /orders 500: race in optimistic update'. If technical detail is essential, put it at the bottom under a 'Technical notes' heading so the lay reader can skim past it.

Post a comment on an issue. Real-time, visible to anyone watching the board.

AUDIENCE: testers and project owners (restaurant staff, not developers) often read these. Write in plain English. Avoid stack traces, code, error codes, framework names, and acronyms unless the conversation is already deep in technical territory. Prefer 'I checked the login page; the button still doesn't respond on first tap. I think it's because the page hasn't finished loading yet.' over 'Confirmed: event handler is racing the React hydration boundary.' If you must mention something technical (an error message, a file path), put it in a single short line at the end so non-technical readers can stop earlier without losing the gist. Be specific (what you checked, what you found) but concise. These threads can get long.

Patch fields on an existing issue. Use to change status (move it across columns), reprioritize, retitle, etc.

STATUS CHANGES: moving a card to in_progress (you're picking it up to work on) or in_review (it's ready for the reporter to verify) is part of the normal triage flow. Just do it when it's warranted; you do not need to ask the user for confirmation first. The same goes for moving a stalled card back to new.

When NOT to move silently: terminal states. Moving an in_review card to done / wont_fix is blocked server-side unless the reporter has signed off (this is intentional). For human reporters, post a comment asking them to confirm. For service-account reporters (e.g. yourself), use a non-terminal status or ask the developer.

AUDIENCE: when editing title or description, the same plain-language rules from create_issue apply (non-developer testers read these too). Don't rewrite a reporter-friendly title into a developer-friendly one.