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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavior beyond that: ids are self-contained and remain valid later (stability across calls), and NHS Jobs / Teaching Vacancies results carry a closing date that other sources do not. What it omits is any hint of error behavior for a stale or malformed id.

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?

Front-loaded purpose sentence followed by a usage sentence with concrete utterances; the trailing line about closing dates is slightly tacked-on but still earns its place as source-specific behavior. No padding or boilerplate.

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 single-parameter read with no output schema, the description covers purpose, trigger, id discipline, and one source-dependent field variation. It could say a bit more about the shape of the returned details (apply link, closing date, etc.), which matters more here since no output schema exists.

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?

Schema coverage is already 100%, so the baseline is 3, but the description adds invocation-relevant meaning: the id must be copied 'exactly as given' from a search_jobs result, and it confirms that id provenance is what keeps the call working later. This reinforces format discipline rather than merely repeating 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?

States a specific verb+resource pair: fetch details for a single job identified by an id coming from search_jobs. The scoping to 'one job from a search result' cleanly distinguishes it from its only sibling, search_jobs, without needing the schema.

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 names the triggering situation with user-utterance examples ('tell me more about the second one', 'what's the apply link for the Uber job?') and specifies the dependency on a prior search_jobs result. Nothing is left for the agent to infer about when this tool is the right pick.

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