Server Quality Checklist

Tool Scores

• edtb_interface_infoC
  2.6/5.0
  Behavior2/5

  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 implies a read-only query by describing 'current' interface state, but it never explicitly states that no changes are made, nor does it mention any side effects, permissions, or error behavior.

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

  Conciseness4/5

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

  The description is a single concise sentence with no filler. The key information about what is reported is front-loaded, though the terseness leaves room for more useful context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  An output schema exists so return values do not need to be explained, but the description omits essential parameter semantics and usage guidance. For a tool with a required subsystemFQN and an optional projectPath, this level of description is not sufficient for confident invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention either parameter. The required subsystemFQN and optional projectPath are completely unexplained, leaving the agent to guess their roles and formats.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource—commands from CommandInterface.xml—and the specific aspects shown: visibility, placement, and order. Although it lacks an explicit verb, the title 'Info' and the content make the tool's purpose unambiguous and distinct from mutation-oriented siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 like edtb_interface_edit or other info tools. The description only states what the tool reports, not the conditions or context in which it should be selected.

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

• edtb_mxl_infoC
  2.7/5.0
  Behavior3/5

  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 does disclose headless, no-screenshot behavior and implies a read-only informational operation, but it does not state side effects, required access, or what happens when inputs are invalid.

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

  Conciseness3/5

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

  The description is very short and contains no filler, which is good. However, 'без скриншота' and 'headless' are somewhat redundant, and the description is phrased as a noun phrase rather than an actionable sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With three opaque parameters, no usage guidance, and no sibling differentiation, the description is only minimally complete. An output schema exists, but it does not compensate for missing parameter semantics or selection criteria.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain objectName, templateName, or projectPath at all. The parameters remain opaque, so an agent has no semantic help beyond the raw names and types.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states that the tool returns structural information about a layout from a file, and adds a distinguishing qualifier: no screenshot, headless. This separates it from compile/decompile siblings, though it lacks an explicit verb like 'get' or 'return'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus siblings such as edtb_mxl_compile, edtb_mxl_decompile, or edtb_form_info. The 'headless' and 'no screenshot' hints imply a use case, but no alternative tools or exclusion conditions are named.

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

• edtb_cf_panels_infoC
  2.9/5.0
  Behavior3/5

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

  With no annotations, the description must carry the behavioral burden. It conveys that the operation is observational ('Текущая раскладка... состав') and points to Configuration.mdo as the source, implying a read-only inspection. However, it does not state side effects, failure modes, or whether projectPath affects which Configuration.mdo is read.

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

  Conciseness4/5

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

  The description is a single short sentence with no redundant words. It front-loads the core subject and includes the relevant source file. It could be slightly more explicit about the action, but it is appropriately sized for what it conveys.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The presence of an output schema reduces the need to describe return values, but the description still omits any explanation of the sole input parameter and how to target the intended project. For an agent deciding whether and how to invoke this tool, the missing parameter semantics and lack of usage context leave important gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not mention projectPath or clarify how it is used. The parameter name is somewhat self-explanatory as a project path, but the description adds no semantics about its role, optionality, null behavior, or relationship to Configuration.mdo. This is a clear compensation gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the tool's purpose: it reports the current panel layout and start-page composition from Configuration.mdo. This is a specific resource and topic, though the action verb is implied rather than explicit. It is clearly distinct from a generic 'panels' tool at a glance, but it does not name or contrast sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as edtb_cf_panels or edtb_cf_artifact. No context is given for the expected use case, prerequisites, or situations where another tool would be preferred. The description states only what the tool exposes, not when to invoke it.

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

