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

With no annotations provided, the description carries the full behavioral burden, yet it discloses no side effects: whether a duplicate check occurs, whether adding triggers an automatic episode search, or what permissions/rate constraints apply. 'Add' implies mutation but nothing about consequences is stated.

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?

Three short sentences, front-loaded with purpose, then the prerequisite, then the optional inputs. No padding, though the optional-fields sentence is somewhat redundant with the schema.

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?

Covers the required input and the source for its value, which is the key thing an agent needs to call it. For an 8-parameter mutating tool with no annotations and no output schema, the absence of any duplicate-handling or side-effect guidance leaves a real 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 schema already documents all 8 parameters, including defaults. The description loosely echoes root folder, quality profile, and season monitoring but adds no format or semantics beyond the schema – baseline 3 applies.

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?

States a specific verb ('Add') and resource ('a new TV series to your library'), which cleanly separates it from the edit/delete/refresh siblings. It does not explicitly name a tool it is not, so it falls just short of a 5.

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?

Gives a clear precondition – the tvdbId must come from sonarr_search_series, which routes the agent to the right sibling for acquisition. It stops short of explicit exclusions (e.g. when to use edit_series instead), so no 5.

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. It discloses the key behavioral traits: irreversible deletion ('cannot be undone'), optional disk-level file removal, and a re-import prevention side-effect is left to the parameter description. It doesn't mention permission or confirmation requirements, but the core irreversibility warning is a meaningful addition.

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?

Three short sentences, all front-loaded and earning their place: purpose, option, and warning. No redundancy or filler.

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 destructive deletion tool with no annotations or output schema, the description covers the essential risk (irreversibility) and the file-deletion option. It could go further on prerequisites or return behavior, but it is largely complete for the agent's needs.

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 all three parameters including 'PERMANENT' and 'import list exclusion'. The description adds no parameter-level meaning beyond what the schema provides, so baseline 3 applies.

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?

States a specific verb and resource ('Delete a series from Sonarr'), clearly distinguishing it from siblings like sonarr_add_series and sonarr_edit_series. An agent immediately knows this is the destructive removal operation.

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 when to use it (to delete a series) and flags the optional file deletion, but does not name alternatives or exclusions—e.g., no mention of when to use sonarr_edit_series instead, or whether series must exist first. Usage is implied rather than explicit.

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?

With no annotations, the description carries the full disclosure burden. The instruction to fetch the full object first and pass it back implies full-object replacement semantics, which is useful context for a mutation. However, it says nothing about permissions, whether omitted fields are cleared, or what errors/replies occur, leaving meaningful gaps for a write operation.

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?

Three short sentences: purpose first, editable surface second, prerequisite workflow third. No filler, no repetition of the schema, fully front-loaded and appropriately sized.

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 single-parameter edit tool with no output schema and no annotations, the description covers purpose, editable fields, and the required read-modify-write workflow. It stops short of explaining replacement behavior for unmentioned fields or failure modes, but an agent has enough to invoke it correctly.

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 coverage is 100% and the schema already documents the 'series' object and its required 'id'. The description adds real meaning by enumerating which sub-fields are editable (monitored, quality profile, path, tags) and reinforcing that a complete object must be supplied, going slightly beyond the schema text.

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?

States a specific verb+resource ('Edit an existing series') and immediately names the mutable dimensions (monitored status, quality profile, path, tags), which cleanly separates it from sonarr_add_series and sonarr_delete_series. An agent can identify the tool's role without opening the schema.

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?

Gives an explicit workflow: fetch the object with sonarr_get_series, modify it, then pass it here. This is concrete procedural guidance that steers the agent to the prerequisite call. It lacks any negative guidance (e.g., use sonarr_refresh_series instead when only refreshing), so it falls short of a 5.

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 full disclosure burden. It usefully describes the return shape ('complete list with metadata, seasons, and statistics'), which matters because there is no output schema, but it says nothing about read-only safety, pagination, response size on large libraries, or failure modes.

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?

