Маркет сценариев

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds real behavioral value: it reveals that with the case parameter each publication shows whether it is already installed in that case and whether it is behind the current version, and it discloses that the catalog mixes project and community sources — context the annotations and schema do not provide.

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 sentences cover an 11-parameter tool efficiently, with the core purpose front-loaded in the first sentence. The middle sentence summarizing search/filter capabilities partially duplicates what the schema already documents, and the final sentence packs both the case behavior and the market_install pointer, but there is no filler or repetition.

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 complex 11-parameter tool with no output schema, the description answers the key operational questions: what the catalog contains, what filters exist, how the case parameter changes results, and which sibling handles installation. The main gap is that with no output schema present, the return-value shape of a listed publication is not described, though the annotations fully cover the safety profile.

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 baseline is 3. The description groups the filter parameters (category, platform, source, needs_ai, needs_knowledge) into a capability summary and, more usefully, explains the case parameter's effect on results (install status and version freshness), which goes beyond the schema's identity-focused description of case. For the remaining parameters the schema already carries the semantic load.

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 'Каталог готовых сценариев' (catalog of ready-made scripts), clearly identifying the resource and the listing function, and states the catalog spans project and community publications. It names market_install as the installation path, distinguishing this read/catalog tool from that sibling, though the operating verb is implied ('каталог') rather than explicit and no distinction is drawn against other market_* siblings such as market_get or market_like.

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 closing clause 'Установка — market_install' explicitly routes installation intent to a named alternative, which is a genuine usage signal. However, no guidance is given for the other market_* siblings (market_get for fetching a single publication, market_like, market_publish, market_update, etc.), and when-not conditions beyond installation are left to inference.

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