Chip MCP

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

Annotations only declare readOnlyHint=true, so the description carries most of the behavioral burden. It adds meaningful context: call exactly once, prefer whats_new for repeated visits, and depth controls whether output is summarized or verbatim. Nothing contradicts the read-only annotation.

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 compact sentences deliver the resource description, usage rule, alternative, and parameter semantics with no filler. The most important usage guidance ('call once') is front-loaded, and each clause 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?

An output schema exists, so the description does not need to enumerate return values. It provides the trigger condition, the cheaper alternative, and depth semantics, which is enough for an agent to select and invoke the tool correctly. The only lightly covered parameter, project_id, is clear from its name and required status.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It fully explains depth with its default ('brief') and alternative value ('full'), but it says nothing about project_id beyond the schema's name and type. project_id is inferable, but not explicitly documented.

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 statement of the resource ('Контекст проекта') and enumerates its contents: instructions, tasks, map table of contents, memory, files, and dialogs. It also explicitly contrasts itself with whats_new, making it easy for an agent to distinguish this tool from its siblings.

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 gives an explicit trigger condition: call once when taking on a project for the first time. It also names the alternative ('whats_new') for familiar projects and adds a cost signal ('он дешевле'), which is concrete, actionable guidance.

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, so no mutation warning is needed. The description adds useful context by stating the returned attributes and positioning the tool as a discovery step before file reading. It does not disclose edge cases such as empty projects or file counts, but the read-only annotation lowers the bar for additional disclosure.

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: the first states what the tool returns, the second gives the when-to-use rule. No filler or redundant repetition of schema fields.

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 only one obviously-named integer parameter, an output schema present, and annotations covering read-only behavior, the description provides the essential tie to read_project_file. 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 0%, and the description does not explain project_id beyond the broad 'project knowledge base' context. The parameter name is self-explanatory, but with zero schema coverage the description should have explicitly tied project_id to the source project.

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 identifies the resource (project knowledge base files) and the attributes returned (name, size, readability), making the listing operation clear. It also distinguishes itself from read_project_file by framing it as the precursor when the exact filename is unknown. However, the verb 'list' is only implied, not explicitly stated, which costs a point.

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?

Explicitly instructs to call this tool before read_project_file when the exact name is unknown, naming the sibling alternative and the condition. This is strong routing guidance with no ambiguity.

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, so the safety profile is covered. The description adds a behavioral trait: the list changes rarely and should not be re-read. This goes beyond the annotation by warning about staleness and unnecessary repeated calls, which is valuable operational 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?

A single, compact sentence in Russian conveys the resource, the return fields, the use case, and a caching guideline. Every clause earns its place; 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 zero-parameter read-only list tool with an output schema present, the description is sufficient on its own. It states what is returned, when to invoke it, and notes the infrequent change rate. Nothing an agent needs to call this 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 are zero parameters, so the schema requires no further explanation; the context signal confirms 100% schema coverage. The description's note that the output provides project_id is helpful for downstream usage, though it does not describe input parameters (there are none).

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 the resource ('Проекты пользователя' – user projects) and the returned fields (id, name, last activity, open tasks). It stops short of an explicit verb like 'list' or 'get', but the tool name and content make the purpose clear. It differentiates from sibling tools like list_files and list_tasks by focusing exclusively on projects.

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 'Нужен project_id — сюда' gives an explicit trigger for when to use this tool: when a project_id is needed. It also advises 'список меняется редко, не перечитывай', indicating when not to re-fetch. It does not name alternative tools for the same task, but the usage context is clear.

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 this as read-only, and the description adds useful lifecycle context: tasks are created by the user or previous session, completed tasks are closed via complete_task, and unclosed tasks will reappear. This goes beyond the annotation without contradicting it.

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 convey purpose, usage timing, and task lifecycle without unnecessary detail. The most important guidance 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 one-parameter tool with an output schema, the description covers when to use it and what behavior to expect. The only notable gap is the under-explained project_id parameter, but overall context is adequate.

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 a single required project_id with 0% description coverage, and the tool description only vaguely references 'this project' without explicitly explaining the project_id parameter. The description does not fully compensate for the schema gap.

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 explicitly identifies the tool as listing tasks ('поручения') for the current project, which is a specific resource and scope. It also differentiates this tool from siblings by tying it to work flow actions like add_task and complete_task.

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 states precisely when to call the tool: at the beginning of work and when looking for the next task. It also names related tools for adding and completing tasks, giving the agent clear routing guidance.

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, so the description does not need to restate read-only behavior. The description adds value by disclosing ordering (new on top), offset semantics (offset 0 is fresh), and pagination via a hint at the end of the response. This goes beyond the annotation and provides useful behavioral context without contradicting it.

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 three short sentences, front-loading the purpose, then usage guidance, then pagination details. Every sentence earns its place with no filler or redundancy, making it efficient and easy to scan.

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 presence of an output schema and the readOnlyHint annotation, the description provides all needed context: what the tool returns (verbatim journal with session summaries and milestone notes), how to use it for a specific query, and how to paginate. No critical information is missing for an agent to call 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 description coverage is 0%, so the description must compensate. It explains the offset parameter (offset 0 is fresh, then page via hint), but does not explain project_id. While project_id is likely self-evident, the description does not explicitly describe it, leaving a small gap in parameter documentation.

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 returns a project journal verbatim, listing content types (session summaries and milestone notes), and explicitly distinguishes from search_project by mentioning it for topic searches. The verb 'read' is implied but the resource and scope are specific, and the differentiation from the sibling makes the purpose unambiguous.

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 explicit when-to-use guidance ('call for what happened N sessions ago') and points to the alternative for topic searches ('search by topic — search_project'). This is a clear directive that tells the agent exactly when to pick this tool over its 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?