Two compact sentences, purpose front-loaded, with the return content following immediately. Nothing is padded or redundant.

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 zero-parameter read tool with no annotations and no output schema, the description is nearly sufficient: it covers scope and roughly what comes back. It stops short of noting anything about library-size behavior or that results are unfiltered and potentially large, which is the only meaningful 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a parameterless full-library fetch and does not invent any filtering arguments.

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 names a specific verb and resource: 'Get all series in your Sonarr library.' The word 'all' plus the return payload distinguishes it implicitly from single-item siblings like sonarr_get_series and sonarr_get_series_by_tvdb, but it never explicitly contrasts with sonarr_search_series or the other list-style tools, so sibling differentiation is left to inference.

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?

There is no explicit when-to-use guidance, no condition under which this bulk-fetch should be preferred over sonarr_search_series or per-series retrieval, and no mention of alternatives. The 'all' phrasing hints at bulk enumeration but does not state the selecting condition.

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?

With no annotations, the description carries the full behavioral burden but only discloses a default window ('Defaults to the next week'), which is already implied by the schema defaults for start/end. It says nothing about read-only semantics, result limits/ordering, or what a calendar response looks like.

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?

Three short sentences, front-loaded with the core purpose and range behavior. The closing sentence is mildly promotional but costs little.

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 six-parameter, all-optional read tool with no output schema or annotations, the description covers the essential concept but omits return-shape context (what a calendar entry contains, ordering) and any note that the optional include* flags are purely additive. Adequate but with visible 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?

Schema coverage is 100% and every parameter already has a description, so the schema does the heavy lifting. The description reiterates the date-range concept but adds no meaning beyond the schema, which is the baseline-3 case.

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?

States a specific verb and resource ('Get episodes airing in a date range'), which is distinct from siblings like sonarr_get_episodes or sonarr_get_wanted because it is scoped to air dates rather than a series or a missing-episode list. It does not name those siblings explicitly, so an agent must still infer the boundary, keeping it short of a 5.

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?

'Great for seeing what's coming up' is a vague benefit statement, not guidance on when to choose this over sonarr_get_wanted or sonarr_get_episodes. No prerequisites, exclusions, or alternative-routing conditions are given.

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?

With no annotations, the description carries the full behavioral burden and delivers almost nothing beyond the bare operation. It does not state that this is a read-only operation, what happens if the ID is invalid or not found, or what shape the returned detail takes.

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?

One front-loaded sentence with the verb and resource first and no filler. It is appropriately sized, though it is terse to the point of omitting usage and behavioral context that a slightly longer description could carry.

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 single-parameter read tool with no output schema and no annotations, the description is minimally sufficient: the agent knows what it retrieves and by what key. It is silent on error behavior and the content of the returned detail, leaving the definition adequate but thin.

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% and the single 'id' parameter is already documented as 'Episode ID'. The description merely restates that, adding no format, expected source, or validation detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb ('Get') and resource ('detailed information about a specific episode') and clarifies the lookup key ('by its episode ID'). It implicitly separates itself from the plural sibling sonarr_get_episodes, though it never names or contrasts with it.

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?

No when-to-use, when-not-to-use, or alternative is given. The agent cannot tell from the description when to prefer this over sonarr_get_episodes, sonarr_search_episodes, or sonarr_search_season beyond the trivial singular/plural distinction in the name.

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?

With no annotations, the description carries the full burden. "Get" implies a safe read, and it discloses the return payload (air dates, file status, monitoring status), which is genuinely useful given there is no output schema. It omits auth requirements, pagination, and whether the list is ever truncated for large series.

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?

Two short sentences, purpose front-loaded, no filler. Efficient, though the second sentence could carry more routing value instead of only describing the return.

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 two-parameter read tool with no output schema, the description adequately covers what it does and what comes back. It is thin on usage context and sibling differentiation, which matters given a crowded family of episode/series retrieval tools.

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 both seriesId and the optional seasonNumber are already documented in the schema. The description adds nothing about parameter format or the filtering behavior beyond what the schema states, so the baseline 3 applies.

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?

