Edtb Cf Panels

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.

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.

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.

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.

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.

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.