• edtb_designer_checkC
  2.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It does disclose the return shape and the CLI_NOT_FOUND error with installation instructions, which is useful. However, it does not explicitly state whether the check is read-only, whether it can modify the project, or what side effects the external CLI may have.

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

  Conciseness4/5

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

  The description is short and front-loads the core purpose and command. The return/error information is packed efficiently, though the second line is somewhat cryptic and could benefit from a tiny bit more context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 2-parameter tool with no annotations and no schema descriptions, the description leaves a notable gap around 'projectPath'. It also omits any usage context, such as when validation should be run or how the result should be interpreted.

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

  Parameters2/5

  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 adds meaning to 'scope' by listing 'project' | 'extension', but it gives no explanation of 'projectPath', which is the other parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Проверка проекта/расширения') and the underlying commands ('ring edt validate or 1cedtcli'), making the tool's purpose clear. It is distinguishable from sibling tools like edtb_form_compile or edtb_apply_mutations, which are more specialized mutation or compile operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 exclusions, and no mention of prerequisites. The scope values are listed but not explained in terms of decision-making.

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

• edtb_mxl_decompileC
  2.9/5.0
  Behavior2/5

  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 communicates that this is a conversion operation and names the output format, but it does not disclose side effects such as file writes, overwriting behavior, projectPath resolution, or whether the operation is read-only. These are significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single sentence with no filler or redundant phrasing. The core operation is stated directly and front-loaded, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although an output schema exists, the overall definition is incomplete. There are no annotations, parameter documentation, or usage context, so the description does not provide enough information to select and invoke the tool correctly. The optional projectPath, required fields, and side-effect behavior are left unexplained.

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

  Parameters1/5

  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 does not explain what objectName, templateName, or projectPath mean, how they relate to the .mxl artifact, or what values are expected. An agent cannot reliably determine how to fill the required parameters from the description alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly names the verb 'декомпилировать' (decompile), the resource (a .mxl layout of a project), and the output format (JSON-DSL). This makes the tool's purpose distinct from siblings like edtb_mxl_compile, which performs the inverse operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus alternatives such as edtb_mxl_info or edtb_mxl_compile. There is no mention of prerequisites, workflow context, or conditions that should lead an agent to choose this tool.

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

• edtb_form_compileB
  3.1/5.0
  Behavior2/5

  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 says 'compilation' without disclosing whether this mutates anything, whether it produces a plan or applies changes, what side effects occur, or what the output represents. The schema's dryRun parameter hints at planning behavior, but the description does not state it.

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

  Conciseness5/5

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

  A single, front-loaded sentence with no filler. The core purpose appears immediately, and the parenthetical adds useful specificity without bloat.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema and output schema cover inputs and outputs reasonably well, so the descrition is minimum viable for a straightforward compile action. However, with no annotations and a complex nested DSL parameter, the missing relationship to plan/apply siblings and the lack of side-effect context leave a real completeness gap.

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

  Parameters3/5

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

  Schema description coverage is 83%, so most parameter meaning is already carried by the schema. The description adds a small hint about DSL variants (GAP-FORM-DSL/BATCH/PRESETS), but does not meaningfully explain parameters such as mode, dryRun, or objectName beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear action — compiling a form from JSON-DSL — and names the source format explicitly, including useful DSL variants. It does not explicitly differentiate this tool from sibling tools, but the verb-resource pair is specific enough to be understood.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 like edtb_plan_mutations or edtb_apply_mutations. The schema implies dryRun/mode behavior, but the description itself gives no use-case context, exclusions, or decision rules.

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

• edtb_mxl_compileB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It does reveal meaningful routing behavior (auto/edt-mcp/file strategies and their targets), but it omits what side effects compiling has, whether it writes files, how dryRun affects execution, and what happens on failure. Partial but not rich disclosure.

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

  Conciseness4/5

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

  The text is short and the most important decision-relevant detail (strategy behavior) is front-loaded. It loses a point for terse, somewhat cryptic formatting (e.g., 'полный DSL → файл' without explaining файл), but there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has six parameters, three required, a nested dsl object, and no annotations; the description only addresses compilation purpose and strategy. Required parameter meanings, dryRun behavior, projectPath expectations, and the nature of the compiled artifact are absent, so an agent would struggle to construct a valid call.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain parameters. It explains only strategy values; objectName, templateName, dsl, dryRun, and projectPath are never defined, and their relationships (e.g., what subset/full DSL means for dsl) are unclear. This is not enough to invoke the tool correctly with the required parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states a specific operation: compile a JSON-DSL into a layout (макет), which is enough to identify the tool's core function and distinguishes it from decompile/info siblings by direction. It does not explicitly name a sibling alternative, so it stops short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete guidance for the strategy parameter: auto routes subsets to modify_metadata vs full DSL to a file, edt-mcp forces proxy, file forces file. However, it never says when to prefer this tool over edtb_mxl_decompile, edtb_mxl_info, or edtb_plan/apply_mutations, leaving tool-selection context implicit.

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