States a specific verb and resource ("Get all episodes for a specific series") and adds what is returned. It is clear, but it never names the sibling sonarr_get_episode (singular) or sonarr_search_episodes, so an agent must infer the boundary between 'all episodes for a series' and 'one episode'.

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?

No when-to-use guidance and no alternatives named. The agent gets no signal on when to prefer this over sonarr_search_episodes or sonarr_get_episode, leaving selection to inference from the name alone.

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?

With no annotations, the description carries the full behavioral burden. It usefully implies a read-only operation and enumerates the kinds of issues surfaced (disk space, download client), but says nothing about return format, empty-health behavior, or whether results are cached/live.

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?

Two tight sentences, front-loaded with the verb and resource, and the second sentence earns its place by concretely illustrating what "health" output contains.

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 zero-parameter read tool with no output schema, the description gives a reasonable sense of what is returned (warnings/errors categories), but it leaves the overlap with sonarr_get_system_status unresolved and gives no signal on result shape beyond examples.

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 tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. Schema coverage is 100% and consistent with no params.

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 and resource ("Get system health status") and clarifies what that means (warnings/errors about disk space, download client issues). It is clear on its own, but does not distinguish itself from the sibling sonarr_get_system_status, which an agent could easily confuse with this tool.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the sibling sonarr_get_system_status as an alternative or complement. The agent must infer the use case from the purpose text alone.

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 full burden. 'Get all' implies a safe read, but there is no disclosure of whether results are paginated, cached, or what permissions are needed. The second sentence restates the name rather than adding behavioral context.

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?

Two short sentences, front-loaded with the primary action. The second sentence is largely redundant with the first, which is the only real waste.

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 no-parameter list tool this is close to sufficient, but with no output schema the description should say what a profile contains or how the list is used. It leaves the return shape and any consumer-side relevance unexplained.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter meaning is lost.

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?

States a specific verb (Get) and resource (language profiles), which cleanly separates it from other sonarr reads. However, it never distinguishes itself from the closely related sibling sonarr_get_quality_profiles, relying only on the resource noun.

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?

There is no guidance on when to call this versus alternatives such as sonarr_get_quality_profiles, nor any prerequisites or context for why an agent would fetch language profiles before another operation.

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 full burden. 'Get all' reasonably implies a full, unpaginated read with no side effects, but it does not state whether results are cached, whether any auth is required, or what the shape of a profile is. Adequate but thin for an unannotated tool.

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?

Two short sentences, no filler, with the action front-loaded in the first sentence and the purpose in the second. Every sentence earns its place.

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 zero parameters, no output schema, and a simple read operation, the description is nearly complete. Only the return-value shape is left unspecified, which is a minor gap for a tool whose output structure an agent would benefit from knowing.

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 tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. No parameter-related information is missing.

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?

States a specific verb and resource: 'Get all quality profiles', with a second sentence clarifying what the returned profiles represent ('quality settings you can use when adding series'). It is clearly distinguishable from sibling profile-listing tools like get_language_profiles, though it never explicitly names that sibling.

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 phrase 'you can use when adding series' implies the usage context (retrieve profiles before calling add_series), but it never states when not to use it or names an alternative. Usage is implied rather than directed.

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?

With no annotations, the description carries the full burden. It usefully discloses the returned content (active downloads, progress, status, errors), which is valuable given there is no output schema, but says nothing about read-only semantics, pagination behavior, or result limits.

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?

Two short sentences with the core purpose front-loaded and zero filler. Every clause carries information.

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?

