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 only restates the apply action and notes the default branch_name, which is already in the schema default. It does not disclose whether the operation is destructive, whether it commits changes, or how it handles invalid SQL.

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 and well-structured: a one-sentence purpose followed by a clean argument list. It contains no redundant or fluff content and is 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 tool's potentially schema-modifying nature, the description is too thin. It lacks context about the workflow with ai_preview_schema, what happens after applying (e.g., commit, migration), or any prerequisites. The presence of an output schema reduces the need for return-value explanation, but behavioral and workflow context is still 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's Args section is the only source of parameter explanations. It describes all five parameters, clearly defining the allowed mode values ('create' or 'modify') and the branch_name default, thus compensating for the missing 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 clearly states the tool applies AI-generated SQL to a schema in a specified branch, using the verb 'применить' (apply) and naming the target resource. It implies a distinct action from sibling preview tools by using 'apply' vs 'preview', but does not explicitly name 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?

The description implies usage when you have AI-generated SQL and want to apply it to a schema branch, but provides no explicit guidance on when to use it instead of ai_preview_schema or when not to use it. There are no exclusions or alternative tool references.

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 only says 'get result' without stating whether it is a read-only operation, whether it can be called multiple times, or what happens if the task is still processing. This is a significant gap for an AI task retrieval 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?

The description is compact, consisting of a one-sentence summary and a clear Args block. It is well-structured and avoids unnecessary detail, making it easy for an agent to parse.

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 description covers the tool's purpose and parameters, and an output schema exists, so return values are not needed. However, it does not address potential asynchronous behavior (e.g., task still running) or error scenarios, which are relevant for an AI task retrieval tool.

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?

With 0% schema description coverage, the description compensates by explaining all three parameters: project_uuid, schema_uuid, and task_uuid (specifically noting task_uuid comes from ai_preview_schema). This provides necessary meaning beyond the raw schema.

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 retrieves the result of an AI schema generation task using a specific verb ('Получить' = get) and a resource ('result of AI schema generation task'). It implies a retrieval operation, but does not explicitly distinguish it from the sibling tools ai_preview_schema and ai_apply_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?

The description provides a clear usage context by stating that task_uuid comes from ai_preview_schema, indicating the tool should be used after initiating an AI preview task. It does not mention explicit alternatives or exclusions, but the source of task_uuid gives enough 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?

No annotations are provided, so the description carries full weight. It discloses the async nature (returns task ID, wait for result via ai_get_preview) and the separation from actual application (ai_apply_schema). However, it does not explicitly state whether this tool mutates the schema directly; 'modify' mode might confuse an agent into thinking changes are applied, though the workflow implies otherwise.

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 and front-loaded with the primary action, then adds mode details and the pipeline. The Args list is structured and each line serves a purpose. 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 tool that kicks off an async AI generation process, the description covers the necessary context: what it does, the two modes, how to proceed with results, and all parameters. The presence of an output schema means return values need not be explained. It is complete 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?

With 0% schema description coverage, the description fully compensates by explaining each parameter: project_uuid, schema_uuid, prompt, mode (with allowed values 'create' and 'modify'), and current_schema (optional, used as context for modify). This adds essential meaning beyond the bare schema.

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: 'Запустить генерацию структуры схемы через ИИ' (launch generation of schema structure via AI) and that it returns a task ID. It distinguishes from siblings like ai_get_preview and ai_apply_schema by mentioning the workflow, showing this is the kickoff step.

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 explains when to use each mode ('create' for new schema, 'modify' for changes) and gives a clear workflow: run this, then wait via ai_get_preview, then apply via ai_apply_schema. It does not explicitly list alternatives or exclusions, but the workflow makes the tool's position 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?

There are no annotations, so the description carries the full burden of disclosing behavioral traits. It only states that the tool runs an analysis, implying a non-mutating operation, but does not mention permissions, whether any state changes occur, or what happens with the output. No side effects or safety guarantees are 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?

The description is extremely concise and front-loaded with the main action and purpose. The Args block is short and clearly separated, ensuring no wasted words. It is well-structured for quick reading.

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 values are covered. The description provides some context about what the analysis covers (metrics, quality rules, migration risks), but it lacks information about when to use the tool, potential expectations, or side effects. It is minimally adequate but leaves gaps in usage and behavioral context.

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 description coverage is 0%, so the description must compensate. It includes an Args section restating the parameter names with Russian labels like 'UUID проекта' and 'UUID схемы', which add no substantive meaning beyond the schema titles 'Project Uuid' and 'Schema Uuid'. No additional constraints, formats, or relationships are explained.

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 with a specific verb ('Запустить' / 'Run') and resource ('анализ схемы' / 'schema analysis'), and even lists what the analysis includes: 'метрики, правила качества, риски миграций' (metrics, quality rules, migration risks). It distinguishes from sibling tools like create_schema or delete_schema by focusing on analysis rather than modification.

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 provided on when to use this tool versus alternatives. The description simply states what the tool does without any context about prerequisites, typical scenarios, or exclusions. For example, it does not indicate that this should be run before a migration or when to prefer it over ai_preview_schema.

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 must disclose behavioral traits. It only says 'mass change' without mentioning atomicity, failure handling, permission requirements, whether existing values are overwritten, or how the operation interacts with branches. For a mutation tool, this lack of detail leaves significant ambiguity.

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, front-loaded with the main purpose, and uses a clearly formatted Args list with an illustrative example. Every sentence earns its place, and there is no filler or redundancy.

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 description provides adequate parameter semantics and the output schema exists to cover return values, but it lacks guidance on when to use this tool, the transaction/atomicity behavior, and error handling. For a batch mutation tool, this incomplete contextual information leaves the agent unsure about important operational details, though the core use case is covered.

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% (no parameter descriptions in the schema), but the description compensates well. It defines each parameter (schema_uuid, items, branch_name) and provides a concrete example of the items structure including table_uuid and data with sample fields. This adds meaning beyond the bare schema, though it does not enumerate all allowed data fields.

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: 'Массово изменить несколько таблиц одним запросом' (mass change several tables with one request). This both identifies the action (change/edit) and the resource (tables), and distinguishes it from single-table tools like edit_table by emphasizing the batch aspect.

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 for multi-table updates via 'несколько таблиц' (several tables) and provides an example, but it does not explicitly say when to prefer this tool over edit_table or any other sibling. There are no exclusions or alternative references, leaving usage context implicit 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 only states 'switch' and includes an 'apply_to_workspace' parameter that hints at side effects, but it does not disclose consequences for uncommitted changes, whether the operation is reversible, or what state is affected.

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: one sentence clarifying the purpose plus an args list. It is well-structured and not verbose, though the args list largely duplicates schema 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 tool's complexity (4 parameters, no annotations, and an output schema not shown), the description lacks important context: when to use it, side effects, relationship to workspace, and what happens to existing changes. It is a minimal viable description, but does not give a complete picture of the operation.

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 lists all four arguments with terse explanations (e.g., 'UUID проекта'), but these mostly restate the parameter names and add little beyond the schema's titles. Only 'apply_to_workspace' gets a slightly more meaningful note ('Apply the branch state to the workspace'), but overall the semantics are shallow.

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: 'Переключить схему на другую ветку' (Switch the schema to another branch). This is a specific verb and resource, and it distinguishes the tool from sibling tools like checkout_commit and commit_to_branch.

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 such as checkout_commit, fork_branch, or merge_branches. It does not mention prerequisites, typical scenarios, or 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 full responsibility for behavioral disclosure. It says 'switch schema', implying a state change, but does not disclose whether this is destructive, whether it discards uncommitted changes, how it interacts with the current branch, or what happens after the switch. This lack of side-effect details is a significant gap for a mutating 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?