• edtb_cf_panelsB
  3.3/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the full behavioral burden. It does disclose a meaningful behavior: dryRun returns a unified diff without writing to disk, implying the default mode writes the file. However, it omits what the default write path returns, whether edits replace or merge existing panels/homePage definitions, and any failure or reversibility characteristics.

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

  Conciseness4/5

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

  The description is compact and well-structured: a one-line purpose, an ops grammar block, and a dryRun note. The key information is front-loaded and every line earns its place; slightly clearer prose framing of the two ops variants would be the only improvement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no annotations and no output schema, the description should do more. It adequately documents the ops grammar and dry-run behavior but omits projectPath semantics, the default (non-dryRun) side effects, return values, and any routing guidance toward neighboring sibling tools. An agent can call it correctly for the documented cases, but meaningful gaps remain.

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

  Parameters4/5

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

  The input schema has zero property descriptions, so the description must compensate — and it largely does. It specifies the ops grammar (panels list with panel/location enums, homePage columns/forms structure) and explains dryRun's diff-without-write semantics. projectPath is left undocumented in both the schema and the description, which prevents a full score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource: 'Правка секций интерфейса в Configuration.mdo' (editing interface sections in Configuration.mdo), and the ops grammar further scopes it to panel locations and home page columns. It only partially distinguishes from the sibling edtb_interface_edit, since the boundary between 'interface sections' and a generic 'interface edit' is not explicitly drawn.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance states when to prefer this tool over siblings like edtb_interface_edit, edtb_cf_panels_info, or edtb_designer_check. There is no when-to-use or when-not-to-use language, no prerequisites (e.g., a valid projectPath or checked-out Configuration.mdo), and the usage context must be inferred entirely from the ops grammar.

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

• edtb_form_infoB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It does add useful context: the operation is 'headless' and produces a structured parse result, implying a non-mutating read/analysis operation. However, it does not explicitly state whether the tool modifies anything, what prerequisites exist, or how errors or missing forms are handled.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence: it names the resource, the action, the output categories, and the headless mode. There is no filler or redundant restatement of the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The output schema covers return-value structure, but the tool lacks annotations, usage guidance, and parameter explanations. For a tool with three parameters and no schema descriptions, relying on 'Разбор Form.form' alone is incomplete for reliable invocation.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description does not explain objectName, formName, or projectPath. The phrase 'Form.form' loosely implies which inputs identify a form, but without explicit parameter semantics an agent must infer the meaning of objectName vs formName and projectPath.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource: 'Разбор Form.form' (parse Form.form), and specifies the decomposition result {elements, commands, params, events}. This makes the tool's purpose immediately clear and distinguishes it from mutation-focused siblings like edtb_form_compile and edtb_form_remove.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 rather than related info/parse tools such as edtb_interface_info or edtb_mxl_info. There is no mention of expected 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.