Because there is no output schema, the description's summary of returned fields (progress, status, errors) is genuinely needed and mostly sufficient for a simple read-only list tool. Minor gap: no mention of pagination behavior despite paging parameters.

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 all five parameters (page, sortKey, pageSize, sortDirection, includeUnknownSeriesItems) are already documented in the schema. The description adds no parameter meaning beyond that, making the baseline 3 appropriate.

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?

States a specific verb+resource ("Get current download queue") and clarifies the scope with what the queue contains. It doesn't explicitly contrast with sonarr_remove_from_queue, but no sibling also reads the queue, so the agent can distinguish it from the name alone.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the related sonarr_remove_from_queue tool that operates on the same resource. Usage is only implied by the verb "Get".

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?

Without annotations, the description must carry the full burden. It does convey that this is a read-only retrieval of configuration (all root folders), and that these are storage locations for series. However, it does not disclose return format, whether it requires authentication, or if there are side effects. It exceeds the bare minimum but lacks depth.

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?

Two short sentences. The first sentence is the core action; the second adds useful context without being verbose. No wasted words, front-loaded with the main action.

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 (no parameters, no output schema, no annotations), so the description does not need to explain return values or side effects. However, it could provide more context about what a root folder represents (e.g., filesystem paths) and when to use it relative to other series tools. As is, it is adequate but minimal.

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 tool has zero parameters, so according to the rules the baseline is 4. The description correctly does not discuss parameters, and it clarifies that the tool returns a list of all configured root folders, which is sufficient.

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 (Get) and resource (root folders) with scope 'all configured'. The second sentence adds meaning: root folders are storage locations for series. It does not explicitly differentiate itself from siblings like sonarr_get_series or sonarr_add_series, but the resource name 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?

There is no explicit 'when to use' or 'when not to use' guidance. The phrase 'Shows where series can be stored' implies that it is useful before adding or moving series, but this is only implied and not stated. No alternatives are mentioned.

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 full disclosure burden. It does describe the payload scope convincingly ('all seasons, episodes, and statistics'), which is useful for anticipating a large response, but it says nothing about permissions, failure modes, or rate limits.

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?

Two tight sentences, zero waste, with the identifying constraint front-loaded before the payload description.

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 and no annotations, the description usefully compensates by enumerating what comes back (seasons, episodes, statistics). Only minor gaps remain – no indication of response size, error behavior, or required permissions.

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% with a single parameter whose schema text already reads 'Sonarr series ID (not TVDB ID)'. The description's 'by its Sonarr ID' adds no meaning beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('Get detailed information about a specific series') and pins the identifier type with 'by its Sonarr ID', which implicitly separates it from the sibling sonarr_get_series_by_tvdb. It does not name that sibling explicitly, so differentiation is inferred rather than stated.

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?

Usage is only implied: the phrase 'by its Sonarr ID' signals a prerequisite (you must already hold a Sonarr ID), which distinguishes it from search tools. It never explicitly says when to prefer this over sonarr_get_series_by_tvdb or sonarr_get_all_series, and states no exclusions.

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 full burden of behavioral disclosure. It does not state whether this is a read-only operation (though 'Get' implies it), nor does it describe error behavior when the TVDB ID is not found, pagination, or return format. For a lookup tool with no annotations and no output schema, this is a significant 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?

Two sentences, zero waste, and the primary purpose is front-loaded ahead of the usage guidance. Every sentence earns its place.

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 single-parameter lookup tool, the description covers the core purpose and a key usage condition. However, with no annotations and no output schema, it should ideally disclose whether the operation is read-only and what happens on failure. The omission of these behavioral details leaves it minimally adequate rather than complete.

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 coverage is 100%, and the parameter schema already includes a description with an example ('TVDB ID (e.g., 81189 for Breaking Bad)'). The tool description adds no syntactic or format details beyond what the schema provides, so baseline 3 is appropriate.

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 (Get) and resource (series information) with an explicit lookup key (TVDB ID). It distinguishes itself from sonarr_get_series, which presumably uses the Sonarr ID, by naming the identifier type in the lookup.

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?

