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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them ("opens nothing by itself"). Beyond that it discloses the actual return shape (step-by-step screens, buttons, fields) and the underlying constraint that no Arborgold API, webhooks, or Zapier app exist, which explains why browser tools are required. The integration list and check date are extra context rather than behavior, keeping it below a 5.

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 functional content (returns steps, opens nothing, follow with cotlet_browser_*) is front-loaded in the second sentence, but the opening clause "from ChatGPT, Claude or any AI agent" is filler and the closing API/integration sentence with a check date is verbose for an agent's decision-making. It is readable but carries two sentences' worth of material that does not change tool selection.

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 no parameters and no output schema, the description carries the burden of explaining what comes back, and it does so concretely (screens, buttons, fields). It also explains why the browser tools follow. What remains unstated is roughly how much guidance is returned or whether it varies by job type, but that is a small gap for a zero-input tool.

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 no schema semantics to supplement; the baseline for a no-param tool is 4. The description correctly implies no inputs are needed and points to the browser tools for the actual data entry.

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 names the specific resource and action ("Schedule job ... in the user's own Arborgold account") and then corrects the natural misreading of the name by stating it "Returns how to do it in Arborgold step by step (screens, buttons, fields) and opens nothing by itself." That distinguishes it from action-performing siblings like arborgold_create_estimate. Minor deduction because the leading sentence still reads as if the tool performs the scheduling.

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 gives explicit downstream routing: "then do it with the cotlet_browser_* tools in the user's Arborgold Cloud Browser," which tells the agent this is a prerequisite step, not a terminator. It does not state exclusions against the arborgold_* list/create siblings, so the comparison to alternatives is left implicit.

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