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

No annotations are provided, so the description must carry the behavioral burden. It discloses the action and required keys, but nothing about side effects, validation, idempotency, errors, or permissions. The reference to format is structural, not behavioral.

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 dense sentences; the action and required fields are front-loaded and no words are wasted. The README redirect is concise, though not self-contained.

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 create operation with a completely open branch object, the description identifies the mandatory keys and points to get_branch for shape, which partially compensates for the empty schema. It leaves workspace semantics and the full valid-key set to external sources, so it is only minimally 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 0%, and branch is an unconstrained additionalProperties object, so the listed required keys add real meaning. However, the workspace parameter is never mentioned, and valid keys are deferred to an external README rather than described.

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 verb ('add') and resource ('branch'), immediately distinguishing it from list/update/get siblings. It also states the format is like ybiz_get_branch, reinforcing the object being created.

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 sets the context: creating a new branch, with required fields enumerated. It does not explicitly state when not to use it or point to update_branch as the alternative for existing branches, but the new-vs-existing distinction is strongly 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?

The description discloses a critical behavioral trait: the tool refuses to close branches from baseline unless their company-id is in allow_close, and that allow_close should only be passed with explicit user confirmation. This is valuable beyond the schema. However, there are no annotations to lean on, and the description doesn't mention other behaviors like side effects, output format, 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?

The description is a single, dense sentence that front-loads the primary purpose and then states the critical safety condition. Every word 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?

The tool has 3 optional parameters, no required ones, and an output schema exists. The description covers the main purpose and the most important safety constraint, but it doesn't explain what the output contains, how workspace is used, or what happens when no_baseline is set. For a build tool with a safety-critical condition, this is adequate but not 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 description coverage is 0%, so the description must compensate. It explains the semantics of allow_close (which company-ids are allowed to be closed) and implies the role of no_baseline (bypassing baseline checks), but it doesn't explain workspace or provide full parameter-level detail. The description adds meaning for allow_close but leaves other parameters under-specified.

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 ('Собрать feed/feed.xml') and a key behavioral constraint, which distinguishes it from sibling tools like ybiz_validate or ybiz_diff. However, it doesn't explicitly name sibling tools or contrast them, so differentiation is implied rather than explicit.

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 clear guidance on when to use the tool: to build the feed, and it warns about the allow_close condition requiring explicit user confirmation. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide.

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 full responsibility for behavioral disclosure. It mentions that removed items 'will be closed in Yandex', which hints at potential impact but does not clarify whether the tool itself executes changes or only reports them. It also omits details about read-only nature, permissions, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with zero wasted words. It front-loads the purpose ('What the feed will change relative to baseline') and lists the output categories succinctly. Structure is exemplary.

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 (not shown) and the description already mentions the key output categories. However, it does not explain what 'baseline' refers to, how the workspace parameter influences the result, or whether the tool actually applies changes or merely reports them. For a simple diff tool this is adequate but leaves some operational details ambiguous.

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 includes a single optional parameter 'workspace' with no description and 0% schema coverage. The description does not mention this parameter at all, leaving the agent without guidance on how to set it or what values are acceptable. Since the description adds no meaning beyond the schema, it fails to compensate for the coverage 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 computes a diff of the feed relative to baseline, listing added, removed, and changed items. It uses a specific verb ('diff') and resource ('feed vs baseline'), and the categories are explicit. However, it does not explicitly differentiate from sibling tools, though the tool name and purpose make it 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?

The description provides no guidance on when to use this tool versus alternatives like ybiz_validate or ybiz_build. It simply states what the tool does without any context on prerequisites, typical use cases, or when it would be inappropriate.

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. The parenthetical 'как в data/branches/<company-id>.yaml' usefully discloses that the output matches the YAML file content, but it does not mention error behavior, existence checks, authentication, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a short, single phrase with no unnecessary words. The core scope ('one branch') and the data reference are front-loaded, 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?

