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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: the return value is a human-style click-by-click procedure (screens, buttons, fields), not a job list, and the tool performs no navigation itself. It still doesn't say what a failure or an unconnected account looks like.

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 disclosure (returns steps, opens nothing, follow up with cotlet_browser_*) is reasonably front-loaded, but "from ChatGPT, Claude or any AI agent" adds nothing, and the closing "Workever's official API: Workever publishes no public API" is an awkward self-restating fragment that would read better as a plain statement of why the guide approach is used.

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, annotation-rich, output-schema-less guidance tool, the description covers what it returns and what to do next, which is most of what an agent needs. Missing are the preconditions for the follow-up browser steps and any indication of failure modes.

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?

There are zero parameters and the schema is fully described, so the baseline of 4 applies; the description correctly implies no input is needed. No parameter meaning is added or needed.

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?

States a specific verb and resource ("List jobs in the user's own Workever account") and then clarifies the actual mechanic: it returns step-by-step instructions rather than job data. That clarification is essential because the name alone would mislead. It does not, however, distinguish itself from other Workever siblings (create_job, list_unpaid_invoices) or from cotlet_app_guide, which plausibly offers similar guidance.

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?

Gives a clear usage sequence: call this to get the procedure, then act with the cotlet_browser_* tools in the Workever Cloud Browser, and states it opens nothing by itself. What it lacks is any exclusion or prerequisite (e.g., account connected, browser session already open) and any explicit routing away from a similar guide tool.

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