Skip to main content
Glama

remove_parameter

Destructive

Remove a named parameter from a function signature while keeping the body intact and adjusting language-specific syntax. Use it to drop one parameter without retyping the signature.

Instructions

Remove a parameter by name from a function's signature, keeping the body. A parameter on a line of its own goes with that line and its comment. Removing the only one leaves (), or (void) in C. In Python a * or / left invalid goes too, and a *args with keyword-only parameters after it leaves a bare * (def f(a, *args, b) minus args is def f(a, *, b)). One Go name of a, b int, or one name that a destructuring parameter binds, goes alone. Refused: a name the function lacks, and in C the last named parameter before ....

Use this when: dropping one parameter without retyping the signature. Don't use this when: rewriting the signature (replace_signature).

Example: target="LRUCache.get" parameter_name="default"

Input Schema

NameRequiredDescriptionDefault
targetYesFunction or method name as list_symbols lists it, dotted for nesting ('LRUCache.get'); overloads take parameter types ('A.m(int)').
file_pathYesAbsolute path to the source or config file.
parameter_nameYesBare name of the parameter (e.g. 'default'), without its type or default value.

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 / parameter_name / description
      Added value: +"Bare name of the parameter (e.g. 'default'), without its type or default value."
    • addedInput schema / properties / target / description
      Added value: +"Function or method name as list_symbols lists it, dotted for nesting ('LRUCache.get'); overloads take parameter types ('A.m(int)')."
  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 (destructiveHint=true, readOnlyHint=false) only signal that this mutates; the description adds substantial context beyond that: comments travel with a line-own parameter, `()`/`(void)` results, Python `*`/`/` cleanup, `*args` leaving a bare `*`, Go `a, b int` and destructuring singletons, and explicit refusal cases. That is exactly the edge-case behavior an agent cannot infer from annotations or schema.

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?

Front-loaded with purpose, then behavior, then when/when-not, then an example — a sensible progression with no filler sentences. It is dense with parenthetical edge cases, which earns its place but could be tightened slightly; the example partially restates the schema's own field descriptions.

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 destructive mutation tool, the agent knows the effect on the signature and body, the formatting-preservation rules, and the conditions under which the call is refused. An output schema exists, so return-value detail is unnecessary — nothing material is missing.

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 baseline is 3; the description goes further by clarifying what a 'name' means operationally — one name of a Go `a, b int` group, or a name bound by a destructuring parameter, is removed alone. The worked example (target="LRUCache.get", parameter_name="default") also reinforces the dotted target format.

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?

Opens with a specific verb and resource: 'Remove a parameter by name from a function's signature, keeping the body.' The scope qualifier ('keeping the body') immediately distinguishes it from replace_signature and replace_function, so an agent can route without opening a 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?

Explicit 'Use this when: dropping one parameter without retyping the signature' and 'Don't use this when: rewriting the signature (replace_signature)', naming the sibling alternative. Both the positive trigger and the exclusion are stated, not implied.

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