Get Time Tracking Entry

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the specific return fields and the GID source context, but doesn't disclose additional behavioral traits such as rate limits, pagination, or error conditions. Since annotations cover the safety profile, a score of 3 is appropriate: the description adds value but not rich behavioral context.

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-loads the core action ('Get a single time tracking entry by GID'), lists the return fields concisely, and ends with a pointer to the sibling tool. No wasted words; every sentence earns its place.

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?

With high schema coverage, accurate annotations, and no output schema (so return values are described), the description is sufficient for an agent to select and invoke the tool. The only minor gap is that it doesn't mention the 'opt_fields' parameter behavior for expanding fields, but the overall context is complete enough for a straightforward read operation. The pointer to the sibling tool for finding GIDs adds needed context.

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 both parameters already have descriptions in the schema. The description reinforces that 'time_tracking_entry_gid' is the key input and where to find it, but it does not add new semantic meaning beyond the schema. The 'opt_fields' parameter is only referenced by the return fields list in the description, not explicitly explained as a parameter. Baseline 3 is correct given the high schema coverage.

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 uses a specific verb ('Get') with a clear resource ('a single time tracking entry by GID') and lists the returned fields. It also distinguishes itself from the sibling tool 'asana_get_time_tracking_entries' by explicitly pointing to it for finding entry GIDs, which differentiates this singular retrieval tool from the list/find tool.

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 explicitly tells the agent when to use this tool ('Get a single time tracking entry by GID') and directs to the alternative for finding GIDs ('Use asana_get_time_tracking_entries to find entry GIDs'). This provides clear usage context and an explicit exclusion/alternative reference, which is exactly what the guideline dimension asks for.

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