Get job posting

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

No annotations are present, so the description carries the behavioral burden. It discloses that the tool works logged out for public pages and includes a workflow with safeguards like "Never auto-submit" and "Skip already_applied jobs." However, it does not explicitly state that fetching is read-only, describe error behavior, or clarify what happens for non-public jobs.

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 summary line is front-loaded and useful, and the workflow is numbered for readability. However, the description embeds a lengthy 10-step application workflow that concerns several sibling tools, not just waas_get_job. This is structured but not concise, and some steps go well beyond the tool's own behavior.

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 one-parameter fetch tool with no output schema, the description provides solid context: it names core returned fields (description, comp, visa, skills), explains logged-out access, and gives integration order relative to siblings. It could add return-format or error details, but the essential operational context is present.

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 sole parameter job_id is already documented in the schema as "Numeric id or /jobs/123 URL," giving 100% schema description coverage. The tool description adds no additional parameter-level meaning beyond what the schema provides, so the baseline 3 is appropriate.

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 opens with a specific verb and resource: "Fetch full job posting (description, comp, visa, skills)." This clearly distinguishes waas_get_job from siblings like waas_search or waas_list_applied. The title 'Get job posting' reinforces the same purpose without ambiguity.

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 required workflow explicitly positions this tool after waas_search or a user-provided URL and before waas_get_company and waas_inspect_application. It also notes "Works logged out for public pages," giving useful context about when authentication is not needed. It stops short of explicitly listing when-not-to-use alternatives, but the workflow is strong guidance.

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