get_saved_jobs

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It's a read operation (listing), which is inferable from 'List', but the description doesn't mention pagination behavior, ordering, whether results include full job details or just summaries, or whether the 'limit' parameter controls result count. For a listing tool, this is a notable gap.

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 with zero wasted words. It's appropriately front-loaded and gets straight to the point.

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?

This is a fairly simple listing tool with one optional parameter and no output schema. The description covers the core purpose adequately. However, given no output schema exists, it doesn't explain what fields/information the returned jobs will contain, and leaves pagination/ordering behavior unspecified. Adequate for a simple tool but has small gaps.

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?

There's one optional parameter (limit) with a minimum of 1 and maximum of 50. Schema description coverage is 0%, so the description doesn't explain the limit parameter at all. However, the schema itself provides good constraint documentation (min/max), and the semantic of 'limit' is fairly self-evident for a list operation. A description mentioning 'limit controls how many jobs to return (max 50)' would be more helpful.

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 'List jobs you have saved on LinkedIn' clearly states a specific verb (list) and resource (saved jobs), and distinguishes it from sibling tools like search_jobs or get_job by specifying the 'saved' scope. It's clear and unambiguous, though it could be slightly more specific about the personal/owned nature.

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 this tool is for viewing a user's own saved jobs, which is an implied usage. It doesn't explicitly contrast with sibling tools like search_jobs (which finds new jobs) or save_job, though the sibling context makes the distinction reasonably inferable. There's no when-to-use-when-not guidance.

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