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

Annotations already establish that this is a read-only, idempotent, non-destructive operation, so the description is not carrying the safety burden. It adds useful behavioral context by naming returned categories such as missing_ids, closed_ids, and applied_ids, and by stating that cursors expire after 15 minutes. It does not discuss authorization or rate limits, but those are minor gaps given the annotation coverage.

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 two efficient sentences with no wasted text. It front-loads the return-shape information and follows with pagination constraints in a logical order.

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?

With no output schema, the description is responsible for explaining return values, and it does list the main fields and ID categories. It covers pagination and cursor expiry, though it does not fully explain what missing_ids represents or the exact structure of compact saved_jobs summaries.

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 adds some meaning for both parameters, saying cursor is the next_cursor and limit is optional for pagination. However, schema coverage is only 50%, and the description does not explain the limit bounds or default, nor does it add much beyond the cursor description already present in 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 gives a specific verb and resource: it lists saved job IDs and returns compact saved_jobs summaries plus categorized ID sets. It is clearly not a search or mutation tool, though it does not explicitly distinguish itself from siblings such as get_jobs or get_saved_searches.

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 pagination mechanics but does not say when an agent should use get_saved_jobs instead of alternatives like get_jobs or get_saved_searches. There are no explicit use cases, prerequisites, or exclusions.

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