The description is concise, with a single front-loaded sentence and a structured Args list. It avoids irrelevant detail. The Args block is somewhat mechanical but still more compact than a long prose paragraph. It slightly loses points for not grouping optional parameters or explaining the selection between commit_id and commit_uuid, which could improve structure.

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 tool's moderate complexity (5 parameters, no annotations, but an output schema), the description covers the basic operation and parameter types, but lacks guidance on how to choose between the two commit identifiers, potential side effects, and what the result indicates. It is adequate for a straightforward invoke but incomplete for confident handling of edge 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?

The input schema has no property descriptions (coverage 0%), so the description's Args block is the only source of parameter meaning. It adds that commit_id is a 'numeric ID' and commit_uuid is a 'UUID', and restates the default for branch_name. However, it does not explain the relationship between commit_id and commit_uuid (e.g., whether one is sufficient, which takes precedence, or the behavior when both are provided), which is essential for correct invocation.

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: 'Switch schema to a specific commit in a branch' (Переключить схему на конкретный коммит в ветке). It uses a specific verb and resource, and distinguishes itself from sibling 'checkout_branch' by mentioning 'commit' rather than 'branch'. However, it does not explicitly contrast with other version-control tools like 'reset_branch', leaving some ambiguity about exact scope.

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 such as checkout_branch, reset_branch, or merge_branches. It does not state when not to use it or mention any prerequisites, leaving the selection entirely to the agent's inference from tool names.

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. While it states that a commit is created, it does not mention potential side effects, authorization requirements, branch existence requirements, or conflict behavior, leaving the mutation behavior underexplained.

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: a one-sentence purpose followed by a tight Args block. Every line contributes useful information, and there is no repetition of the schema structure or padded text.

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 output schema is present, so return value documentation is not necessary. However, for a commit-creating mutation with no annotations, the description lacks important preconditions and caveats (e.g., branch existence, whether the commit mutates the schema), making it only minimally 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?

Although schema coverage is reported as 0%, the description text actually includes an Args block that explains each parameter: project_uuid, schema_uuid, and branch_name with its default. This adds semantic meaning beyond the bare schema titles and helps the agent understand parameter roles.

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+resource+scope statement. It clearly conveys the action and target, but does not explicitly differentiate itself from the sibling 'commit_to_branch' 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?

The description provides no guidance on when to use this tool versus alternatives like 'commit_to_branch', nor any preconditions such as whether the branch must already exist. The only usage hint is the default branch name in the Args block, which is not sufficient.

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 does not explain side effects, whether the operation is destructive/reversible, or what 'detached' commit means, leaving critical behavioral traits undisclosed.

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 crisp summary followed by a clean parameter list. Every line is useful and scannable, with no redundant 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?

Even though an output schema exists, the description lacks usage guidance, behavioral context, and clarity on the detached-commit flow. It leaves the agent uninformed about branch selection rules and relationship to sibling commit_schema, making the tool's overall context incomplete.

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?

With 0% schema description coverage, the description provides Russian one-line explanations for each parameter, adding some meaning beyond the bare titles. However, it does not clarify concepts like 'detached_target_branch_name' or constraints on branch_name, so compensation 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 states 'Зафиксировать изменения схемы коммитом в ветке' (commit schema changes in the branch), clearly identifying the verb, resource, and context. However, it does not differentiate from the sibling tool 'commit_schema', leaving ambiguity about which tool to choose.

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. It only lists arguments without mentioning prerequisites, exclusions, or scenarios where commit_schema or other branch tools would be preferable.

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 burden of behavioral disclosure. It does not mention side effects (e.g., whether the new branch becomes active), permission requirements, error conditions, or whether the branch is created locally or remotely. The description merely lists parameters without explaining the operation's behavior beyond the fact that it creates a branch.

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, with a one-line summary followed by a formatted parameter list. It is front-loaded with the purpose. The formatting is slightly inconsistent but overall 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?

Despite having an output schema, the description does not explain what the tool returns or any behavioral context such as error handling, required project state, or interaction with other branch operations. Given the tool's complexity and the presence of sibling tools, the description is too minimal to fully guide an agent in all scenarios.

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 description provides meaningful explanations for all four parameters (project_uuid, branch_name, source_branch, is_default) in Russian, which compensates for the schema's lack of descriptions (0% coverage). For example, it clarifies that source_branch defaults to 'main' and is_default controls default status. This adds value beyond the schema's titles.

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 Russian description 'Создать новую ветку проекта' clearly states the action (create) and resource (project branch). It is specific enough to understand the tool's primary function, but it does not explicitly differentiate from sibling tools like fork_branch or checkout_branch, which also deal with branches.

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 use this tool versus alternatives. The description lacks any context about prerequisites, such as whether a project must exist or whether this tool is preferred over creating a branch via another method. No exclusions or alternative recommendations are provided.

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, and the description does not disclose side effects such as whether changes are persisted immediately, require a commit, or affect branches. The bare statement 'Add a column' provides minimal behavioral context for a mutation 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?

The description consists of one concise sentence followed by a structured Args list. It is appropriately sized for eight parameters and avoids unnecessary verbosity.

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?

While the output schema likely covers return values, the description omits critical context about branch-based workflows (e.g., needing to commit after creation) and preconditions. This makes it incomplete for a schema-management tool that operates on 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 Args section explains every parameter, including examples for column_type and column_default. Since the schema itself provides only titles and defaults (0% coverage), the description fully compensates by adding meaningful semantics.

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 'Добавить колонку в таблицу' ('Add a column to a table'), using a specific verb and resource. This clearly distinguishes it from sibling tools like edit_column and delete_column.

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. The description only states the action and parameter definitions, with no mention of preconditions, branch workflows, or when another tool would be more appropriate.

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 of behavioral disclosure. It states that it creates a group for visual organization, which implies a non-destructive write operation, but it does not disclose whether this affects the schema version, requires permissions, is reversible, or what happens to associated tables. Essential side-effect information is absent.

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 clear sentence followed by a structured list of parameter explanations. It is not verbose, but the full list repeats parameter names already present in the schema. Still, the explanations make the list valuable. The main statement is front-loaded and direct.

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 tool has 10 parameters and an output schema, the description covers the purpose and parameter meanings sufficiently. The only missing contextual element is usage guidance (when to use vs. alternatives). For a straightforward create operation, this is near complete, but not fully.

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 provides only bare titles, while the description adds a meaningful one-line explanation for every parameter (e.g., schema_uuid: 'UUID схемы', position_x: 'Координата X группы на холсте'). This significantly enriches schema understanding and correctly covers all 10 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 clearly states 'Создать группу таблиц в схеме (для визуальной организации)' — 'Create a group of tables in the schema (for visual organization).' This uses a specific verb and resource, and 'для визуальной организации' explains the purpose. It distinguishes from sibling tools like edit_group and delete_group by indicating it is a creation action.

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 use this tool versus alternatives. It does not mention that editing groups should use edit_group or deleting should use delete_group, nor any prerequisites or conditions. The description merely lists parameters and provides no contextual usage direction.

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 are absent, so the description must disclose behavioral traits. It only states the creation action without mentioning side effects, permissions, idempotency, or error conditions. This is insufficient for a create 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?

The description is extremely concise, with a one-line action statement and a bullet list of parameters. Every word serves a purpose, and the structure is clean.

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 create tool with an output schema, the description is minimally adequate. However, it lacks any mention of return behavior or prerequisites, and the parameter guidance is superficial. A bit more detail would improve 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?

The schema has no descriptions beyond titles. The description adds Russian labels for project_name and project_description and clarifies that the description is optional, but these labels merely mirror the schema titles. It does not explain constraints or formats.

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 begins with 'Создать новый проект.' (Create a new project), which directly states the action and resource. This clearly distinguishes it from sibling tools like edit_project and delete_project.

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 provided about when to use this tool versus alternatives. It does not mention that list_projects exists for viewing existing projects or edit_project for modifications.

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 are missing, so the description carries the full burden. It mentions 'create' (a mutation) but does not disclose side effects, permissions, or the impact on the schema. This is a notable gap for a creation 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?

The description opens with a concise purpose sentence followed by a structured docstring. While it is long due to 10 parameters, the content is necessary given zero schema descriptions and avoids unnecessary prose.

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 description covers all parameters with explanations and examples, making it sufficient for invoking the tool correctly. However, it does not mention side effects or the need to commit changes, which might be relevant context for a schema-modifying operation.

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 zero descriptions for its 10 parameters (0% coverage). The docstring compensates by explaining each parameter's role, clarifying FK/PK sides, providing examples for relationship_type, and enumerating delete/update actions. This adds meaningful semantic information beyond the schema.

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 that this tool creates a relationship (foreign key) between two columns. It uses a specific verb and resource, distinguishing it from siblings like delete_relationship and edit_relationship.

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 by defining the action, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. The parameter list gives context for how to use it, but no explicit 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?

With no annotations provided, the description must disclose behavioral traits on its own. It only states the action (creating a schema) but does not mention potential side effects, idempotency, duplicate handling, or required permissions. For a mutating operation, this is a significant transparency 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?

The description is concise and well-structured: a single opening sentence followed by an Args block that lists parameters. Every sentence contributes value without unnecessary elaboration.

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 tool's simplicity, output schema presence, and parameter explanations, the description is largely complete. It lacks behavioral details like error handling or prerequisites, but these are not critical for a straightforward create operation and are partly covered by the output schema.

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 no parameter descriptions (0% coverage), but the tool description compensates by explaining each parameter: project_uuid is the project's UUID, schema_name is the schema name with examples, and schema_description is optional. This adds meaningful context beyond the bare schema.

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 creates a new schema in a project, using a specific verb and resource. It is distinct from sibling tools like create_table, create_project, and edit_schema, leaving no ambiguity about its function.

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 when a new schema needs to be created, but provides no explicit guidance on when to use this tool versus alternatives (e.g., edit_schema for modifying, delete_schema for removing). No exclusions or preferred scenarios 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?

There are no annotations, and the description only states that it creates a sync job. It does not disclose whether the job runs immediately, whether it is idempotent, what permissions are required, or what side effects occur on the target 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 a concise docstring with a one-sentence summary followed by a flat list of parameters. No redundant information or lengthy caveats, every line serves a purpose.

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?

Although the tool is complex with 8 parameters and no annotations, the description explains all parameter meanings and an output schema exists, so return values are covered. However, it lacks expected usage context and behavioral caveats such as whether the operation is reversible or asynchronous, leaving some completeness 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?

The input schema has no descriptions for any parameters, but the description compensates by listing all 8 arguments with brief Russian explanations, including enum-like values for import_scope ('one_schema' or 'whole_database') and import_mode ('replace' or 'merge'). It also clarifies that agent_schema_uuid is for one_schema scope.

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 the verb 'Создать' (create) with a specific resource 'задачу синхронизации структуры базы' (database structure sync job), which clearly differentiates it from sibling tools like list_sync_jobs and get_sync_job.

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. It does not mention listing, retrieving, or deleting sync jobs, nor any prerequisites like establishing a data source or agent connection.

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 must fully disclose behavioral traits. It does not mention side effects, permissions, idempotency, or whether changes require a commit or affect branches. The provided defaults and column format relate to parameter semantics, not behavioral transparency.

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 front-loaded purpose sentence followed by an Args list. It is slightly long but each parameter explanation adds value, and the columns example is particularly useful.

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 7 parameters and no annotations, the description covers parameter semantics thoroughly but lacks broader workflow context, such as whether changes are staged, need committing, or affect the visual canvas beyond simple coordinates. The presence of an output schema handles return values, but the tool's role in the schema editing process is not explained.

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 JSON schema contains only titles with no descriptions (0% coverage). The description explains every parameter in detail, including the structure of columns with an example, coordinate semantics, color defaults, and branch context. This substantially adds meaning beyond the schema.

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 begins with 'Создать таблицу в схеме' (Create a table in the schema), which clearly identifies the action and resource. It distinguishes from sibling tools like edit_table, delete_table, and create_schema by specifying exactly what is 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?

Usage guidance is implicit: the description states the purpose and lists required parameters (schema_uuid, table_name), so an agent can infer this tool is for adding a new table. However, there is no explicit direction on when to use this versus alternatives, or any prerequisites or 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 only says 'delete column' without mentioning irreversibility, cascading effects, permissions, or error conditions, which is a significant gap for a destructive 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?