It clearly states when to use this tool: 'when you know the TVDB ID but not the Sonarr ID.' This gives a concrete context and implicitly contrasts with siblings like sonarr_get_series that require Sonarr ID. It does not explicitly name the alternative tool or cover exclusion cases, so it falls short of a 5.

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, but the description does disclose the returned content set (version, OS, runtime, database type, migration version), which is real behavioral information. It omits anything about auth/API-key requirements, caching, or whether the call is expensive, so the full burden is not met — but for a zero-parameter read-only status probe the remaining disclosure need is modest.

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?

Two sentences, both earning their place: the first states the purpose, the second enumerates the return contents. Purpose is front-loaded and there is no filler.

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 correctly compensates by listing what the response contains, and with zero parameters there is no input surface to document. The only gap is that it never positions the tool relative to sonarr_get_health, which is the one thing an agent could get wrong here.

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 tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter surface for the description to clarify and nothing is left ambiguous on the input side.

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?

Uses a specific verb and resource ('Get system status information') and further enumerates exactly what the payload contains (version, OS, .NET version, database type, migration version). This makes the tool's scope concrete. It does not, however, distinguish itself from the sibling sonarr_get_health, which an agent could plausibly confuse it with.

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 never says when to reach for this tool, when not to, or how it relates to the similar diagnostics tool sonarr_get_health. The only implicit guidance is the word 'Get', which tells the agent nothing about context or prerequisites.

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 full burden, and it never explicitly confirms this is a read-only, non-mutating, zero-argument call. For a trivial retrieval the risk is low and the verb "Get" strongly implies a safe read, but no auth, caching, or rate-limit context is offered.

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?

Two short sentences with the core action front-loaded. The second sentence slightly restates the first ("Get all tags" / "available tags") but does add the purpose of tags, so almost nothing is wasted.

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 zero-parameter retrieval tool with no output schema, the description never indicates the shape of what comes back (e.g., a list of tag objects with IDs and labels), which matters because the IDs are typically what callers need to assign tags. Adequate but leaves a 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and the schema coverage is 100%.

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?

States a specific verb and resource ("Get all tags") and adds what tags represent (labels applied to series for organization). It does not need to differentiate from siblings since none of them return tags, but it stops short of explicitly positioning itself relative to them.

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 clause "tags you can apply to series" implies the use case (discover tag identifiers before assigning them to series), but there is no explicit when-to-use or when-not-to-use statement and no named alternative. Usage is inferable rather than stated.

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 supplied, so the description carries the full burden. It helpfully discloses the semantic filter (monitored + missing file) that goes beyond the schema, but says nothing about pagination behavior, ordering defaults, or what the response contains.

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?

Two tight sentences with the purpose front-loaded and the scoping definition immediately after. No filler, no repetition of the tool name.

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 paginated, parameterized list tool with no annotations and no output schema, the description conveys the core result set but omits pagination and response-shape context. Adequate but with clear 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?

Schema description coverage is 100%, so all four parameters (page, pageSize, sortKey, sortDirection) are already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('Get wanted/missing episodes') and then defines the scope precisely: 'monitored but don't have files yet.' That definition distinguishes it semantically from sibling read tools like sonarr_get_calendar or sonarr_get_episodes, though it never names an alternative explicitly.

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 (surface episodes that still need to be acquired) but gives no explicit when-to-use, when-not-to-use, or alternative such as sonarr_get_calendar or sonarr_get_episodes. An agent must infer the trigger condition.

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?

With no annotations, the description carries the full behavioral burden. It does say the tool pulls from metadata sources and updates episode/air-date data, but it doesn't say whether this is a blocking or queued/async operation, whether it requires the series to already exist, whether it can fail on unavailable metadata providers, or how long it takes.

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?

