Apply to job

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

With no annotations provided, the description carries the full burden, and it does an excellent job. It discloses that the tool never auto-submits externally, returns PAUSED_FOR_USER with a checklist, and only records APPLIED when markApplied is explicitly passed after user confirmation. This is concrete, non-obvious behavioral information beyond the tool name and schema.

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 compact and front-loaded: the main action appears first, followed by the key behavioral caveat and the conditional flag instruction. Every sentence contributes essential information, and there is no filler or repetition of the schema.

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?

The description explains the outcome states and the critical user-confirmation condition, which is valuable for a tool with no output schema and no annotations. However, it omits what `application` refers to (likely an application ID from a previous step), what `note` does, and any fallback or error behavior. Enough to invoke the tool at a basic level, but not fully complete.

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 description coverage is only 33%, so the description should compensate for the undocumented application and note parameters, but it only explains markApplied. The `application` integer and `note` string are never described, leaving the agent without enough semantic context to populate them correctly. markApplied gains slight additional meaning ('record it as APPLIED'), but the other two parameters remain under-specified.

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 clearly states the action ('submit the application') and the mechanism ('through the resolved application adapter'), so the tool's core purpose is unambiguous. It does not explicitly name or differentiate siblings like prepare_application or update_application_tracking, but the intent is still distinct enough for an agent to identify what this tool does.

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 provides clear operational guidance: in Phase 1, the manual adapter never auto-submits, and markApplied should be true only after user confirmation. This tells the agent when and how to use the tool effectively, though it does not explicitly discuss alternatives or when to prefer another sibling tool.

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