apply_code_patch

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

With no annotations provided, the description carries the full burden. It discloses meaningful behavioral traits: AST validation, Git safety gates, and automatic rollback on invalid syntax. This is genuinely useful safety information that an agent needs before invoking a mutation tool. It could add what happens on successful application (e.g., commit behavior) but covers core risk disclosure.

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

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

Two sentences with no wasted words. The key safety behaviors (AST validation, Git gates, rollback) are front-loaded. Efficient and scannable.

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 which partially relieves the description's burden, and both params are documented in the schema. For a mutation tool with no annotations, the safety behaviors are well disclosed. However, it doesn't clarify what happens on success (does it commit? create a branch?), or whether the Git safety gates could fail and how that's surfaced. A bit more operational detail would strengthen completeness for a state-changing 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?

Schema description coverage is 100%, so the schema already documents both parameters adequately. The description adds context that this is a full-content replacement ('full updated source code content') rather than a patch/diff, which is valuable distinction. However, this is baseline territory given the high 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 uses a specific verb ('modifies') with a clear resource ('target Python source file') and adds value by noting it validates AST syntax and establishes Git safety gates. It's clear but doesn't explicitly distinguish from sibling tools, though the verbs differ enough (query_log_file, inspect_code_ast are read operations while this is a write).

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 context (modifying Python source files) but provides no explicit when-to-use guidance or exclusions. It doesn't mention when to prefer alternatives like inspect_code_ast or query_log_file, though the write-vs-read distinction is implied. No prerequisites beyond the two required parameters are noted.

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