Get AppDynamics transaction snapshots

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

With no annotations, the description relies on itself to convey behavioral traits. It discloses capacity limits (cap 100, max 600) and a usage hint, but does not mention whether the operation is read-only, authentication needs, pagination, or response format. It provides some value but not comprehensive transparency.

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 two sentences, front-loaded with the core purpose, and includes key constraints and usage hint. Every word contributes value, making it 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 with 11 parameters and an output schema, the description covers only capacity limits and one parameter's use case. It lacks guidance on common filters or response structure, leaving the agent needing to infer from the schema. It is minimally adequate but not fully complete.

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 description adds meaning for the needExitCalls parameter by linking it to dependency-map analysis, which is beyond the schema. However, with 64% schema coverage, many parameters already have descriptions; the description does not compensate fully for the undocumented ones. It adds moderate value.

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 verb 'Retrieve' and the resource 'slow/error/diagnostic transaction snapshots for an application', making it specific. It also hints at a sibling tool (dependency map) for context, distinguishing its purpose.

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 provides a hint for when to use the needExitCalls parameter for dependency-map analysis, but does not explicitly state when to use this tool over alternatives or when not to use it. This leaves room for ambiguity.

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