The description is compact and front-loaded with the action, followed by a clear Args list. There is no fluff or repetition; every sentence contributes necessary 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 destructive tool with no annotations, the description is incomplete. It does not explain branch-specific behavior, what happens to dependent data, or any constraints on deletion. The output schema is present, so return values are not needed, but behavioral and usage context 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%, and the description compensates by listing all four parameters with brief glosses (e.g., 'schema_uuid: UUID схемы'). This adds meaning beyond the bare property titles, though the explanations are shallow and mostly restate the parameter type.

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 'Удалить колонку из таблицы' (Delete column from table), which is a specific verb and resource. It clearly distinguishes this tool from siblings like delete_table, delete_relationship, and create_column.

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 use this tool versus alternatives, no preconditions, and no exclusions. The existence of related delete tools is not mentioned, leaving usage inference entirely to the tool 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 provided, the description carries the full burden of disclosing behavior, but it only states the action. It does not mention side effects, such as whether the underlying data source is deleted, or dependencies like existing tables that may be affected. The lack of such disclosure is a significant gap for a delete 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?

The description is extremely concise and well-structured: a single clear purpose statement followed by an Args section. There is no redundancy or unnecessary verbiage, making it easy to parse quickly.

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?

Although an output schema exists (so return values need not be explained), the description lacks important contextual details about the operation's impact. For a delete tool, it should clarify what happens to the data source, whether the action is reversible, and any prerequisites or constraints. The current description is minimal and leaves critical questions unanswered.

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 only parameter, project_uuid, is described as "UUID проекта," which merely repeats the schema's property title and type. Schema description coverage is 0%, so the description must compensate, but it adds no new meaning beyond what is already present in the schema field.

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 deletes the binding between a project and a data source agent ("Удалить привязку проекта к агенту-источнику данных"). It uses a specific verb and resource, and it distinguishes itself from sibling delete tools (delete_project, delete_schema) by targeting the data source binding specifically.

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 no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states the action without contextualizing the operation, leaving the agent without direction on when this tool is appropriate.

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 burden of behavioral disclosure. It does disclose the key non-destructive-to-tables behavior ('таблицы остаются в схеме'), adding value beyond the tool name. However, it omits other potentially important behaviors such as effects on relationships, branch behavior, or reversibility, leaving the agent with incomplete information.

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, front-loads the primary purpose, and includes only a minimal parameter list. 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 is simple and an output schema exists, so return values need not be described. The description covers the core side effect (tables remain) and parameters. It could be more complete by noting relationship handling or error scenarios, but for a delete-group operation it is reasonably sufficient.

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 description includes a brief Args list (schema_uuid: UUID схемы, group_uuid: UUID группы, branch_name: Ветка схемы), but these are essentially restatements of the parameter names, and the schema already provides the default for branch_name. With 0% schema description coverage, the description does not meaningfully compensate by explaining formats, constraints, or usage nuances.

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 it deletes a group of tables ('Удалить группу таблиц') and adds the crucial qualifier that the tables themselves remain in the schema. This verb+resource+scope distinguishes it from sibling tools like delete_table, delete_schema, and delete_relationship.

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 by indicating that it deletes a group while preserving tables, but it provides no explicit when-to-use guidance, exclusions, or alternative tool references. Unlike higher-scoring tools, there is no mention of when to prefer this over delete_table or delete_schema.

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. It discloses the cascading destructive behavior (schemas, tables, relationships) but lacks details on irreversibility, required permissions, or other affected entities like branches or sync jobs.

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 extremely concise and front-loaded, with two sentences covering the essential information. 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 is a simple delete with one parameter, but the description omits critical safety context such as reversibility, confirmation, or side effects on other data. The cascading scope is mentioned, but for a destructive tool this is insufficient.

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 the description only restates 'project_uuid: UUID проекта,' adding minimal meaning. It does not explain how to obtain the UUID, constraints, or related context.

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 'delete' with a clear resource 'project' and specifies the scope: 'together with all its schemas, tables, and relationships.' This distinguishes it from sibling tools like delete_schema or delete_table.

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 for deleting an entire project and its contents but does not explicitly state when to use it over alternatives or any exclusions. It is clear from context but not explicitly 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?

With no annotations, the description carries full responsibility for behavioral disclosure. It merely states that the tool deletes a relationship but does not mention irreversibility, side effects, permission requirements, or what happens to dependent data. This is a significant transparency gap for a destructive 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?

The description is a single, clear sentence followed by a compact list of parameters with translations. Every element serves a purpose, with no fluff or repetition. The structure is front-loaded with the action and then provides essential argument details.

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 values need not be described. However, the description omits behavioral context such as side effects, reversibility, and the role of branch_name beyond a generic 'schema branch'. It is adequate for a straightforward delete operation but lacks depth for a branching-aware destructive action.

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 description includes a brief explanation for each parameter (schema_uuid, relationship_uuid, branch_name), which adds meaning beyond the raw schema that has no parameter descriptions. Even though schema coverage is 0%, the description compensates by identifying the role of each argument.

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 the imperative 'Удалить' (delete) with a specific resource 'связь между таблицами' (relationship between tables), making it unambiguous. It clearly differentiates from sibling tools like create_relationship and edit_relationship, as well as delete_table and delete_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?

No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description is a bare command with parameter names, leaving the agent to infer usage solely from the tool name and general CRUD context.

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 openly discloses the destructive cascading nature by stating it deletes the schema together with all tables, columns, and relationships. This covers the primary behavioral trait, though it omits details like reversibility or permissions.

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 focused sentence followed by two simple parameter lines. There is no filler, and the main action is front-loaded. Every word contributes to clarity.

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 that this is a destructive operation with two parameters and an output schema present, the description effectively explains the scope of deletion and the parameter meanings. It does not discuss prerequisites or potential side effects beyond deletion, but for a delete tool this 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?