For a simple 2-parameter read tool with an output schema, the core operation is sufficiently clear, and the YAML reference helps define the return content. However, the workspace parameter is left unexplained, which could matter in multi-workspace or multi-tenant contexts.

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 implicitly ties company_id to the file path '<company-id>.yaml', but it does not explain the workspace parameter at all. This leaves the meaning of half the parameters effectively undocumented.

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 phrase 'Полные данные одного филиала' clearly indicates a single-branch data retrieval operationable recognizable from the tool name. It differentiates from ybiz_list_branches by the singular scope ('одного филиала'), but lacks an explicit verb such as 'get' or 'return', so it is clear but not a fully specified action statement.

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 does not state when to use this tool versus alternatives like ybiz_list_branches or ybiz_update_branch. The singular 'одного филиала' weakly implies a single-branch use case, but there is no explicit guidance on selection, exclusions, 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose the key destructive trait — force=True overwrites existing YAML and destroys local unsaved edits — which is valuable. However, it does not disclose whether a non-force import is also a mutation, whether the operation is reversible, or what happens to a pre-existing baseline on a normal import.

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 with the core purpose front-loaded and zero filler. The destructive force=True warning is placed at the end, which is acceptable but arguably deserves more prominence given the data-loss risk; still, 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 file-mutating tool with no annotations and 0% schema coverage, the description should do more. It covers the core operation and force behavior but leaves the workspace parameter undocumented, fails to explain what happens to an existing baseline on a normal (non-force) import, and omits prerequisites. An output schema exists, which relieves return-value explanation, but the behavioral and parameter gaps remain significant.

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 for all three parameters. It explains force=True's meaning (overwrite existing YAML, lose unsaved edits) and implies xml_path is the path to the XML file, but the workspace parameter is never mentioned or explained at all, leaving it completely ambiguous.

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 (import), a concrete source resource (XML export from Yandex Business cabinet), a destination (YAML branches), and a distinct side effect (saving as baseline). Among the siblings (ybiz_status, ybiz_list_branches, ybiz_get_branch, ybiz_update_branch, ybiz_add_branch, ybiz_validate, ybiz_diff, ybiz_build), none perform import, so the tool is cleanly differentiated without needing to name an alternative.

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 — call this when you have an XML export to bring into YAML branches — and the siblings are all distinct operations, so the context is reasonably clear. However, there is no explicit when-to-use vs when-not-to guidance, no mention of prerequisites (e.g., whether the XML must be validated first with ybiz_validate), and no stated 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does not state that the operation is read-only, whether it requires special permissions, or whether it returns a snapshot or streaming list. It only mentions the output fields, omitting any side effects, pagination, or data volume considerations. This is a significant gap for a tool that likely lists many records.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise and front-loaded with the action. However, it is so terse that it omits necessary details about the parameter and usage. Conciseness is good, but the structure sacrifices clarity for brevity. It earns a middle score because it is not bloated, but it is under-informative.

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 list tool with one optional parameter, the description does not fully cover what an agent needs. It lacks explanation of the workspace parameter, any filtering or ordering behavior, and does not mention error cases or empty results. The output schema is absent, but the description does list fields, which is helpful. Still, for a tool that might be used to explore branches, the missing parameter context is a notable shortfall.

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 has one optional parameter 'workspace' (string or null, default null) with 0% coverage from the description. The description does not explain what 'workspace' does or how it affects the list. It might filter by workspace, but this is left to guesswork. The described fields (company-id, etc.) are return fields, not parameters, so they add no semantics about the input.

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 action ('list') and the resource ('branches'), and enumerates the returned fields (company-id, name, address, rubrics). This differentiates it from siblings like ybiz_get_branch or ybiz_update_branch, which imply singular or mutating operations. It could be slightly more explicit about 'all branches' but is unambiguous overall.

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 guidance is given on when to use this tool versus alternatives such as ybiz_get_branch (for a single branch) or ybiz_add_branch/update_branch (for mutations). The description implies it is for listing, but there is no explicit mention of when it is appropriate or how it differs from other listing tools (e.g., import/export might also list). This leaves the agent to infer usage.

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 implies a read-only summary operation and lists what data is included, but it does not explicitly state that it performs no mutations, nor what happens when workspace is null, or what error conditions may arise.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence, front-loads the scope ('workspace summary'), and lists exactly what the summary contains. There is no filler or redundant content.

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, has one optional parameter, and an output schema exists, so return structure is covered. However, the description omits null-workspace behavior and does not position the tool relative to its siblings, leaving some context 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 0%, so the description must compensate. It clarifies that the tool is scoped to a workspace, but it does not explain the workspace parameter format, the meaning of null/default, or any accepted values.

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 that the tool returns a workspace summary and enumerates its contents: network config, branch count, baseline and feed presence. This distinguishes it from sibling tools that manipulate individual branches, though it lacks an explicit verb like 'get' or 'retrieve'.

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 guidance is given about when to use this tool versus alternatives such as ybiz_list_branches, ybiz_validate, or ybiz_diff. The agent must infer from the name and sibling names that this is the high-level status overview.

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 burden, and it does: it discloses that `changes` replaces top-level keys wholesale, null values delete keys, invalid branches are not saved, and the feed is not rebuilt. It doesn't cover auth, idempotency, or failure modes like nonexistent branch, but core behavior is well disclosed.

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 concise sentences with no filler. The main purpose is front-loaded, followed by the essential data semantics and the cross-tool follow-up. 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 mutation tool with no annotations and an output schema, the description covers validation behavior, feed rebuild, and change semantics. It doesn't state error behavior for missing branches or permission requirements, but the provided context plus output schema is sufficient for correct invocation in most cases.

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 0%, so the description must compensate. It does for the critical `changes` parameter with an example and precise semantics (replacement of top-level keys, null deletion). `company_id` and `workspace` remain schema-only, but their names are self-explanatory; the key behavioral parameter is thoroughly 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 specific verb+resource: 'Изменить поля филиала' (modify branch fields), making it clear this is an update operation on a branch, distinct from add/get/list siblings. It does not explicitly name sibling alternatives or scope constraints, 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?

