locations_get_recurring_task_by_id

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. However, the description adds no behavioral context beyond that—no mention of what the response contains, whether the resource might not exist, error handling, or any rate limits. Since the description adds no value beyond annotations, it fails to compensate for the absence of an output schema.

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 just a single sentence that essentially restates the tool name ('Get Recurring Task By Id' vs 'locations_get_recurring_task_by_id'). It is concise, but it does not earn its place—it adds no information beyond what the name already conveys. Effective conciseness would involve front-loading useful constraints or context, which is absent here.

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 only two parameters and no output schema, the description is very sparse. It does not explain what a recurring task is, what the response looks like, or any related context. Given the lack of an output schema and the existence of sibling tools for task management, more context (e.g., typical usage or return format) is expected for completeness, but none is provided.

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 input schema provides 100% description coverage: id is described as 'Recurring Task Id' and locationId includes a default behavior. The tool description itself doesn't add any parameter details, but because schema coverage is complete, the baseline of 3 applies. The description offers no extra value 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 states 'Get Recurring Task By Id' which clearly identifies the action (get) and resource (recurring task) with a specific identifier. It is unambiguous and not a tautology because it adds the verb 'Get' and the qualifier 'By Id', though it does not explicitly differentiate from sibling tools like locations_task_search or locations_get_tag_by_id. It is clear but lacks explicit sibling contrast.

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 no guidance on when to use this tool versus alternatives. It does not mention that this should be used when an id is already known, or that for searching/filtering one should use locations_task_search. There is no mention of exclusions or contexts, leaving the agent to infer usage from the name alone.

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