• edtb_form_removeA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and provides meaningful behavioral detail: the default dryRun phase, one-time confirmToken, the EDTB_ALLOW_FILE_MUTATIONS=1 requirement for actual deletion, resync, and .mdo registration removal. It does not cover failure modes or permission requirements, but the core side effects and safety flow 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.

  Conciseness5/5

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

  The description is compact, front-loads the core purpose, and uses two labelled phases to convey process flow. No sentence is wasted, and the most important safety detail (dryRun default) appears early.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the main behavioral phases, the environment gate, and the mutation effects, and the output schema handles return-value documentation. However, usage guidance and parameter semantics for objectName/projectPath are incomplete, so an agent may still lack full information for a correct invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It explains dryRun and confirmToken and mentions 'by form name', which maps to formName, but objectName and projectPath are left unclear. Some semantics are present, but not enough to compensate for the full schema gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with a clear verb and resource: deleting a form with a pre-check of BSL references. It distinguishes this tool from form compilation/inspection siblings by describing the removal workflow and naming the cascade operation GAP-FORM-REMOVE-CASCADE.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this tool is for form deletion and explains the dryRun vs. actual deletion phases. However, it never explicitly states when to use this tool over alternatives or when not to use it, so the agent must infer the usage boundaries from context.

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

• edtb_apply_mutationsA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral transparency burden. It discloses the dry-run behavior, rollback-on-error semantics, and the two execution strategies. This is solid transparency, though it does not explicitly state that the tool modifies files or project state by default.

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

  Conciseness5/5

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

  The description is compact and well-structured: a one-sentence purpose, followed by strategy, dry-run behavior, and rollback guarantee. Every sentence carries useful information with no repetition or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers safety-critical behavior well but leaves the most important input semantics unexplained. With no parameter descriptions in the schema and a complex ops array, the tool is not fully callable by an agent without additional external knowledge. The presence of an output schema helps, but it does not compensate for missing parameter semantics.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It explains dryRun and planHash indirectly, but it does not explain the structure or meaning of the required 'ops' array, nor the role of 'projectPath'. An agent cannot confidently construct a valid 'ops' payload from this description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: apply a batch of mutations using the hash of a fresh plan. It also names two strategies (edt-mcp and file), which differentiates it from sibling tools like edtb_plan_mutations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives practical guidance on how to use the tool: dryRun returns a diff preview without applying, and failed file mutations are rolled back from backup. It implies this tool should be used after a plan is created, though it does not explicitly name alternatives or exclusion criteria.

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

• edtb_interface_editA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description must carry the behavioral burden; it does so by listing the mutating operations and explicitly defining dryRun as returning a unified diff without writing to disk, which implies normal execution persists changes. It does not discuss reversibility or permissions, but the core side-effect behavior is clear.

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

  Conciseness5/5

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

  The description is compact and well-structured: a one-line purpose followed by an operation-list spec and a short dryRun definition. Every sentence contributes functional information and there is no repetition of schema fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The core invoke data (ops shapes, dryRun semantics) is covered and an output schema exists, so return values do not need explanation. However, the full allowed values for group are truncated ('NavigationPanelOrdinary|...'), and no behavior is described for invalid groups, missing subsystemFQN, or what exact file changes occur when dryRun is false; this leaves moderate ambiguity for place/order operations.

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

  Parameters4/5

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

  The input schema has no parameter descriptions, but the description adds concrete JSON templates for hide/show/place/order, explains the meaning of command FQN, and defines dryRun's effect. It is less explicit about subsystemFQN and the full group value set, but it compensates for most of the schema's 0% coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description immediately names the exact resource ('CommandInterface.xml подсистемы') and the specific mutation verbs ('hide/show/place/order команд'), making the tool's function unambiguous and distinct from read/info siblings such as edtb_interface_info.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit guidance on when to choose this tool over alternatives, and no prerequisites or exclusions are mentioned. The purpose implies 'use for editing interface commands', but nothing in the description routes an agent away from related tools like edtb_plan_mutations, edtb_apply_mutations, or edtb_interface_info.

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

