get_timebase_activity_detail

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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds a genuinely useful behavioral constraint: 'Limited TimeBase server versions support,' which is not captured by annotations. It does not contradict annotations and provides an extra caveat, earning a solid score despite the sparse description.

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, concise sentence that immediately states the action and the object, followed by a short caveat. It is front-loaded with the verb and resource, contains no filler, and every clause provides necessary information. This is an exemplary concise description.

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 7 parameters but 100% schema coverage and an output schema present, the description does not need to explain parameters or return value format. It covers the only additional non-schema context—that some server versions are not supported. The tool is a straightforward detail-fetch operation, and the description, though minimal, covers essential context. It could mention that include_instruments only applies to cursor/loader, or that instance_key is required in multi-instance setups, but these are already in the schema, so not necessary for completeness.

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?

Input schema coverage is 100% – every parameter has a description, which is the baseline condition. The tool description itself does not add any parameter-specific meaning beyond what the schema already provides. For example, the enum for 'kind' is fully documented in the schema, and the description does not elaborate on id formats or instance_key requirements. Thus, the description adds no value to parameter understanding beyond the schema.

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 function: 'Get details for one cursor, loader, connection, or lock.' It uses a specific verb ('get details') and a specific resource type, distinguishing it from the sibling list_timebase_activity which lists activity objects rather than retrieving a single object's details.

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 gives clear context: it is for retrieving details of a single specific activity object, which implies use when you have a known id/kind and need more information than a list provides. However, it does not explicitly mention alternatives or exclusions, such as 'use list_timebase_activity to discover objects first' or 'not supported on all server versions.' The caveat 'Limited TimeBase server versions support' provides some usage warning but not a full when-to-use/not-to-use comparison.

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