Prompting Guide
Prompt patterns that respect rate limits, keep the blast radius small and keep the person in view when an LLM drives the MCP server.
MCP gives an LLM real levers on a project record. Good prompts respect rate limits, keep the blast radius small, and let the person see what is happening. Bad prompts either over-invoke tools or get stuck in loops asking for confirmation.
Ground first
Tell the assistant what universe it is in before asking for action:
Call
get_me, then loadzusegenius://enums/abilityand tell me what this token can and cannot do before we start.
An agent that knows the team it is scoped to and the abilities it holds does not guess at a project it cannot see or a tool it cannot call.
Name the project by its key
Every project has a key, such as CRM, which prefixes every reference inside it (CRM-142). Prompts that name the project once up front are far more reliable than prompts that describe it:
Work on project CRM for the rest of this conversation. First, tell me its status, health and who leads it.
This prevents the assistant from silently switching projects mid-chat, which is the most common source of confusion.
Scope the token narrowly
A personal access token limited to project:view-any, project:view and activity:read answers most "what is going on" questions. Do not hand it write abilities unless the prompt explicitly involves writes; mint a second token instead. An OAuth connection carries your whole reach, so give it tasks you would do yourself.
Use the assistant for aggregations
The server surface is low-level. The assistant's value is combining tools:
For each project in development, read its activity log for the last day and tell me which projects had no change at all.
That becomes: list_projects with status: in_development → iterate → get_activity_log per project → compare → render.
Avoid unbounded loops
When you ask "find every X", cap it:
List up to 50 webhook deliveries that failed today.
Lists page at up to 100 rows and the activity log at up to 200 entries, so an overly literal agent that is not capped walks every page before answering.
Drive writes through previews
Run a write through a dry-run pattern first:
Register a webhook endpoint for every project event at
https://hooks.example.test/zusegenius, named "Delivery board". Show me the exact arguments you would send, but do not execute yet.
Then:
OK, go ahead.
Tools that change data are marked destructive, so the client asks you to confirm before running them in any case; the preview makes sure what it asks about is what you meant.
Reference
The full ability catalog and tool list are at abilities and the tools reference.
How is this guide?
Last updated on