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

Annotations already declare readOnlyHint=true, so the read-only safety is covered. The description adds valuable non-obvious behavior: descriptions of episodes not yet reached are hidden by default, and only the existence of the episode is shown. This informs the agent about spoiler behavior without contradicting the annotations.

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 short sentences with no filler. The first sentence states the core purpose, and the second front-loads the key behavioral caveat about hidden unwatched episode descriptions.

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 output schema, annotations, and moderate parameter count, the description covers the main operational concerns: tracked-series scope and spoiler defaults. It is slightly thin on search matching semantics, but the schema and annotations carry enough of the remaining burden.

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 descriptions cover query, show, and include_unwatched, while limit, season, and include_specials lack descriptions. The description adds meaning only to the unwatched/spoiler parameter by explaining the default hidden behavior. With 50% schema coverage, the description provides marginal but not complete compensation for the undocumented parameters.

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 action: search episodes by plot description among tracked series. This clearly distinguishes it from siblings such as show_search (searching shows), show_profile (show details), tracking_update (mutating tracking state), and watch_next (next 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?

The description gives useful context: the search is scoped to tracked series and uses episode descriptions. However, it does not explicitly say when to choose this tool over siblings, nor does it mention any exclusions or alternative tools.

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?

Annotations already mark the tool as read-only, and the description reinforces this with 'Показывает' while adding useful behavioral context: it aggregates episode ratings into season-level trends and includes the current user's position. No contradiction with readOnlyHint/openWorldHint is present. It stops short of revealing potential dependencies, such as whether tracking data is required.

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 definition is brief and front-loaded: the first sentence states exactly what the profile contains. The second sentence adds a differentiating claim, though it is more marketing than invocation-critical; overall it is efficiently structured.

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 simple two-parameter schema, a read-only annotation, and an output schema, the description sufficiently communicates what the tool returns and why it is special. The only notable gaps are the undocumented response_format modes and lack of explicit routing to sibling tools, which are minor at this complexity.

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 schema already documents the show parameter with an example, and the description's 'рейтинги по сезонам' adds contextual meaning to that parameter. However, the optional response_format parameter is only defined by its enum and default; the description adds no explanation of concise vs. detailed, leaving a real gap at 50% schema coverage.

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 uses 'Показывает' (shows) with a specific resource, the show profile, and enumerates concrete content: facts, per-season ratings, and the user's position in the show. It implicitly separates this from search/sibling tools by claiming this aggregated view is not available in TVmaze clients, but it never names the sibling alternatives.

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 context is implied: an agent can infer to call this when it needs a show's profile, season ratings, or the user's standing in the show. However, the description gives no explicit when-to-use/when-not-to-use conditions and does not mention alternative sibling tools such as show_search or episode_search.

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?

Annotations already signal a read-only operation. The description adds useful behavioral context: filters must use exact values from catalog://facets, and each result is marked with the user's tracking state. It does not cover edge cases like empty results or pagination, but those are less critical given the read-only annotation and output schema.

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 well-structured with a clear opening summary, bullet-style mode explanations, and concrete examples. It is slightly longer than strictly necessary, especially the aside about TVmaze, but each part contributes to the agent's understanding of when and how to invoke the tool.

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 read-only search tool with 10 optional parameters, the description covers the key decision points: which search mode to use, how to handle empty query, where to get exact filter values, and what the results include. Some minor gaps remain around limit, year range, language, and response_format, but the output schema and parameter names reduce the risk of misuse.

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 low (30%), but the tool description compensates well for the central parameters: it explains query modes, empty-query filter browsing, exact facet values for genre/status, and gives a min_rating example. Remaining parameters like limit, year_from/year_to, and response_format are left largely to their names and schema constraints, which are self-explanatory.

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 states the tool's function: find a series by title, by plot description, or by filters, and it gives concrete examples for each mode. It is specific about the resource and behavior, but it does not explicitly differentiate show_search from its sibling tools like episode_search or show_profile.

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 gives strong practical guidance: when to use a title query, when to use a plot query, when to use filters without query, and where to find exact filter values. It does not mention exclusions or direct alternatives among sibling tools, so it falls just short of a fully explicit routing guide.

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?

Annotations already set readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds a valuable behavioral detail for action='track': episodes are loaded and indexed, enabling search and backlog counting. This goes beyond the schema and annotations, though per-action side effects are not exhaustively documented.

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: one front-loaded purpose sentence and one focused sentence about the track-specific behavior. Every sentence earns its place and there is no repetition of schema contents.

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 six action variants and five parameters, the description covers the overall purpose and one important action-specific consequence, but it omits action-parameter requirements such as progress needing episode or rate needing rating, and it does not explain the note parameter. The output schema and annotations reduce the burden, but an agent still has to infer the per-action call contract.

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 schema covers show, action, and episode; the description adds meaning by glossing several action enum values in natural language and explaining the track action's effect. It does not clarify note or rating semantics, nor dependencies between actions and optional parameters, so with 60% schema coverage the added value is only partial.

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 opens with a clear verb and resource: 'Изменить состояние просмотра' (change viewing state) and lists concrete actions such as subscribe, mark episode, rate, and drop. This makes it clear that the tool mutates tracking records, but it does not explicitly contrast with sibling tools like show_search or watch_next.

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 usage: it is the tool for updating viewing/tracking state, while siblings are search/profile tools, and the note about action='track' indicates when that particular action is relevant. However, it never names alternatives or states when not to use the tool, leaving routing partially 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral constraints beyond that: only released episodes are considered, only backlog items, and only episodes that fit the time limit. No contradiction with annotations.

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, purposeful sentences: the first states the overall action, the second states the filtering rules. There is no filler, repetition, or unnecessary detail, and the main purpose is front-loaded.

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 read-only recommendation tool with three optional parameters and an output schema, the description provides enough to understand what the tool does and how it filters. It could be slightly richer with an explicit usage note, but nothing critical is missing for correct invocation.

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 67%, with minutes and include_new already documented. The tool description adds useful context for minutes ('укладываются в заданное время') and indirectly for include_new ('только вышедшие серии'), but it adds nothing about the limit parameter, which remains only defined by its schema constraints.

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 uses a specific action ('Выбрать, что посмотреть') and a clear resource ('из накопившегося'), then narrows the behavior with concrete criteria: only released episodes from the backlog and only those fitting the given time. This clearly distinguishes it from the sibling search, profile, and update 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 intended use is implied by the phrasing: use it when the user wants a recommendation of what to watch now from their backlog within a time budget. However, the description does not explicitly name alternatives, state when not to use it, or contrast it with episode_search, show_search, or tracking_update.

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