Skip to main content
Glama

Remove sections

remove_sections

Remove sections by name, or all.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "remove_sections"
  }
}

Input Schema

NameRequiredDescriptionDefault
allNo
namesNo
projectIdNoProject to act on (default: the open one)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

Annotations declare destructiveHint=false, yet the description describes unconditional removal of sections, including removing every section at once via "all" — a tension the description never resolves (soft delete? undoable? renumbered?). With minimal annotations, the description should have said what removal does to containing clips/markers and whether it is reversible, and it says nothing.

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?

A single eight-word sentence with the mode distinction front-loaded and no filler. Its brevity is close to under-specification rather than verbosity, but on the conciseness axis itself it is efficient.

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

Completeness2/5

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

This is a mutation tool that can wipe all sections in one call, with no output schema, 33% schema coverage, and thin annotations — of all tools this one most needs a sentence about consequences and confirmation. The projectId default ("the open one") is the only contextual detail supplied.

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 only 33% (projectId is the sole documented parameter), so the description carries real weight — and it does partially compensate by explaining that "names" selects by name and "all" selects everything. However, it never states that the two are mutually exclusive or which one wins if both are supplied, nor that omitting both is a no-op or error.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Remove sections by name, or all" gives a specific verb (remove) and resource (sections) and even names the two operating modes, so an agent immediately knows what the tool does. It does not distinguish itself from siblings such as set_sections (which presumably replaces section structure) or list_sections, so it falls short of a 5.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus set_sections, delete_ranges, or remove_markers, and no prerequisites or warnings attached to the bulk "all" path. The only implied usage is the mechanical "by name or all" phrasing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources