Skip to main content
Glama

add_method

Add a method to an existing class at the end of its body, matching method spacing and preserving Go type or C++ access context.

Instructions

Add a method at the end of a class body, after its last member, spaced like the class's methods. In Go it goes after the type declaration. In a C++ class whose last method is followed by an access label, it goes right after that method, so it gets the same access. A one-line Python or Ruby class is refused, and so is a function target (use insert_in_body).

Use this when: adding a method to an existing class. Don't use this when: adding a field (add_field) or a top-level function (add_top_level).

Example: class_target="LRUCache" content='def clear(self):\n self.items.clear()'

Input Schema

NameRequiredDescriptionDefault
contentYesComplete method source, re-indented like the class's members, keeping its own relative indentation.
file_pathYesAbsolute path to the source or config file.
class_targetYesClass name as list_symbols lists it (a struct, interface or Go struct type too), dotted for nesting ('A.B').

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.2.0
    • addedInput schema / properties / class_target / description
      Added value: +"Class name as list_symbols lists it (a struct, interface or Go struct type too), dotted for nesting ('A.B')."
    • addedInput schema / properties / content / description
      Added value: +"Complete method source, re-indented like the class's members, keeping its own relative indentation."
    • addedInput schema / properties / file_path / description
      Added value: +"Absolute path to the source or config file."
  2. First observedv2.0.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare safety hints (readOnly false, destructive false, closed world); the description adds substantial behavior: placement rules across Go/C++/Python/Ruby, refusal conditions for one-line classes and function targets, and indentation/spacing behavior. Nothing contradicts 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.

Conciseness5/5

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

Front-loaded with the core behavior, then use/don't-use bullets and a compact example. Every sentence earns its place—language-specific rules are necessary precision, not padding.

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?

Given an output schema, annotations, and full schema coverage, the description covers everything an agent needs to call this correctly: placement per language, refusals, target restrictions, and an example. No material gaps remain.

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 coverage is 100%, so all three parameters are already well documented; the baseline is 3. The description doesn't add syntactic meaning to file_path or class_target beyond the schema, though the example clarifies content shape (full method source including def line).

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 and resource (add a method to a class body) and precisely defines where it is placed. The language-specific clauses (Go after type declaration, C++ after access label, refusal of one-line Python/Ruby classes) make it unmistakable against siblings like add_field or add_top_level.

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?

Explicitly provides 'Use this when' and 'Don't use this when' sections, naming the alternatives add_field and add_top_level. It also redirects function targets to insert_in_body, so the agent knows exactly which sibling to pick.

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