overseerr_request_tv_to_library

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

With no annotations, the description carries the full burden. It does disclose important constraints (library name must match exactly, duplicate display names possible) and defaults (all seasons requested if omitted). However, it omits side effects, permission requirements, and confirmation behavior.

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 with a clear purpose statement, followed by a structured parameter list. The 'Available: None fetched' and '(or duplicates exist)' parentheticals feel like placeholder or incomplete data and slightly disrupt readability, but overall it remains concise.

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?

Even though parameter semantics are well covered, the description lacks explicit linkage to sibling tools (e.g., overseerr_get_available_libraries, overseerr_get_users) for resolving the 'not fetched' names, and does not describe what the tool returns or any side effects. For a mutation-style tool, this leaves gaps for the agent.

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 0%, and the description fully compensates by explaining each parameter's meaning and constraints: tmdb_id is the TMDB ID, library_name is the exact Sonarr library name, user_display_name is the exact Overseerr user, and seasons has a documented default behavior. This goes beyond the schema's bare type definitions.

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 first sentence clearly states the action ('Submit a TV show request'), the target resource ('specific Overseerr library identified by its name'), and the beneficiary ('on behalf of a specific user'). This distinguishes it from the sibling movie request tool and other contextual tools.

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 does not provide any guidance on when to use this tool versus alternatives such as overseerr_request_movie_to_library. It also fails to mention prerequisites like fetching the library list or user list, despite noting 'Available: None fetched'.

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