execute_delta_query

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

Annotations indicate read-only, idempotent, and non-destructive operations, which the description doesn't contradict. The description adds valuable context beyond annotations: it explains the tool's behavioral trait of tracking 'incremental changes' and being for 'efficient synchronization,' which helps the agent understand its role in change tracking workflows. However, it doesn't detail rate limits, auth needs, or response formats, keeping it from a 5.

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?

The description is a single, efficient sentence that front-loads the core purpose without any wasted words. Every part of the sentence ('Track incremental changes...', 'using delta queries...', 'for efficient synchronization') contributes directly to understanding the tool's function and context, making it highly concise and well-structured.

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?

Given the tool's complexity (delta queries for synchronization), annotations cover safety (read-only, idempotent), and schema covers parameters fully, the description provides adequate context. It explains the high-level behavior and use case, which is crucial for an AI agent. However, without an output schema, it doesn't describe return values or pagination, leaving a minor gap that prevents a perfect 5.

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?

Schema description coverage is 100%, so the schema already documents both parameters (resource and deltaToken) well. The description doesn't add specific syntax or format details beyond what the schema provides, such as examples of resource paths or delta token usage. It implies parameter usage ('using delta queries') but doesn't enhance the schema's information, meeting the baseline of 3.

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?

The description clearly states the tool's purpose: 'Track incremental changes to Microsoft Graph resources using delta queries for efficient synchronization.' It specifies the verb ('track'), resource ('Microsoft Graph resources'), and method ('delta queries'), making it distinct from siblings like execute_graph_search or search_audit_log. However, it doesn't explicitly differentiate from execute_graph_batch, which might also handle Graph operations, so it's not a perfect 5.

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?

The description implies usage context ('for efficient synchronization') and suggests this is for incremental updates rather than full queries. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like execute_graph_search or manage_graph_subscriptions, nor does it mention prerequisites or exclusions. This leaves some ambiguity for an AI agent.

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