Skip to main content
Glama
thenavidm

Gumloop MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Rename session

rename_session
Destructive

Rename an existing Gumloop session by updating its name; the value is trimmed and must be 1-256 characters.

Instructions

Rename a session. name is the only mutable field; it is trimmed and must be between 1 and 256 characters after trimming.

Returns the full session, in the same shape as Retrieve session. Explicit confirmation is required for this exact account operation. Runs can spend credits or trigger downstream actions; never resubmit unknown outcomes automatically.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
accountNoNamed private Gumloop account; selects private credentials and user/team identity.
confirmNoSet true only when the user asked for exactly this action.
payloadNoComplete JSON request body instead of body flags. Preserves current endpoint fields and values.
session_idYesID of the session to rename.
payload_fileNoRegular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv3.0.0
    • addedInput schema / $defs / name
      Added value: +{
+  "description": "New name for the session. Leading and trailing whitespace is removed before the 1-256 character limit is applied, so a whitespace-only value is rejected.",
+  "maxLength": 256,
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true for this exact requested account change, agent/flow execution, upload or deletion."New value: +"Set true only when the user asked for exactly this action."
    • addedInput schema / properties / name / $ref
      Added value: +"#/$defs/name"
    • removedInput schema / properties / name / description
      Removed value: -"New name for the session. Leading and trailing whitespace is removed before the 1-256 character limit is applied, so a whitespace-only value is rejected."
    • removedInput schema / properties / name / maxLength
      Removed value: -256
    • removedInput schema / properties / name / minLength
      Removed value: -1
    • removedInput schema / properties / name / type
      Removed value: -"string"
    • addedInput schema / properties / payload / properties / name / $ref
      Added value: +"#/$defs/name"
    • removedInput schema / properties / payload / properties / name / description
      Removed value: -"New name for the session. Leading and trailing whitespace is removed before the 1-256 character limit is applied, so a whitespace-only value is rejected."
    • removedInput schema / properties / payload / properties / name / maxLength
      Removed value: -256
    • removedInput schema / properties / payload / properties / name / minLength
      Removed value: -1
    • removedInput schema / properties / payload / properties / name / type
      Removed value: -"string"
  2. First observedv2.0.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructive=true, idempotent=false and openWorld=true; the description adds the confirmation gate, the trimming/normalization rule, and the return shape, which are not in the annotations. The credit/downstream-action sentence is fairly generic boilerplate that reads as policy text rather than tool-specific behavior.

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 the operation and the key constraint, then the return shape. Efficient overall, though the closing sentence about credits and automatic resubmission is generic and not obviously tied to a rename.

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?

No output schema exists, but the description compensates by stating the return is the full session in retrieve_session's shape. The confirmation requirement and normalization rule are covered; the remaining gap is the unexplained relationship among `name`, `payload` and `payload_file`.

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 description coverage is 83%, so the schema already documents `name`, `session_id`, `account`, `confirm` and the payload options; the description mostly repeats the trimming/1-256 rule. It does not explain how `payload`/`payload_file` relate to the body flags, which is the one parameter relationship an agent still has to guess at.

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+resource ('Rename a session') and immediately narrows scope by naming the only mutable field. It also anchors the return shape to the sibling `retrieve_session`, so an agent knows exactly what comes back without opening the schema.

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

Usage Guidelines4/5

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

Gives real when-to-use context: explicit confirmation is required for this exact operation, and the description warns against automatic resubmission of unknown outcomes. It does not enumerate alternatives (there is no competing rename sibling), so it falls just short of explicit when-not guidance.

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

Deploy Server

Other Tools