The final sentence 'Фид не пересобирается — вызови ybiz_build' explicitly instructs when to call ybiz_build after this tool, and the validation note implies a guardrail before saving. It does not explicitly state when to prefer ybiz_add_branch over this update, so no 5, 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It does not state whether the tool is read-only, what side effects occur, whether it requires specific permissions, or what happens on failure. The reference to 'rules from documentation' is vague and does not clarify the actual behavior. This is a significant gap for a validation tool that could be read-only but is not 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?

The description is a single, short sentence with no fluff. It is front-loaded with the main purpose. However, it is so terse that it omits necessary details, but that is a completeness issue, not a conciseness one. For what it includes, it is 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?

The tool has an output schema (not shown) and one optional parameter, but the description is incomplete. It does not explain what the workspace parameter does, what the validation output looks like, or how the 'rules from documentation' are applied. An agent cannot confidently invoke this tool without additional context, especially regarding the workspace parameter's influence on 'all branches'.

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 has one optional parameter 'workspace' with zero description coverage (0%). The description does not mention this parameter at all, leaving its meaning and effect entirely undefined. The description does not add any meaning beyond the bare schema, failing to compensate for the lack of schema descriptions.

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 ('проверка' = checking/validating) and a specific resource ('всех филиалов' = all branches), and mentions the method (XSD + documentation rules). It distinguishes from siblings like ybiz_status or ybiz_list_branches by focusing on validation rather than status or listing. However, it does not specify what 'validate' entails (e.g., schema compliance, business rules), so it is clear but not fully precise.

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 explicit guidance on when to use this tool versus its siblings. It does not mention alternatives, prerequisites, or scenarios where validation is appropriate. The only implicit hint is the purpose of validation, but it does not tell an agent when to choose this over ybiz_diff or ybiz_build, for example.

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