• edtb_cf_artifactA
  4/5.0
  Behavior4/5

  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 does this well by stating that it uses 1cv8 DESIGNER, reads infobase parameters from EDTB_INFOBASE_PATH, operates on a file infobase, runs non-interactively, and enforces a timeout. It does not explicitly warn that 'load' may overwrite existing data, but the load action is clearly described as writing a file into the infobase.

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

  Conciseness5/5

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

  The description is compact and well-structured: a one-line statement of purpose, then explicit dump/load semantics, then execution constraints. Every sentence adds useful information, and there is no filler or tautological restatement of the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-mode artifact tool, the description covers the purpose, both actions, the file/infobase relationship, the external command, the relevant environment variable, and the non-interactive/timeout behavior. The main gaps are the undocumented 'projectPath' parameter and the lack of an explicit overwrite warning for load, but an output schema exists, so return-value details are not required here.

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

  Parameters3/5

  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 usefully defines the 'action' values and clarifies that 'path' is a file path. However, the optional 'projectPath' parameter is not explained at all, leaving one of three parameters semantically undocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies a concrete resource (.cf/.cfe artifact) and a clear verb pair (dump/load), then defines the two action modes explicitly. This makes its role distinct from sibling tools focused on mxl, forms, panels, or mutations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the dump/load semantics: an agent can infer that this tool is for exchanging .cf/.cfe artifacts with an infobase. However, there is no explicit statement of when to prefer this tool over alternatives, no exclusions, and no when-not-to-use guidance.

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

• edtb_plan_mutationsA
  4.1/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden. It discloses the critical no-side-effect trait ('БЕЗ применения'), the per-op validation performed, and the two-phase deletion nuance via confirmToken for deleteMetadata. It does not mention error behavior or prerequisities, but the main behavioral risk is well covered.

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

  Conciseness5/5

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

  Three short, front-loaded sentences with no wasted words. The first sentence states the core scope and constraint, the second details what happens per op, and the third defines the return contract for downstream tools.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that an output schema exists and only ops is required, the description covers the intended lifecycle: validate, get hash/confirmToken, then apply or perform two-phase deletion. It stops short of documenting the optional projectPath and the exact op payload shape, so it is not a 5.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description had to compensate by explaining the parameters. It adds some meaning to ops: each op is a mutation whose schema, target addressability, and risk are checked. However, it never explains how to structure an op and says nothing about projectPath (optional, default null), leaving substantial parameter semantics undocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description opens with 'Провалидировать пакет мутаций БЕЗ применения' – validates a mutation batch without applying – giving a specific verb and resource. It enumerates the checks (schema, target addressability, risk) and explicitly orients the output toward edtb_apply_mutations, distingushing it from the applying sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'БЕЗ применения' clearly frames this as a pre-flight validation step, and the return contract ('hash для edtb_apply_mutations') signals that this tool is the prerequisite before applying. It lacks an explicit 'use edtb_apply_mutations instead when you want to apply' exclusion, so it does not earn a 5.

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

• edtb_cfe_borrow_methodA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does a good job: it discloses that a method is read, an interceptor is generated and inserted, writes happen either via proxy or by appending to .bsl plus resync, and that dryRun returns a plan without applying. It does not mention permissions or reversibility, but core behavioral impact is clear.

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

  Conciseness4/5

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

  The description is a bit long due to a complete parameter list, but it is well organized with a summary, parameter block, and return block. The key purpose is front-loaded, and no sentence is purely decorative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 9 parameters, no annotations, and zero schema description coverage, the description covers the full workflow, fallback path, parameter constraints, dry-run behavior, and return fields. Nothing essential for an agent to select and invoke the tool is missing.

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

  Parameters5/5

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

  Schema description coverage is 0%, and the description fully compensates by documenting every one of the 9 parameters, including FQN examples, moduleType and mode enums, default values for newName, extProjectPath and baseProjectPath, the formName condition, and dryRun semantics. This is far richer than the input schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: it 'borrows' a BSL method from the base project, generates an interceptor with the correct annotation, and inserts it into the extension module. This clearly distinguishes it from sibling tools concerned with forms, MXL, panels, or design checks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied: create an extension interceptor for a base method. It also explains a fallback path when EDT-MCP is unavailable, but it never explicitly says when to choose this tool over alternatives like edtb_plan_mutations or edtb_apply_mutations, nor provides exclusions.

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