Annotations already declare readOnlyHint=true, and the description does not contradict that. It adds context that the returned content is 'current knowledge on a topic' and describes the granularity as one shelf/section, but it does not address error behavior, missing sections, or other side effects. Given the read-only annotation and output schema, 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?

The description is exactly two sentences: the first defines the tool's purpose and content type, the second gives usage instructions. Every word contributes, and there is no redundant or filler 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 simple two-parameter read tool with an output schema, the description covers the essential facts: what a section is, what content it returns, and how the agent should obtain valid section names. Minor ambiguity remains about the exact format of `section` (whether it is a slug, title, or ID), but the examples reduce this risk.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description partially compensates by explaining that `section` is a named topic such as «Решения» or «Грабли», giving the agent examples of valid values. `project_id` receives no additional explanation, but its meaning is conventional and its schema type (integer) is likely clear enough.

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 identifies the tool as returning a single section (article) of the project map with current knowledge on a topic, giving concrete examples like «Решения» and «Грабли». It references get_project_context and get_project_map, which helps distinguish it from broader tools, though the action verb is only implied by the tool name rather than stated in the description.

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 explicitly tells the agent to call this tool by table-of-contents entries obtained from get_project_context or get_project_map, establishing a clear usage workflow. It does not state exclusions or when to prefer alternative tools like search_project, which keeps it from a perfect score.

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?

Beyond the readOnlyHint annotation, the description adds useful behaviors: omitting session_id returns the most recent dialog, and the full dictated plan should be retrieved rather than paraphrased. It does not describe cursor/pagination or permission details, but these are not required for a simple read tool with an 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?

Two sentences carry the purpose, use-case, and parameter behavior with no filler. The main purpose is front-loaded, and every clause adds useful 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?

Given the low parameter count, the readOnlyHint annotation, and the presence of an output schema, the description is complete enough for an agent to invoke the tool correctly. It explains required context, optional session selection, and where to obtain session IDs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates meaningfully: it explains that session_id is optional, that omitting it yields the latest dialog, and that IDs come from get_project_context. project_id is left to its self-evident name, but the key optional behavior is clarified.

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: reading a user's dialog with Chip inside a project, returning a summary and latest replies. It also distinguishes the operation from related tools by referencing how dialog IDs come from get_project_context.

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 gives a concrete scenario: if the user dictated a plan from a phone, retrieve the whole text rather than a retelling. It also explains session_id behavior and where to find dialog IDs, but it does not explicitly say when not to use this tool or name an alternative for exclusion.

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?

readOnlyHint=true already marks it non-destructive; the description adds real behavioral detail beyond that: without page, a long document returns a TOC, and the response ends with a navigation hint. No contradiction.

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 then the pagination workflow. Every clause earns its place; no repetition of 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?

For a read-only, paginated file tool with an output schema, the description covers the non-obvious pagination behavior and navigation loop. It lacks only explicit guidance on the two required identifier parameters, which limits completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It adds useful semantics only for page (omit → TOC, page=N → section content), while the required project_id and filename are not described beyond their schema names.

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 says 'Текст файла из базы знаний проекта, страницами' – a specific read action on a project file with pagination. It is clear, but it does not name or contrast sibling tools like list_files or read_project_dialog, so differentiation is left to the agent.

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 gives concrete procedural guidance: omit page to get a table of contents for long documents, then call with page=N and follow the hint at the end. This is clear context, but there are no explicit exclusions or 'use X instead' guidance for 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?

