get_updatesRetrieves recent project activity — plans sent, approvals, payments, stage reviews and change requests — so you can see what happened across projects, newest first.
What happened recently across the person's projects: plans sent, approvals, payments, stages started or sent for review, changes requested.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many, newest first. Default 50. |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description contributes the meaningful scope fact that results span all of the person's projects rather than one, but leaves 'recently' undefined — no time window, no mention that the schema's default caps at 50 newest-first. With annotations carrying the safety profile, this is an adequate but thin addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, and the enumeration of event types earns its space by telling the agent what will appear in the feed. The colon-list structure is readable, though slightly list-heavy for one sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should at least imply the return shape (a chronological list of updates) and the meaning of 'recent'. It hints at a feed via the event enumeration but never states ordering, time horizon, or cross-project scope boundaries explicitly. Adequate for a simple read tool, with a clear gap around the time window.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one optional parameter and the schema documents it fully (min 1, max 200, default 50, newest first). The description says nothing about limiting results or what ordering it uses, so the schema does all the work; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the resource (recent activity across the person's projects) and enumerates the concrete event types it covers — plans sent, approvals, payments, stage transitions, change requests. That is far more specific than the title alone. It stops short of an explicit verb ('returns a feed of...') and does not distinguish itself from siblings such as get_user_activity or get_project_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus get_user_activity, get_project_messages, or get_project_context, all of which plausibly overlap. Nothing about prerequisites, time windows, or whether it can be narrowed to a single project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.