get_changes

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose the key non-obvious trait: results are relative to the previous call within this process, making the tool stateful. It does not disclose what the first call returns, whether the baseline resets or persists across sessions, or how large a window the diff covers, which are the questions an agent actually needs answered before relying on it.

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?

Two short sentences, zero filler. The scope qualifier ('since the previous call in this MCP process') is front-loaded before the payload list, and the second sentence adds the polling instruction without repetition.

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?

For a zero-parameter tool with no annotations and no output schema, the description does reasonable work by naming the delta categories and the stateful baseline. The critical gap is first-call behavior and baseline lifetime, which an agent must know to interpret an empty or unexpected diff.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description adds useful framing by naming the three delta categories the caller will receive.

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?

States a specific operation (diff since the previous call in this MCP process) and enumerates the payload: stockpile deltas, squad health changes, hostile count change. An agent can distinguish it from snapshot-style siblings like get_state or get_squads_report by the word 'diff' and 'deltas', though no sibling is named explicitly.

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?

'Call repeatedly to watch the settlement' gives an implied polling use case, so an agent knows this is for monitoring change over time rather than initial inspection. However, it never states when to prefer this over a full-state call, nor what to do on a first call when no prior baseline exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.