With 0% schema description coverage, the description compensates by including an Args section that defines each parameter: 'project_uuid: UUID проекта' and 'schema_uuid: UUID схемы'. This adds meaning beyond the bare type/title in the schema, though it does not give additional constraints or formats.

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 the specific verb 'Удалить' (delete) with the resource 'схему' (schema) and explicitly states it removes all associated tables, columns, and relationships. This clearly distinguishes it from sibling tools like delete_table or delete_relationship, which target narrower resources.

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 when a complete schema and its contents need to be removed, as it lists all elements that will be deleted. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select it appropriately.

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 burden of behavioral disclosure. It discloses that the deletion cascades to columns and relationships, but does not mention permanence, reversibility, permission requirements, or impact on branches/commits. For a destructive operation, this lacks critical safety and side-effect information.

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 main description is a concise single sentence that front-loads the core action. The Args block is slightly redundant with the schema but is concise and organized. No unnecessary filler is present.

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 tool with no annotations, the description is incomplete. It does not mention reversibility, permissions, branch/commit implications, or what happens to related data beyond columns and relationships. The presence of an output schema does not cover these operational concerns, leaving gaps for an agent to safely invoke the tool.

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 no descriptions for parameters, so the description's Args block adds some meaning (e.g., schema_uuid is UUID of schema, branch_name defaults to main). However, this largely restates the property names and types, and doesn't explain formats or constraints beyond the schema defaults. It adds minimal value but partially compensates for the low 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 states a clear action: 'Удалить таблицу вместе с колонками и связями' (Delete the table along with its columns and relationships), specifying the resource (table) and the scope (cascades to columns and relationships). This distinguishes it from sibling tools like delete_column, delete_relationship, and delete_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?

The description implies when to use this tool (to delete a whole table and its dependent structures) but does not explicitly state when not to use it or mention alternatives such as delete_column for partial deletions. No conditional or failure context is provided.

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, and the description does not disclose any behavioral traits such as side effects, permissions required, or impact on data. It only lists inputs, leaving the agent unaware of consequences.

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 compact docstring with a one-line purpose followed by an Args list. It is structured and not overly verbose, though the parameter list largely duplicates 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 complex mutation tool with no annotations, the description omits important contextual information such as whether changes are branch-local, whether at least one property is required, and what the output indicates. The presence of an output schema doesn't excuse the lack of usage context.

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 description provides Russian glosses for each parameter (e.g., 'column_name: Новое название колонки'), but most are direct translations of the schema field names. It adds some semantic value by marking fields as 'new' and noting the branch_name default, but does not fully compensate for the 0% schema description 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 opens with 'Изменить свойства колонки' (Change column properties), clearly indicating a mutation on a column. It lists the affected fields, distinguishing it from create/delete operations, but does not explicitly contrast with sibling tools like edit_table.

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 provided. The description only states what the tool does and lists parameters, without mentioning alternatives, prerequisites, or typical scenarios.

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, but it only lists parameters without revealing side effects, error conditions, or whether changes are committed to a branch. The overwriting nature of 'новые' (new) values is implied but not explicitly 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 concise one-sentence purpose followed by a parameter list with no extraneous text. Every line adds value, and the structured list is easy to scan, making it efficient for an AI agent to parse.

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 parameter documentation is thorough enough for an agent to invoke the tool correctly, and the presence of an output schema removes the need to describe return values. The main gap is the absence of any mention of prerequisites (e.g., the group must exist) and relationship to sibling tools, but overall it is reasonably 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?

The description provides a detailed meaning for all 11 parameters (e.g., 'Новая координата X', 'Новый цвет группы в HEX', 'Новое описание группы'), which the schema itself lacks (0% coverage). This gives an agent sufficient semantic understanding to correctly supply 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 clearly states the action ('Изменить свойства группы таблиц' - change properties of a group of tables) with a specific resource. The verb 'Изменить' distinguishes it from sibling tools like create_group and delete_group, making 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 provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states the function without referencing create_group for creation or delete_group for deletion.

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 only states that the tool modifies name/description but does not disclose any side effects, required permissions, behavior on non-existent projects, or return/error semantics.

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 opens with a succinct one-sentence purpose, followed by a structured Args list. It is compact and has no unnecessary prose, though the Args block partially duplicates schema property names.

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 edit tool, the description covers the essential action and parameters. However, it omits any prerequisites (e.g., project must exist) or error conditions, and there is no annotation to fall back on. The output schema exists, so return values need not be described.

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 no parameter descriptions (0% coverage), but the 'Args' section in the description explains each parameter: project_uuid as UUID, and the other two as new values with '(если нужно изменить)' clarifying they are optional. This 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 states a specific verb ('Изменить' = change) and resource ('проекта' = project) with exact fields ('название и/или описание' = name and/or description), clearly distinguishing it from sibling edit tools for schema, table, column, etc.

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 usage context is implied by the purpose: use this tool when you need to change a project's name or description. However, there is no explicit guidance about when not to use it or mention of alternatives, leaving the agent to infer.

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 burden. It lists parameters but does not disclose behavioral traits such as whether updates are partial, whether the relationship must exist, what side effects occur, or how branch_name affects the operation. It only says 'change properties' without 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?

The description is concise: one sentence stating purpose followed by a parameter list. No unnecessary prose. It could use more structured formatting or grouping, but it's 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?

Despite having an output schema, this is a complex 11-parameter mutation tool with no annotations. The description only lists parameters and lacks usage context, branch behavior, partial update semantics, and relationship to other CRUD tools. It is insufficient for an agent to invoke confidently.

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 description provides a line for each parameter, but most are simple translations of the parameter name (e.g., 'UUID схемы' for schema_uuid). Some add meaning, like 'Новое название связи' (new relationship name) and 'Новое действие при удалении' (new delete action), conveying that these are replacement values. However, there are no examples, allowed values, or constraints beyond the schema defaults.

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 begins with 'Изменить свойства связи' (Change relationship properties), which clearly states the action (change) and resource (relationship). It distinguishes from siblings like create_relationship and delete_relationship by the verb, though it doesn't explicitly say 'existing relationship'.

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. It doesn't mention that create_relationship is for new relationships or that delete_relationship removes one. There is no context, prerequisites, or 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 provided, the description must disclose behavioral traits. It simply says 'change name and/or description' with no mention of side effects, reversibility, permissions, or impact on other schema components. For a mutation tool, this is insufficient.

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 and front-loaded with the main purpose. The Args block is well-structured and not overly verbose. Each sentence earns its place, though the parameter descriptions are 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?

The tool has an output schema, so return values are handled. The description covers the purpose and parameters, but lacks usage context and behavioral side effects. For a simple metadata update, it is adequate but not fully complete due to the missing guidelines and transparency.

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 Args block provides Russian descriptions for all parameters, adding meaning beyond the bare schema names. It clarifies that schema_name is the new name and schema_description is optional, which is valuable. However, it largely restates the parameter names with minimal elaboration.

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 ('Изменить' = change/update) and the target resource (схема = schema), specifying the exact scope: 'название и/или описание' (name and/or description). This distinguishes it from sibling tools like create_schema, delete_schema, and commit_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?

No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing an existing schema, nor does it clarify that this tool only updates metadata without affecting structural elements like tables or relationships. Usage is only implicitly understood from the function 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?

No annotations are present, so the description must disclose behavior. It only says 'изменить свойства' without mentioning that this is a mutating operation on a branch, whether changes require a commit, or any side effects. The branch_name parameter is listed but its behavioral significance is not explained.

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 brief and front-loaded with the main purpose. The Args list is concise, though it partially duplicates 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?

The tool is a mutation on a schema branch, but the description does not explain the branching context or the need to commit after editing. While an output schema exists, the behavioral context of editing (e.g., that it modifies the working version) 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 Args section provides basic descriptions for each parameter (e.g., table_color: 'Новый цвет в HEX'), which helps understand the parameters. However, given 0% schema coverage, the descriptions are minimal and do not clarify optionality, constraints, or interactions between parameters (e.g., whether position_x/y must be provided together).

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: 'Изменить свойства таблицы' (edit table properties) and lists the editable properties (name, position on canvas, color). This clearly distinguishes it from sibling tools like create_table or batch_edit_tables.

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 alternatives like batch_edit_tables or edit_schema. The context implies it is for editing a single table, but no exclusions or alternative recommendations are provided.

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 burden of behavioral disclosure, but it only restates the export action and parameter meanings. It does not state whether the operation is read-only, what the returned DDL includes, whether special permissions are needed, or how branch_name affects the output.

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 extremely concise and front-loaded with the core purpose, followed by a compact Args list. Every line earns its place, with 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 simple 3-parameter export tool with an output schema, the description covers the main parameters and the outcome. However, the absence of annotations and usage guidance leaves gaps in side-effect transparency and alternative selection, making it 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?

Although schema description coverage is 0%, the Args block adds meaningful semantics: schema_uuid is 'UUID схемы', dialect is 'Диалект SQL' with default 'postgres', and branch_name is 'Ветка схемы' with default 'main'. This compensates for the lack of parameter descriptions in the input schema, though it does not enumerate allowed dialect 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 opens with the specific verb-resource phrase 'Export schema to SQL DDL' (Экспортировать схему в SQL DDL), clearly stating what the tool does and its output format. This distinguishes it from sibling operations like import_sql_into_schema or get_branch_migration.

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 is given about when to use this tool vs alternatives, such as preferring DDL export over get_branch_migration or ai_apply_schema. The only implied usage is the verb 'export', but there are no prerequisites, exclusions, or comparisons to other 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?

The description adds some behavioral context by explaining the flags (create_target_if_missing, overwrite_target, is_default) in the Args block, but it does not disclose side effects, permissions, or broader implications. With no annotations, the description carries the burden, yet it remains limited.

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 reasonably concise with a clear opening sentence and a structured parameter list. However, the Args block largely duplicates the input schema, making it somewhat redundant and not as tight as it could be.

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 moderately complex branch fork operation, the description covers core parameters and their effects. It doesn't address conflicts, permissions, or migration behavior, but the presence of an output schema makes detailed return documentation unnecessary. Overall, it is adequate but not comprehensive.

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?

Although the schema has 0% description coverage, the description includes a parameter list with brief but meaningful explanations for each argument, such as 'Создать целевую ветку, если её нет.' (Create target branch if missing). This compensates for the schema's lack of descriptions, though not extensively.

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: 'Создать ветку из другой ветки (fork) в проекте' (Create a branch from another branch (fork) in the project). It uses a specific verb and resource, and distinguishes itself from the sibling create_branch by emphasizing 'from another branch'.

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 create_branch or merge_branches. It simply describes the action without any context, prerequisites, or 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 provided, the description must disclose behavioral traits. It describes a 'get' operation, which implicitly suggests a read-only, non-destructive action. However, it does not explicitly state read-only status, potential side effects, permissions, or error behavior, relying on the verb 'get' to imply safety.

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 and well-structured: a single-sentence purpose statement followed by a clean list of parameters. Every element earns its place, with no redundant text 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?

The tool has a modest parameter set (3), an output schema, and no annotations. The description clearly articulates the tool's purpose and parameters, and the output schema covers return values. The main gap is the lack of explicit usage guidance, but overall it provides sufficient context for a simple getter.

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 0% description coverage, so the description must compensate. It provides brief definitions for all three parameters (project_uuid, schema_uuid, branch_name), but most are mere restatements of the parameter names (e.g., 'UUID проекта' for project_uuid). The only additional semantic value is the explicit default for branch_name ('main').

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: 'Get SQL migration between base and current commit of the branch.' It uses a specific verb ('get') and a distinct resource ('SQL migration') with a defined scope. This distinguishes it from all sibling tools, which focus on other branch operations like checkout, merge, or commit.

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 when a SQL migration diff is needed between a branch's base and current commit, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. No alternative tools are referenced.

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 were provided, so the description carries the transparency burden. It adds some behavioral context by explaining that 'limit' caps the maximum number of commits, but it does not disclose side effects, return semantics, or potential limitations (e.g., scope of included branches).

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 and well-structured: a single sentence stating the core purpose followed by a compact Args list. Every sentence earns its place with no redundancy.

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 2 parameters and an output schema, the description covers the essential purpose and parameter semantics adequately. It lacks usage context and nuances about the graph's scope, but it 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?

The description includes an Args block that clearly explains both parameters: project_uuid is the project UUID and limit is the maximum commit count (default 200). Since schema description coverage is 0%, this fully compensates and adds meaning beyond the bare schema.

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: 'Получить направленный граф коммитов проекта (историю изменений)' (get the directed commit graph). This is a specific verb+resource combination that distinguishes it from sibling commit-related tools like checkout_commit or get_branch_migration.

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 provided on when to use this tool versus alternatives. The description only explains what it does, leaving the agent to infer context. It does not mention exclusions or compare to other commit-history 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?

No annotations are provided, so the description carries the full burden. It discloses no behavioral details such as read-only nature, error conditions if the binding doesn't exist, or any side effects. The name 'get' implies retrieval, but the description itself does not confirm safety or other traits.

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 very brief with no wasted words, front-loading the core purpose. However, it is structured as a docstring with an 'Args' block, which is acceptable but not as clean as a single natural-language sentence.

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 getter with an output schema, the description provides the essential purpose and argument, but lacks context about when to use it or what 'binding' represents. It is minimally sufficient for invocation but not for confident selection among siblings.

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 description only repeats the parameter name and provides a redundant Russian translation ('UUID проекта'), adding no meaning beyond the schema. With 0% schema description coverage, the description fails to compensate with any additional context about the parameter.

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 retrieves the binding of a project to a data-source agent, using a specific verb ('get') and resource ('binding'). This distinguishes it from sibling tools like set_data_source and delete_data_source, though it doesn't explicitly differentiate from other getters like get_commit_dag.

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 provided on when to use this tool versus alternatives. The description only states what it does and the argument, with no mention of use cases, prerequisites, or 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. It implies a read-only operation ('understand the current state'), but does not explicitly state that it makes no modifications or require any special permissions. It also doesn't describe the return format, though an output schema exists. This is adequate but not exceptional.

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 summary, a usage sentence, and an Args section. It's concise and front-loaded with the main purpose. The Args block is slightly repetitive of the schema but valuable given the lack of schema descriptions. 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 only two parameters and an output schema, so the description doesn't need to explain return values. It provides a good overview of what the tool returns (tables, columns, relationships, groups) and when to use it. It's complete for a read-only inspection tool, though it could mention branch behavior or read-only nature explicitly.

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 provides an Args block explaining schema_uuid as the schema's UUID and branch_name as the branch (default main), adding meaning beyond the bare parameter names and types. This helps the agent understand the parameters, though it doesn't go into details like valid values or formats.

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 retrieves the full schema structure: tables, columns, relationships, groups. This specific verb+resource clearly distinguishes it from siblings like list_schemas (which lists schemas) or get_commit_dag (which deals with commits).

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 explicitly tells the user to use this tool to understand the current schema state before making changes, giving clear context for when to use it. It does not mention alternatives or when not to use, but the guidance is sufficient for a read-only inspection tool.

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 burden. It only states that it gets status and details, which implies a read operation, but it does not disclose whether any permissions are required, what happens if the job does not exist, or that the operation has no 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 that directly states the purpose and lists the arguments, making it front-loaded and free of unnecessary words. It is appropriately sized for the simple 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?

While the tool has only 2 required string parameters and an output schema, the description lacks any usage context, such as whether job_uuid is globally unique or project-scoped, and it does not mention error behavior or when to prefer this over list_sync_jobs.

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 description repeats the parameter names and their types (UUIDs) from the schema without adding any additional meaning, such as the relationship between project_uuid and job_uuid or how to specify the job. With schema description coverage at 0%, the description fails to compensate.

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 states 'Get status and details of a synchronization job' with a clear verb ('get') and resource ('sync job'), and the inclusion of job_uuid distinguishes it from list_sync_jobs. It concisely conveys the tool's purpose.

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 provided on when to use this tool versus list_sync_jobs or create_sync_job, nor any exclusions or prerequisites. The agent cannot infer appropriate usage from the description 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 burden. It discloses that it creates tables, columns, and relationships, but does not mention potential destructive aspects (e.g., if SQL contains DROP statements) or how existing objects are handled. The prerequisite about schema existence is helpful, but more context would be needed for full transparency.

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 and front-loaded with the main action, followed by a brief support note and a clear Args block. Every sentence serves a purpose, and the structure makes it 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 tool's complexity (parsing and applying SQL DDL) and the presence of an output schema, the description covers the essential purpose, prerequisites, and parameters. It does not discuss error handling or partial application behavior, but the core information is sufficient for an agent to decide when to use it.

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 fully compensates by explaining each parameter. schema_uuid identifies the target schema, sql is described as DDL text with examples, and branch_name is explained with its default. This adds meaningful semantics beyond the bare parameter 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 clearly states the action: import SQL DDL into a schema, creating tables, columns, and relationships. It distinctly differs from siblings like export_schema_sql or manual table creation tools by focusing on full PostgreSQL DDL import.

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 a key usage prerequisite: the target schema must already exist. It also notes full PostgreSQL DDL support and mentions branch selection, providing clear context. It does not explicitly compare to alternative tools, but the purpose is clear enough.

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 only says 'list branches', which implies read-only, but it does not explicitly state whether it is safe, what it returns, or any potential failure modes. No extra context is added.

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 very concise, consisting of one sentence and an argument list. It is appropriately sized for a simple tool and avoids unnecessary verbosity. However, the structure is a bit docstring-like, but it is not bloated.

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 that the tool is part of a larger branch management set (e.g., create_branch, merge_branches), the description lacks context about what branches are in this project domain, when to list them, or how this fits with other operations. The output schema exists, so return values need not be described, but the description is too minimal to be helpful for an agent deciding among siblings.

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 mentions 'project_uuid: UUID of the project', which adds a small amount of meaning beyond the schema's 'Project Uuid' title, but it is essentially redundant and lacks any deeper explanation of the parameter's usage or format.

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 'Get a list of project branches', which is a specific verb and resource. It distinguishes from sibling tools like create_branch, fork_branch, and merge_branches by indicating a list operation, though it does not explicitly contrast with other list 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?

There is no guidance on when to use this tool versus alternatives. It does not describe any prerequisites, exclusions, or context in which listing branches would be appropriate compared to other branch-related operations.

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 burden of behavioral disclosure. It adds useful context that results are scoped to the current user, but it does not explicitly state that the operation is read-only, nor does it mention pagination, sorting, or whether archived projects are included. For a simple list tool this is acceptable but leaves some gaps.

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, concise sentence in Russian that directly states the tool's purpose. Every word earns its place, and there is no redundant or filler 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?

Given the tool's simplicity (no parameters, output schema present), the description is mostly complete. It could clarify whether results include only active projects or also archived ones, but overall it provides sufficient context for an agent to select and invoke the tool 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?

