method_object

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

Since no annotations are provided, the description carries full burden. It discloses multiple behavioral traits: dry run default vs. apply=true, the fail-safe behavior when expected_symbol is supplied, and the explicit statement that this tool only changes code (not reads). This goes beyond basic 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?

Three dense sentences deliver all essential information without fluff. The opening sentence defines the operation, the second gives positional details, and the third covers dry-run/apply, expected_symbol, and prerequisite. Well-structured and front-loaded.

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, the description covers purpose, usage, behavior, and parameter semantics comprehensively. An output schema exists to clarify return values, so no further explanation is needed. Minor gaps like root are negligible.

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%, but the description compensates well by explaining line/character as 0-based LSP positions in UTF-16 units, apply defaulting to false, and expected_symbol for stale positions. However, the root parameter is not mentioned and its meaning remains unclear.

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 converts a method into a method object, specifically a new class with a __call__ holding the method body and the original method delegating to it. This specific verb+resource+pattern distinguishes it from siblings like extract_method or inline.

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?

Provides clear usage context: it's a stepping stone for decomposing a complex method, defaults to a dry run, and instructs to set apply=true to write. Also advises reading the method with LSP first. While it doesn't explicitly name alternative tools, the guidance is sufficient for an agent to choose appropriately.

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