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

Beyond the readOnlyHint/idempotent annotations, the description adds genuinely useful behavior: it 'opens nothing by itself' and only returns instructions, and it specifies what the output looks like (screens, buttons, fields). That is exactly the extra context an agent needs to avoid assuming a side effect occurred. It stops short of describing output format or whether a session must already be open.

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 message (returns steps, does nothing itself, then use browser tools) is front-loaded and clear. However, the final sentence about Bullhorn's REST API is long and partly meta-commentary, and the 'checked 23 Oct 2026' date adds little for an agent selecting the tool. The 'opens nothing by itself' point is restated in slightly different words.

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 no-parameter, read-only guidance tool the description covers purpose, side effects, and next steps, which is most of what's needed. What it leaves unclear is how the steps get scoped without any input (which job, which candidates) and whether the user's Bullhorn browser session must already be authenticated. No output schema exists, so describing the returned guidance more concretely would have helped.

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 schema has zero parameters and full schema coverage, so the baseline of 4 applies only if the description compensates for the oddity of a zero-input 'submit candidates to a job' tool. The description never explains how the guidance is targeted at a particular job or candidate, which is a meaningful gap despite there being no parameters to document.

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 a concrete verb and resource and immediately redefines the actual behavior: it 'Returns how to do it in Bullhorn step by step (screens, buttons, fields)' rather than performing the submission. That distinguishes it from the actionable cotlet_browser_* siblings, though the tool name and the phrase 'Submit candidates to a job' still conflict slightly with the fact that nothing is submitted.

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 sequencing: call this first to get the steps, then 'do it with the cotlet_browser_* tools in the user's Bullhorn Cloud Browser.' It also pre-empts the obvious alternative (using Bullhorn's REST API) by explaining that the API is a paid partner contract, not a recruiter key. It does not distinguish itself from the Bullhorn read siblings (e.g., list_job_submissions), but those serve different tasks.

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