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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the payload is shaped as a schema.org JobPosting with specific sections, which is useful given there's no output schema, but it says nothing about failure behavior, missing fields, or response size.

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?

Two short sentences with the return content first and the input sourcing second; nothing is padded and no sentence is redundant.

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 simple read-only tool with two required identifiers and no output schema, the description covers the resource, the return structure, and how to obtain the inputs. Only edge cases such as invalid ids or partial postings are unaddressed, which is a minor gap at this complexity.

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 0%, so the schema documents nothing about the two required parameters. The description compensates partially by stating both come from search_jobs, establishing they are identifiers produced by another tool, but it gives no format, casing, or validity constraints for either value.

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 specific retrieval of 'one position as schema.org JobPosting' and enumerates the returned content (tasks, requirements, benefits, application link), which clearly distinguishes it from the plural search_jobs and from get_employer. It doesn't explicitly name those siblings, but the singular-vs-search framing makes the distinction inferable.

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?

'Use employer_slug and job_id from search_jobs' tells the agent this is a follow-up call whose inputs come from a prior search, which is real when-to-use guidance. There are no exclusions or error-case guidance (e.g., what happens for a nonexistent job), so it falls short of a 5.

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