Two short sentences front-loaded with the core action; nothing is padded. The trailing 'etc.' is mildly vague but costs little.

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 single-parameter, no-output-schema tool this is close to adequate, but key operational facts (sync vs. queued, error behavior on metadata failure) are absent and there are no annotations to fill the 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?

Only one parameter exists ('seriesId') and the schema already documents it fully at 100% coverage ('Sonarr series ID to refresh'). The description adds no additional semantics about identifier format or origin, so the baseline 3 applies.

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?

States a specific verb and resource ('Refresh series information from metadata sources') and names the effect ('Updates episode info, air dates'), which distinguishes it from siblings like sonarr_edit_series and sonarr_rescan_series. It doesn't explicitly contrast itself with those siblings, so it stops short of a 5.

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?

No when-to-use guidance is given and no alternatives are named, despite two nearby siblings (sonarr_rescan_series, sonarr_edit_series) that an agent could easily confuse with this one. The implication that this is for syncing metadata is left to inference.

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?

With no annotations at all, the description carries the full behavioral burden. It does disclose that blocklisting prevents re-download, which is genuinely useful, but omits that removal is a destructive/irreversible mutation, what happens to the underlying download client state, and how changeCategory or skipRedownload interact with the removal.

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?

Two short sentences, front-loaded with the core action and immediately followed by the key optional behavior. No filler.

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 mutation tool with no annotations and no output schema, the description is minimally adequate but leaves out the irreversibility of removal, required permissions, and what state the queue item ends in. It covers the primary side effect (blocklist re-download prevention) but not the full picture.

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 all four parameters are already documented in the schema. The description only echoes the blocklist parameter's meaning and adds nothing beyond schema for changeCategory or skipRedownload, so the baseline 3 applies.

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?

States a specific verb and resource ('Remove an item from the download queue') with a clear scope. It does not explicitly name a sibling, though it is the obvious counterpart to sonarr_get_queue, so differentiation relies on inference.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives or related tools like sonarr_get_queue to find the id. The agent gets the action but not the conditions for choosing it.

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?

There are no annotations, so the description carries the full behavioral burden. It discloses that it checks for new, modified, or deleted files, but does not state whether the operation is synchronous or asynchronous, what permissions are required, whether it triggers a command/job, or any side effects or rate limits.

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?

Two tightly written sentences that are front-loaded with the core action and then a clarifying detail. No wasted words.

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, no-annotation tool, the description is minimally adequate in saying what it does. However, it leaves out critical context such as how it differs from sonarr_refresh_series and whether it is an async command, which an agent would need to select it correctly.

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 coverage is 100% and the single parameter's meaning ('Sonarr series ID to rescan') is fully documented in the schema. The description adds nothing beyond the schema for parameter semantics, so the baseline of 3 is appropriate.

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 and resource ('Rescan series folder for files') and clarifies what it checks ('new, modified, or deleted episode files'). It is clear what the tool does, but it does not differentiate itself from the close sibling sonarr_refresh_series, which likely also triggers series folder updates.

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?

No when-to-use guidance is given. It does not mention prerequisites, alternatives (e.g., sonarr_refresh_series), or exclusions, leaving the agent to infer when this tool should be chosen over similar siblings.

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 full burden; it does disclose an important side effect that the name 'search' hides — the episode is sent to the download client. It stops short of saying whether this is queued, whether it can be undone, or what happens on failure.

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?

Three short sentences, front-loaded with the purpose and then the side effect, with no filler. Slightly clipped but every sentence carries information.

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 single-parameter tool with no annotations and no output schema, the description covers purpose, the download-client side effect, and the source of IDs. Minor gaps remain around failure behavior and what the call returns, but nothing essential to invoking it correctly 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?

There is a single parameter with 100% schema description coverage ('Array of episode IDs to search for'), so the schema already does the heavy lifting and baseline 3 applies. The description adds only the provenance of the IDs (sonarr_get_episodes), not format or shape details.

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?

