Skip to main content
Glama

replace_docstring

Destructive

Add or replace Python module, class, function, or method docstrings at a named symbol target, using a quoted string literal for precise source edits.

Instructions

Replace or add the docstring of a Python function, method or class, or of the module with target "". new_docstring must be one string literal with its quotes; anything else (bare text, an f-string, bytes, an empty value) is refused. A new docstring goes first in the body; the module's goes below a #! line and encoding or header comments. A new docstring for a body on its signature's line is refused (use replace_function_body); so is any non-Python file.

Use this when: adding or updating a Python docstring. Don't use this when: editing a # comment above the symbol (edit_leading_comment).

Example: target="LRUCache.get" new_docstring='"""Return the cached value, or None."""'

Input Schema

NameRequiredDescriptionDefault
targetYesPython function, method or class name, dotted for nesting (e.g. 'LRUCache.get'), or '' for the module.
file_pathYesAbsolute path to the source or config file.
new_docstringYesOne Python string literal with its quotes, usually triple-quoted.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.2.0
    • addedInput schema / properties / file_path / description
      Added value: +"Absolute path to the source or config file."
    • addedInput schema / properties / new_docstring / description
      Added value: +"One Python string literal with its quotes, usually triple-quoted."
    • addedInput schema / properties / target / description
      Added value: +"Python function, method or class name, dotted for nesting (e.g. 'LRUCache.get'), or '' for the module."
  2. First observedv2.0.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description goes well beyond that: it enumerates refusal conditions (bare text, f-strings, bytes, empty value, non-Python files, signature-line bodies), states where the new docstring is placed in the body, and specifies module-level placement below `#!` and encoding/header comments. These are non-obvious mutation side effects an agent cannot get from the annotations.

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 placement and refusal rules are front-loaded in the first paragraph, followed by the when/when-not block and a compact example – well ordered and dense. The 'Use this when: adding or updating a Python docstring' line is a light restatement of what the first paragraph already established, a small redundancy.

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 three-required-parameter mutating edit tool with an output schema available, everything an agent needs to call it correctly is present: valid input form, placement semantics, refused cases, and escalation paths to sibling tools. No gaps remain that would cause a malformed or misrouted call.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real constraints the schema does not: new_docstring must include its own quotes, f-strings and bytes are refused, and target="" means the module. The worked example anchors both arguments concretely; it stops short of describing any return or error payload shape, but the output schema covers that.

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?

States a specific verb (replace/add) and a specific resource (Python docstring of a function, method, class, or module) and pins down the target addressing scheme. It actively distinguishes itself from siblings by naming replace_function_body and edit_leading_comment, so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Has explicit 'Use this when: adding or updating a Python docstring' and 'Don't use this when: editing a `#` comment above the symbol (edit_leading_comment)', naming the alternative tool. It also names replace_function_body as the fallback for the signature-line-body case, giving three concrete routing rules.

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