• edtb_epf_scaffoldA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does this well by explicitly stating that the tool creates files, registers the object in Configuration.mdo, performs a resync, and supports a dryRun mode to return a plan without applying changes. It stops short of describing overwrite or idempotency behavior, but the main side effects are clearly exposed.

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

  Conciseness5/5

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

  The description is appropriately sized for a complex scaffold operation and is well structured: purpose, concrete effects, parameters, and return value. Every section adds necessary information, and the first line is a crisp summary of the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-annotation tool with five parameters and no schema-level parameter descriptions, the description is substantially complete: it names target paths, generated files, configuration registration, dryRun behavior, and return fields. It could add edge-case expectations such as behavior when the object already exists, but nothing critical for invoking the tool correctly is missing.

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

  Parameters5/5

  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, and it fully does. It explains all five parameters: name, kind with the two exact allowed values, withBspModules, projectPath including the EDTB_PROJECT_PATH fallback, and dryRun. This adds substantial meaning beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and object: 'Сгенерировать каркас внешней обработки/отчёта' and then enumerates the exact artifacts created and where. This clearly differentiates it from sibling tools like edtb_form_compile, edtb_mxl_decompile, and edtb_cf_artifact.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use case is clear from the description: create a scaffold for a new external data processor or report. However, it never explicitly states when to prefer this tool over alternatives such as edtb_plan_mutations or edtb_apply_mutations, nor does it provide when-not-to-use guidance.

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

• edtb_cfe_init_roleA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full transparency burden. It discloses that the tool may either create metadata via proxy or fall back to file-based .mdo creation plus Configuration.mdo registration and resync. It also mentions dryRun to return a plan without applying, which gives useful behavioral insight into the operation.

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

  Conciseness5/5

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

  The description is well-structured and efficient: purpose, primary/fallback approach, parameter list, and return value are all covered without excess. The use of labeled sections makes it easy for an agent to parse the relevant details quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a four-parameter tool with no annotations and an output schema, the description is nearly complete: it explains the goal, method, fallback, parameters, and return shape. It could be improved by mentioning prerequisites, error conditions, or behavior when the role already exists, but nothing critical is missing for basic invocation.

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

  Parameters5/5

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

  The input schema has 0% description coverage, but the tool description compensates fully by explaining every parameter: roleName with default, extProjectPath with environment fallback, projectName for create_metadata, and dryRun as a plan-only switch. This adds substantial meaning beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the verb and resource: create the 'main role' for an extension (GAP-CFE-NOROLE), and it explains the primary and fallback mechanisms. This is distinct enough to separate it from the listed sibling tools, none of which specialize in role initialization.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states when in the workflow this tool is intended ('composition after create_project') and gives the fallback path if the primary metadata path is unavailable. It does not explicitly list alternative sibling tools or exclusions, 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.

• edtb_help_addA
  4.6/5.0
  Behavior4/5

  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 side effects: creates a help file, conditionally modifies forms via modify_metadata, and emits a warning if EDT-MCP is unavailable. It does not discuss overwrite behavior or reversibility, preventing a 5.

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

  Conciseness5/5

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

  The description is well structured and front-loaded: one-sentence purpose, then side-effect/conditional behavior, then a clear parameter list, then return contract. Every sentence adds useful information with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a six-parameter mutation tool with no annotations, the description is sufficiently complete: it covers all parameters, default behavior, failure mode, dryRun behavior, and return fields. Nothing critical is missing for an agent to invoke it correctly.

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

  Parameters5/5

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

  The input schema has 0% description coverage, and the description fully compensates: every parameter is explained, including defaults, FQN examples for objectName, stub generation for empty html, projectPath fallback to EDTB_PROJECT_PATH, and dryRun semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description says exactly what the tool does: it adds built-in help to an object by creating Help/<lang>.html in the project object directory. The verb 'Добавить' and the concrete file path/resource distinguish it clearly from siblings, none of which target help creation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear operational context: it explains when updateForms triggers form metadata modification, what happens when EDT-MCP is unavailable, and that dryRun returns a plan without applying. It does not explicitly name alternatives or when-not-to-use, but the tool's purpose is unique among siblings, so the context is sufficient.

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