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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value annotations cannot: the distinction between apply_url and source_url, the reassurance that 'Offpeak never submits applications', and the prompt-injection warning that listing content is untrusted. It stops short of covering not-found or invalid-ID behavior.

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?

Three compact sentences with the core action front-loaded, followed by field semantics and a safety caveat. There is minimal waste, though the apply_url/source_url sentence leans toward documenting return values that could arguably live elsewhere.

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-ID read tool with no output schema, the description supplies the important return-field semantics and a security caveat, which is close to sufficient. Gaps remain around error behavior for stale or deleted IDs and whether the listing can change between searches, but nothing blocking is missing.

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?

With a single parameter and 0% schema description coverage, the description must carry the semantics, and it partially does by stating job_id must originate from search results. It does not restate type or validation, though the schema already constrains it to a positive integer. The remaining sentences describe return fields rather than the parameter.

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?

Names a specific verb and resource ('get current details for a job ID'), and scopes the ID source as coming 'from search results'. It also clarifies two return fields (apply_url vs source_url), which sharpens what the tool actually delivers. It never explicitly contrasts with siblings like get_jobs or search_jobs, so the singular-vs-plural distinction is left to inference.

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?

The phrase 'from search results' implies the intended workflow (search first, then fetch details by ID), which is genuinely useful routing context. However, there is no explicit when-to-use/when-not, and no named alternative such as get_jobs for bulk retrieval or get_saved_jobs for previously saved listings.

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