lidarr_indexers

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly labels each operation as WRITE or DESTRUCTIVE, even noting nuances like 'lidarr_test_indexer(force_test=False, body={}) — Test an indexer configuration (body, without saving). WRITE: this modifies your Lidarr instance.' This clearly alerts the agent to side effects. Read-only operations are left unlabelled, implying safety, which is acceptable given the explicit labeling of mutating ones.

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 well-organized bulleted list where each line is short, consistent, and necessary. It front-loads a general instruction ('Pass operation and an arguments dict...') followed by all 23 operations. No sentence is wasted; the length is justified by the number of operations covered. The formatting improves scanability for an agent.

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?

Given the complexity (23 operations, 2 generic parameters, output schema present), the description is remarkably complete. It covers every operation in the enum, their parameters, safety labels, and even explains the arguments dict concept. It does not need to explain return values because an output schema exists. The only minor gap is the lack of detailed resource schemas, but that is beyond the scope of a tool description and is likely provided elsewhere.

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 has zero descriptions for parameters (0% schema coverage), so the description must compensate. It does so by listing each operation's parameter names and defaults, e.g., 'lidarr_create_indexer(force_save=False, body={})', and sometimes explaining body contents ('body carries ids', 'body is a list of resources'). This adds significant meaning beyond the schema, but it does not fully describe the internal structure of resource objects (e.g., IndexerResource), leaving some ambiguity.

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 enumerates each operation with a specific verb and resource (e.g., 'lidarr_list_indexer() — List indexers', 'lidarr_delete_indexer(id) — Delete an indexer'), making the purpose of each sub-operation unambiguous. It fully distinguishes the tool's scope from sibling tools by listing all included operations in a detailed, function-by-function format.

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 implicitly defines when to use the tool: any operation involving Lidarr indexers, delay profiles, or release profiles. It provides clear context for each operation's function, but does not explicitly mention when not to use it or point to alternatives. However, since sibling tools cover distinct domains (e.g., release_search, media_library), the boundary is obvious and the operations are self-explanatory.

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