Skip to main content
Glama

pull_up

Move a method or field up into its superclass and remove it from the declaring subclass. Position on the member name; requires load_project first and returns text edits to apply.

Instructions

Pull a method or field up into the superclass and remove it from the declaring subclass.

USAGE: Position on the member name in the subclass. OUTPUT: editsByFile covering the superclass (member added) and the subclass (member removed); warnings from JDT's condition checking, by the place each names (file, then position; those naming one place in JDT's order, those naming none last). Edits are returned as text - apply them yourself.

The superclass is the Java model's, for local and anonymous classes in and after lambda bodies too. A member is refused when JDT's own type hierarchy leaves that superclass out (a class declared in a lambda body, a local class read by the handle of another of the same name), naming it: JDT's pull up would act on another class. A member is also refused when the superclass has a subclass declared in a lambda body, naming it: JDT's pull up cannot read that class. And a member is refused when JDT's own type hierarchy of the superclass does not hold every subtype with source as the Java model does (a class declared in a lambda body at any depth, a local class held by the handle of another of the same name), naming each type it leaves out and each it holds that is no subtype: JDT's pull up reads the subtypes from that hierarchy.

IMPORTANT: Uses ZERO-BASED coordinates.

Requires load_project to be called first.

Input Schema

NameRequiredDescriptionDefault
lineYesZero-based line number of the member declaration
columnYesZero-based column number (on the member name)
filePathYesPath to source file containing the member

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.1

TDQS

A4.2/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and largely does: it discloses output shape (editsByFile per file), that edits are returned as text and must be applied manually, and the many refusal conditions tied to JDT's type hierarchy quirks. This is substantial behavioral context beyond what any structured field provides.

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

Conciseness3/5

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

The usage/output/prerequisite lines are front-loaded and efficient, but the refusal prose is dense and repetitive, enumerating the same lambda-body and local-class cases multiple times. It is informative yet overlong for the value of the distinction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does explain return values and manual-apply semantics, plus prerequisite and refusal edge cases. It is complete enough to call correctly, only slightly marred by convoluted phrasing of the refusal rules.

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 line/column/filePath are already documented, giving baseline 3. The description adds that coordinates are ZERO-BASED and that the position must land on the member name, which meaningfully sharpens how to supply line and column.

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 (pull up) and resource (method or field) plus the effect (moved to superclass, removed from declaring subclass). This clearly distinguishes it from push_down and extract_superclass among siblings.

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

Usage Guidelines3/5

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

Gives a positional instruction ("Position on the member name in the subclass") and a prerequisite (load_project), but never says when to choose this over push_down, extract_superclass, or move_type_to_new_file. Usage is implied by the positioning hint rather than stated against alternatives.

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