The tool has zero parameters, so the description does not need to explain parameter semantics. According to the rubric, zero-parameter tools receive a baseline of 4, and the description correctly implies no arguments are needed.

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: 'Get list of all projects available to current user.' It uses a specific verb ('get') with a resource ('projects') and a scope ('available to current user'), distinguishing it from sibling tools like create_project, edit_project, and delete_project.

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 tool is for retrieving projects for the current user, which is clear from context. It does not explicitly mention when not to use it or suggest alternatives, but given the sibling list, this is the only project-listing tool, making the usage context evident.

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 must disclose behavioral traits. It only says 'Get list', which implies a read operation, but it does not mention side effects, return format, ordering, pagination, or error behavior. Without annotations, this is a significant gap for a tool that could have hidden behaviors.

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 extremely concise, consisting of a single sentence and the parameter listing. It is front-loaded with the main action and wastes no words. For a simple list tool, this is an appropriate size.

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 a single parameter and an output schema exists, which reduces the need to explain return values. However, the description lacks usage guidance and behavioral transparency, making it only minimally complete. It is adequate for a very simple read operation but leaves gaps in context.

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 description repeats the parameter name 'project_uuid' and calls it 'UUID проекта', which adds no information beyond the schema's property title. Schema description coverage is 0%, so the description should compensate, but it does not provide any additional semantics about the parameter, such as format validity or project lookup specifics.

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: 'Получить список схем внутри проекта' (Get list of schemas inside a project). It uses a specific verb 'list' and a resource 'schemas', and it is distinct from sibling tools like create_schema or delete_schema. This is a precise and unambiguous purpose.

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. It simply states what it does, without noting any exclusions, prerequisites, or alternative tools. There is no explicit or implicit comparison to siblings, leaving the agent to infer usage from context 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 provided, the description carries the full burden. It only states the basic operation and does not disclose return format, pagination, ordering, or side effects. However, it is not misleading.

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 brief and front-loaded with the action. The Args block is somewhat redundant with the schema, but it is compact and does not waste much space.

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 is minimally adequate but lacks context about what the returned list includes, any limits, or how it relates to get_sync_job and create_sync_job. No annotations compensate for this.

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 description repeats the parameter name and meaning ('project_uuid: UUID проекта') without adding constraints, format details, or context beyond the schema. Since schema description coverage is 0%, the description fails to compensate.

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 + resource + scope: 'Получить список задач синхронизации (sync-jobs) проекта' (Get list of project sync jobs). It clearly distinguishes from siblings like get_sync_job (singular) and create_sync_job (creation).

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 is given about when to use this tool versus alternatives. It does not mention get_sync_job for single-job retrieval, nor does it specify scenarios where listing is preferred.

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 must carry full behavioral context. It only states the action and lists parameters; it does not disclose side effects such as whether a merge commit is always created, what happens on conflicts, whether the source branch is deleted only if the flag is set, or the nature of the result.

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, with a single purpose sentence followed by a parameter list. The structure is clear and front-loads the main action, though the Args block is somewhat redundant with the schema and could be trimmed.

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 branching tool with side effects, the description is incomplete. It lacks context on behavior like conflict handling, workspace state changes, output semantics, and error scenarios. While an output schema exists, it does not compensate for these behavioral 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?

The Args section adds brief glosses for each parameter (e.g., 'UUID проекта' for project_uuid), which is somewhat helpful given the schema has 0% description coverage. However, the glosses largely restate the parameter names (source_branch -> 'Ветка-источник') and do not provide additional constraints or format 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?

The description clearly states the tool's function: 'Слить исходную ветку в целевую' (merge source branch into target branch). It uses a specific verb and identifies the key resources, distinguishing it from sibling tools like list_branches or create_branch.

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, prerequisites, or alternatives. It does not mention conditions like clean working tree, conflict resolution, or when merging is appropriate, leaving the agent without usage context.

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 behavioral disclosure burden. However, it only lists parameters and their types/defaults, without explaining the consequences of soft vs. hard reset, the meaning of 'force', or potential side effects on uncommitted changes or branch history. This is insufficient for a mutation tool that could be destructive.

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: a one-line purpose followed by a compact parameter list. There is no fluff, and the purpose is front-loaded. The parameter list is a bit mechanical but acceptable for a docstring-style 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?

For a potentially destructive operation like a branch reset, the description lacks essential context: no warning about data loss, no explanation of soft vs hard reset, and no mention of whether 'force' can override safety checks. An output schema exists, but it does not cover behavioral side effects. The description is incomplete for safe and correct usage.

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 description coverage is 0%, so the description must compensate. It adds some value by providing defaults (branch_name defaults to main), clarifying that target_commit_id is numeric, and target_commit_uuid is a UUID. However, it fails to explain how to choose between the two target parameters or what 'soft' and 'hard' modes concretely do, leaving significant ambiguity.

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: 'Reset branch to the specified commit' (Сбросить ветку до указанного коммита). This is a specific verb+resource combination that distinguishes it from sibling tools like checkout_commit, checkout_branch, and merge_branches, which involve different operations on branches.

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. It does not mention scenarios where a reset is appropriate, nor does it differentiate from checkout or merge operations. The agent is left to infer usage from the name and parameter list.

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 states that agent_uuid is a real PostgreSQL database, but it does not disclose side effects (e.g., whether this creates or updates a binding), permissions required, or what happens to existing bindings. As a mutation tool ('set'), this is a significant transparency 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?

The description is appropriately sized: a one-line summary followed by a structured Args list. No fluff or redundant information. The only slight inefficiency is that the Args section could potentially be condensed, but it remains clear and organized.

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 description is adequate for a simple 'set' operation but lacks broader context. It does not mention how this relates to sync jobs, whether the operation is idempotent, or what happens after a binding is created. Since an output schema exists, return values are covered elsewhere, but the description still misses important behavioral context for a mutation tool.

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 description includes an Args section that explains every parameter: project_uuid (UUID of the project), agent_uuid (UUID of the agent, noted as a real PostgreSQL database), schema_uuid (UUID of the schema into which data is imported), and is_active (whether the binding is active). This adds meaning beyond the schema's bare types, and with 0% schema description coverage, this full parameter documentation is valuable.

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: 'Привязать проект к агенту-источнику данных' (Attach a project to a data source agent). This uses a specific verb (attach) and resource (project + agent), and the name 'set_data_source' distinguishes it from related siblings like get_data_source, delete_data_source, and test_connection.

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. It does not mention prerequisites, scenarios, or exclusions. For example, it does not clarify that this is the setup step before using sync jobs or how it relates to get_data_source or delete_data_source.

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 given, so the description must disclose behavioral traits. It states the core action but does not mention whether it overrides an existing default branch, requires permissions, or what happens to the previous default. This is a mutating operation with minimal 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?

The description is concise, with a one-line purpose and a compact Args list. There is no superfluous text, though the Args list adds little beyond the schema. Structure is acceptable but not front-loaded beyond the initial statement.

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 tool's simplicity, the description still lacks essential context: no prerequisites, side effects, or workflow placement. With no annotations and weak parameter explanations, the description leaves the agent with only the basic action and no deeper understanding of implications.

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 no property descriptions (0% coverage), so the description must compensate. The Args list merely repeats parameter names with trivial glosses ('UUID проекта', 'Имя ветки', 'Статус ветки по умолчанию') and does not explain how is_default affects behavior (e.g., what false does).

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: 'Сделать ветку веткой по умолчанию в проекте' (make a branch the default branch in the project). This is a specific verb+resource and distinguishes it from sibling tools like create_branch, checkout_branch, and reset_branch.

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 provided on when to use this tool vs alternatives, prerequisites (e.g., branch must exist), or exclusions. The only hint is the description itself, which implies usage but gives no context or decision criteria.

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 are absent, so the description must disclose side effects. It only says 'проверка подключения' (connection check) without explicitly stating that it is read-only, does not modify state, or what happens on failure. This is a gap for a tool with no annotation coverage.

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 short and front-loaded, with a one-sentence purpose followed by a compact parameter list. No wasted words; 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 moderate-parameter tool, it covers purpose and parameter meanings, and an output schema exists to explain return values. However, it omits behavioral details like whether the check is read-only and preconditions for use, but for a connection test tool this is mostly complete.

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