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

Beyond the readOnlyHint/idempotent annotations, it discloses two important traits: it performs no action itself ('opens nothing by itself') and it returns instructional content rather than records. The note that Deputy has a REST API but no official MCP server adds useful context on why browser automation is required. It stops short of describing the return format or length of the instructions.

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 core scoping constraint is front-loaded, but the final sentence about Deputy's official API and 'checked 20 Oct 2026' is tangential metadata that competes with the actionable instruction to follow up with the browser tools. The middle of the description is dense with clauses joined by semicolons rather than cleanly separated steps.

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 zero parameters and no output schema, the description needs to convey what comes back and how to proceed — it does the latter well. It never describes the shape of the returned instructions or what a timesheet listing will look like once the browser tools are used, leaving a gap for an agent planning a multi-step flow.

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 clarify; baseline for a no-param tool is 4. It could have noted that no filtering by date or employee is possible, but nothing is missing against 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 opens with a specific verb and resource ('List timesheets in the user's own Deputy account'), which an agent can distinguish from siblings like deputy_approve_timesheet or deputy_discard_timesheet. It then reveals a second purpose — returning step-by-step Deputy UI instructions rather than timesheet data — which muddies the headline slightly, though the agent ends up understanding what it actually gets.

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?

It scopes usage to the user's own account and explicitly chains the call to cotlet_browser_* tools afterward, which is genuine flow guidance. It offers no when-not conditions and never contrasts with the many other deputy_list_* siblings, so the agent must infer which listing tool to pick.

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