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

Goes well beyond the annotations by disclosing the single most important behavior: the tool opens nothing and performs no action, it only returns instructions, which the agent must then execute via the browser tools. It also explains why the official API is not an option (keys are not self-serve, must be requested from Recruiterflow support), which is exactly the kind of context annotations cannot carry. This is consistent with readOnlyHint=true, openWorldHint=false and idempotentHint=true.

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?

Three sentences, each doing distinct work: what it returns, how to act on it, and the API caveat. The API-key sentence is slightly tangential but justifies why the browser path exists. The opening 'List tasks' phrasing costs clarity and would be better replaced with a direct statement that this returns instructions.

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?

For a zero-parameter guidance tool with no output schema, the description covers the input contract (none), the return nature (step-by-step screens/buttons/fields), and the follow-up action. A little more on the shape of the returned guide (e.g. whether it targets the tasks page specifically) would make it fully self-sufficient.

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 tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema already shows. Baseline 4 applies.

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?

Names a specific resource (tasks in the user's Recruiterflow account) but the leading verb 'List' is misleading, since the second sentence clarifies the tool actually returns a step-by-step how-to guide rather than task data. It does distinguish itself from siblings implicitly by describing its handoff to cotlet_browser_* tools, so an agent can tell it is not a data-returning list call, but the correction arrives after a misleading opening.

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?

Explicitly states the workflow: call this to get screens/buttons/fields, then perform the action with cotlet_browser_* tools in the Cloud Browser. It does not name when to prefer a sibling list tool (e.g. list_activities) or when the browser path is unnecessary, so there is no exclusion guidance, but the when-and-how is otherwise clear.

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