The readOnlyHint annotation already signals non-destructiveness. The description adds valuable behavioral context beyond the annotation: search scope across several stores, cross-project behavior when project_id is omitted, keyword-limit semantics, and how kind/since filter results. This meaningfully informs invocation without contradicting 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?

Every sentence earns its place: scope, use case, project_id semantics, query shape, and filter explanation. The description is compact, front-loaded with purpose, and free of padding.

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 multi-parameter search tool, the description covers the search surface, invocation conditions, query constraints, and all parameter behaviors. Since an output schema exists, return-value documentation is not required here. Nothing essential 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?

Schema description coverage is 0%, so the description must carry the semantics — and it does for all four params: query as 1–3 keywords, project_id fallback to all projects, kind with its candidate values, and since with ISO/cursor semantics. This substantially exceeds the bare schema structure.

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 a multi-source resource ('знанию проекта: полочки карты, журнал, память, диалоги'), clearly distinguishing it from sibling read/list tools. It is not a tautology and immediately conveys that this tool searches across project knowledge rather than reading one artifact.

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 gives explicit guidance on when to invoke it: 'Зови за конкретным фактом или старым решением, которого нет в контексте.' It also clarifies behavioral use cases like searching without project_id and query shape. It does not explicitly name sibling tools or state when not to use them, but the context is strong enough to route an agent correctly.

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 declare readOnlyHint=true, which the description does not contradict. The description adds behavioral context beyond annotations: it explains that the tool returns delta vs full context depending on familiarity, and describes the session parameter as a branch label that shows neighboring sessions of the token. This provides useful behavioral disclosure beyond the read-only hint.

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 concise, containing only a few sentences. It front-loads the purpose and provides essential usage guidance. However, the language is somewhat dense and jargon-heavy (e.g., 'Курсора', 'полочки карты'), which could hinder clarity for an agent. Still, it is efficiently structured with 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?

The tool has an output schema, so return format is covered. The description covers when to use, how to use (delta vs full), fallback to get_project_context, and explains two of three parameters. It is fairly complete for an agent to call correctly, though the condition for 'many changes' is not precisely defined, and project_id semantics are assumed rather than stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It briefly explains 'since' (from the previous response's Cursor) and 'session' (label of your branch), but does not explain project_id, which is the only required parameter. While it adds some meaning to two of three parameters, it leaves the most critical parameter undocumented, so it only partially compensates for the schema gap.

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 purpose: showing project changes since the last visit, listing specific content types (journal, assignments, files, map shelves, dialogs). It uses a specific verb (shows changes) and resource (project). However, it doesn't explicitly contrast with all sibling tools like list_files or read_journal, only mentioning get_project_context as an alternative, so it doesn't fully distinguish from every 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 description explicitly instructs when to call this tool: 'Call FIRST, as soon as you take on a project'. It differentiates between a familiar project (only delta) and a first-time visit (full context). It also provides a fallback: if it says 'many changes', then get get_project_context. This is clear, actionable usage guidance with explicit alternatives.

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?

The readOnlyHint annotation already declares the operation safe, so the description only needs to add context beyond that. It adds useful behavioral context: the tool is a status/diagnostic call that reveals plan-dependent data and can be used after a limit-based refusal. No contradiction or hidden side effects are implied.

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 returned data and followed by usage guidance. Every phrase contributes meaning, and there is no redundant restatement of the tool name or 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?

For a zero-parameter, read-only status tool with an output schema present, the description covers what the tool returns and when to call it. Nothing an agent needs in order to invoke 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?

The tool has zero parameters and schema coverage is 100%, so the schema leaves nothing undocumented. The description appropriately does not need to explain parameters; it earns the baseline of 4 for a parameterless tool.

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 the concrete data returned: tariff, project slot occupancy, and remaining daily limits on the paid plan. Although it uses a noun phrase rather than an explicit 'returns' verb, the resource set is specific and unique among the listed siblings, so an agent can understand exactly what this tool provides.

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 explicit invocation timing: 'Зови в начале сессии' (call at the start of the session) and 'когда другой тул отказал по лимиту' (when another tool refused due to a limit). This is strong, actionable guidance that tells the agent both when to call and in which fallback scenario.

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