States a specific verb+resource ('Search for specific episodes') and clarifies the real effect ('sends the episode to your download client'), which separates it from the sibling read/listing tools. It doesn't explicitly name sonarr_search_season or sonarr_search_series as alternatives, so sibling differentiation is only partial.

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?

Gives a prerequisite ('Use episodeIds from sonarr_get_episodes'), which is useful routing guidance for obtaining valid input. However it never states when to prefer this over sonarr_search_season or sonarr_search_series_command, so the when-vs-alternatives decision is left implied.

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?

With no annotations, the description carries the full behavioral burden. It does disclose the key side effect — the season is sent to the download client, i.e. this triggers downloads rather than merely listing results — which is genuinely useful. However, it does not mention reversibility, duplicate-download risk for already-downloaded episodes, or the nature of the response.

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?

Two short sentences with no filler; the operation is front-loaded and the consequential side-effect sentence immediately follows. Nothing is wasted.

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 two-parameter command tool with complete schema descriptions and no output schema, the description covers the essential action and its main side effect. It is still thin on what happens next (queue behavior, confirmation, response content) given the absence of annotations.

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%: both seriesId and seasonNumber are documented in the schema. The description adds no format, range, or syntax detail beyond what the schema already provides, so the baseline 3 applies.

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?

States a specific verb (search) and resource (all episodes in a season), with scope that distinguishes it from the episode-level sibling sonarr_search_episodes. It does not explicitly name that sibling, so differentiation relies on the agent inferring scope from 'season'.

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 phrase 'all episodes in a specific season' implies when this tool is appropriate versus an episode-level search, but no alternative is named and no exclusion (e.g., 'use sonarr_search_episodes for a single episode') is given. Usage is implied rather than stated.

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 full burden. It discloses the return shape ('potential matches with metadata'), which is genuinely useful, but says nothing about authentication, rate limits, or whether the search is local vs remote. For a read-only search tool this is adequate but not rich.

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?

Three tight sentences with no filler; the core action leads, the return value follows, and the routing purpose closes. Every sentence earns its place.

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 search with no output schema, the description covers action, source, and return nature, which is close to sufficient. Minor gaps remain around result limits or pagination, but an agent can call this correctly as written.

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% and the single 'term' parameter is already documented with examples in the schema. The description adds only the 'by title' framing, which is minor reinforcement rather than new meaning. Baseline 3 applies when 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?

States a specific verb and resource ('Search for TV series by title') plus the backing sources (TVDB/TMDB), so intent is unambiguous. It loosely distinguishes itself from the sibling sonarr_search_series_command by implying a direct lookup that returns matches, but it never names that sibling explicitly.

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?

'Use this to find the tvdbId needed to add a series' gives a concrete downstream purpose and implicitly routes the agent toward sonarr_add_series. It stops short of stating when not to use it or contrasting with the command-style search sibling.

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 full behavioral burden and largely fails to. It does not reveal that this issues a command (likely queued/async), whether it hits indexers, whether it can trigger downloads, or what permissions/state it requires.

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?

Two short sentences, front-loaded with the operation and followed by the UI analogy; no filler. Slightly redundant but efficient.

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 command-type tool with no annotations and no output schema, the description should at minimum explain that it dispatches a search job and what the caller gets back. That behavior is entirely absent, so an agent cannot predict the result of the call.

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 coverage is 100% with a single documented param (seriesId as 'Sonarr series ID'), so the schema already carries the semantics. The description adds no extra meaning about the parameter, which is acceptable under the baseline rule.

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?

States a specific verb (search) and resource (all monitored episodes of a series) and adds scope detail ('monitored') that distinguishes it from an unfiltered search. It does not, however, distinguish itself from the near-identically named sibling sonarr_search_series, leaving the agent to guess at the difference.

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 'Search All button functionality' analogy implies when a user would reach for this tool, but there is no explicit statement of when to use it versus sonarr_search_series, sonarr_search_episodes, or sonarr_search_season. Usage is implied rather than specified.

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