get_application

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

With no annotations provided, the description carries the full responsibility for behavioral disclosure. It merely states 'Get details' without indicating whether this is a read-only operation, what specific data fields are returned, or any side effects. The lack of output schema further amplifies this gap, as the agent has no way to anticipate the response structure.

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 a single, concise sentence: 'Get details about a specific job application'. It is front-loaded with the verb and resource, contains no filler words, and every word contributes to the meaning. This is an example of efficient writing.

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 tool with one parameter, the schema covers parameter semantics, but the description fails to provide usage context, behavioral expectations, or return value information. With no annotations and no output schema, the description is too sparse to fully equip an agent to use the tool correctly. It leaves important questions unanswered, such as what 'details' are included and how the application ID should be obtained.

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 fully describes the sole parameter (applicationId) with 'The Ashby application ID', achieving 100% schema description coverage. Baseline is 3, and the description does not add any extra parameter semantics beyond what the schema provides. No compensation is needed, but no additional value is added either.

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 identifies the tool's function: 'Get details about a specific job application' uses an active verb and specific resource. It implicitly distinguishes from sibling tools like list_candidate_applications (which lists multiple) and get_application_feedback (which focuses on feedback), though it doesn't explicitly call out these alternatives.

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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparison to sibling tools like get_candidate or list_candidate_applications. This leaves the agent to infer usage context entirely from the name and schema.

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