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

No annotations are provided, so the description carries the burden. 'List' accurately implies a read-only operation with no side effects, and the optional status filter is disclosed. It does not add extra details like pagination or ordering, but for a simple list tool the core behavior is sufficiently transparent.

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, front-loaded sentence with no wasted words. It states the main purpose and the optional filter efficiently.

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 one-parameter list tool with a complete input schema and an output schema present, the description covers everything an agent needs to select and invoke it correctly. No critical information is missing.

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 100%, so the schema already fully documents the single status parameter. The description merely reiterates that filtering is optional, adding no additional semantic meaning beyond the schema.

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 uses a specific verb ('List') and resource ('tracked applications'), including the optional filter by pipeline status. This clearly distinguishes it from siblings like track_application (a write operation) and search_jobs (searching for new jobs).

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 intended usage is clear: use this tool to retrieve tracked applications, optionally filtering by status. It does not explicitly name alternatives or exclusions, but the context is unambiguous given the sibling tool names and the read-only nature of the action.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It states the core behavior (scoring match) but doesn't disclose what the score means, how it's calculated, whether it's a percentage, a grade, or what the output schema contains. Since there is an output schema, some return details are covered, but the description itself adds little behavioral context beyond the basic action.

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, clear sentence that front-loads the action and the two inputs. It is concise and free of fluff. It could add a bit more context about the output, but it earns its place as a minimal, clear statement.

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 tool is simple with two well-documented parameters and an output schema. The description is adequate for an agent to know what the tool does, but it doesn't explain what the score represents or how to interpret it. Given the output schema exists, the agent can see the return shape, but the description could still clarify the scoring scale or criteria. It's a minimum viable description.

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 100%, so the schema already documents both parameters clearly. The description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.

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 tool's function: scoring how well a resume matches a job description. It uses a specific verb ('score') and identifies the two key resources (resume and job description). It doesn't explicitly differentiate from siblings, but the siblings are clearly different actions (search, track, list), so the purpose is distinct enough.

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 implies the use case: when you have a resume and a job description and want a match score. It doesn't explicitly state when not to use it or mention alternatives, but the sibling tools are clearly different functions, so an agent can infer when this is appropriate. No explicit exclusions or alternative routing.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It accurately conveys a read-only search behavior and mentions 'live' postings, but it does not mention result ordering, pagination, or any system-level constraints. These gaps are minor for a search tool but still present.

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, front-loaded sentence with no wasted words. It names the action, resource, and main filters immediately, making it easy for an agent to parse quickly.

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 search tool with full schema coverage and an output schema, the description is sufficient for selecting and invoking the tool. The main omission is explicit guidance on when to use this tool over its siblings, but those siblings are distinct enough that this is a minor gap.

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 100%, so the parameters are already fully documented in the schema with examples and constraints. The description adds little beyond restating that query and location are the relevant filters.

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 verb ('Search'), a resource ('live job postings'), and the key filters (title/keyword, optional location). It clearly distinguishes itself from sibling tools that score resume matches, track applications, or list applications.

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 use case is clear from the description: find job postings by keyword and optionally filter by location. It does not explicitly name alternatives or exclusions, but the sibling tools perform such different functions that confusion is unlikely.

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

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

No annotations are present, so the description carries the full burden of disclosing the operation. It clearly indicates a mutating, upsert-like behavior, but it doesn't mention the required job_title/company fields, default status, or what happens on invalid application_id. The description is accurate but sparse.

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?

A single, front-loaded sentence that conveys both modes of the tool without waste. It earns maximum points for efficiency.

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 output schema and 100% schema coverage carry the parameter detail, so the brief description suffices for the common case. However, it omits guidance on how to obtain an application_id for updates, leaving a minor gap in the overall tool context.

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 description itself adds no parameter-specific meaning beyond what's in the schema. With 100% schema description coverage, the parameter semantics are fully handled by the input schema, so this is a baseline 3.

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 clear verb+resource: 'Create a new tracked application, or update an existing one by id.' It distinctively covers the upsert operation, clearly differentiating from siblings like search_jobs, score_resume_match, and list_applications, which have different purposes.

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 gives a clear operational context (create new vs. update by id), but it never explicitly says when to prefer this tool over alternatives or how to obtain an application_id (e.g., via list_applications). No exclusions or alternative references are provided, so the usage is mostly implicit.

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