Skip to main content
Glama

add_field

Adds a field or member variable at the top of a class body with correct placement and indentation; refuses function targets. Use for class attributes, not methods.

Instructions

Add a field or member at the top of a class body: before the first member, after a Python class docstring or a Java enum's constants (adding the ; they need), and below the access label a C++ class opens with. It is indented like the class's members, with a blank line after it when a method follows. A function target is refused.

Use this when: adding a class attribute, field or member variable. Don't use this when: adding a method (add_method).

Example: class_target="LRUCache" content='version = "1.0"'

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file_path": "<file_path>",
      "class_target": "<class_target>",
      "content": "<content>"
    },
    "name": "add_field"
  }
}

Input Schema

NameRequiredDescriptionDefault
contentYesField or member declaration as source text (e.g. 'version = "1.0"' or Go 'version int').
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: +"Field or member declaration as source text (e.g. 'version = \"1.0\"' or Go 'version int')."
    • addedInput schema / properties / file_path / description
      Added value: +"Absolute path to the source or config file."
  2. First observedv1.2.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations cover the safety profile (mutation, non-destructive, closed world), and the description adds genuinely new behavior: exact insertion point per language, indentation matching, blank-line insertion when a method follows, Java enum semicolon handling, and that a function target is refused. It does not mention error modes beyond the function-target refusal or whether the edit is atomic, so it stops short of a 5.

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-loads the placement behavior, then a crisp use/don't-use pair, then a compact example. Every sentence carries distinct information; nothing is redundant with the schema or annotations.

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?

Output schema exists, so return values need not be described. Placement, formatting side effects, target-type constraints and the sibling alternative are all covered, which is everything an agent needs to call this correctly.

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 value the schema lacks: the sample invocation shows class_target='LRUCache' with dotted-nesting implied, and the refusal rule clarifies what class_target will accept. It does not clarify file_path or content syntax beyond the example.

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 field or member') and scopes it precisely to a class body, immediately separating it from the sibling add_method. The placement rules across Python, Java and C++ make the operation unambiguous.

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?

Explicit 'Use this when: adding a class attribute, field or member variable' and 'Don't use this when: adding a method (add_method)', naming the sibling alternative directly. Nothing is left to inference.

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