easy_apply

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly explains the safety gates: dry_run must be False to submit, and confirm must be True alongside dry_run=False. It also states that dry_run returns unanswered questions, indicating the tool's output behavior. This goes beyond a simple 'apply' description and provides critical safety and side-effect information. It does not contradict any annotations (none exist).

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 description is concise, front-loaded with the core purpose, and structured as a list of arguments. Every sentence earns its place, explaining the purpose and the critical parameter interactions. There is no fluff or redundancy, and the most important behavioral constraints (dry_run and confirm) are clearly highlighted.

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 tool with only 3 parameters and no output schema, the description is nearly complete. It explains the two modes, the safety gates, and even hints at the return value (unanswered questions) for dry_run. It does not describe potential failure scenarios (e.g., what happens if the URL isn't an Easy Apply job), but for a simple submission tool, this is acceptable. The description covers all necessary invocation details.

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 input schema has 0% description coverage, so the description must compensate fully. It does: each parameter (url, dry_run, confirm) is explained with its role and the logical constraints between them. The description adds meaning beyond the schema's basic types and defaults, making it clear that dry_run defaults to True (inspection mode) and confirm is a secondary safety gate. This is exactly the kind of semantic enrichment needed.

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 clear verb+resource: 'Inspect or submit an Easy Apply job application.' It distinguishes between two modes (inspection vs submission) and the resource is specific (Easy Apply job application). This makes it unambiguous what the tool does and clearly separates it from siblings like get_job_details or search_jobs, which focus on viewing or searching rather than applying.

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 description explains the two primary usage modes via the dry_run and confirm parameters: dry_run for inspection, and the combination of dry_run=False and confirm=True for submission. This provides clear context on how to use the tool. However, it does not explicitly state when to prefer this tool over alternatives (e.g., 'use get_job_details for viewing job info'), so it lacks exclusions or explicit when-not guidance. Still, the purpose is distinct enough that usage context is clear.

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