Gumloop MCP Server

Update skill

update_skill

Destructive

Replace a skill's files with a new upload, reparse SKILL.md to refresh its name, description, and metadata, and create a new version; confirmation is required.

Instructions

Replace a skill's files with a new upload. Reparses SKILL.md to update the skill's name, description, and metadata, and creates a new version. Maximum upload size is 10 MB. 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

Name	Required	Description
`files`	No
`account`	No	Named private Gumloop account; selects private credentials and user/team identity.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Preserves current endpoint fields and values.
`skill_id`	Yes	ID of the skill to update.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv3.0.0Oct 5, 2026

addedInput schema / $defs / files

Added value: +{
+  "description": "Regular local file paths, not base64; each file and total upload at most 5 MiB. Paths cannot be symlinks.",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 25,
+  "minItems": 1,
+  "type": "array"
+}

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 / files / $ref
```
Added value: +"#/$defs/files"
```

removedInput schema / properties / files / description

Removed value: -"Regular local file paths, not base64; each file and total upload at most 5 MiB. Paths cannot be symlinks."

removedInput schema / properties / files / items

Removed value: -{
-  "minLength": 1,
-  "type": "string"
-}

removedInput schema / properties / files / maxItems
```
Removed value: -25
```
removedInput schema / properties / files / minItems
```
Removed value: -1
```
removedInput schema / properties / files / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / files / $ref
```
Added value: +"#/$defs/files"
```

removedInput schema / properties / payload / properties / files / description

Removed value: -"Regular local file paths, not base64; each file and total upload at most 5 MiB. Paths cannot be symlinks."

removedInput schema / properties / payload / properties / files / items
```
Removed value: -{
-  "minLength": 1,
-  "type": "string"
-}
```
removedInput schema / properties / payload / properties / files / maxItems
```
Removed value: -25
```
removedInput schema / properties / payload / properties / files / minItems
```
Removed value: -1
```
removedInput schema / properties / payload / properties / files / type
```
Removed value: -"array"
```

First observedv2.0.1Oct 3, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true; the description adds real value on top by disclosing the reparse/versioning behavior, the confirmation requirement, and the credit/downstream-action warning. The only gap is that it does not describe what happens to the prior version or how failures surface.

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 core action and effect, followed by size and safety constraints. The credit/downstream-action sentence is somewhat boilerplate but carries genuine operational meaning for a destructive, non-idempotent call.

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?

For a destructive mutation with no output schema and 83% schema coverage, the description covers effect, versioning, confirmation, and retry safety. The size-limit inconsistency with the schema and the absence of any failure-mode description are the remaining gaps.

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 skill_id, account, confirm, payload, and payload_file. The description's only parameter-relevant claim — 'Maximum upload size is 10 MB' — actually conflicts with the schema, which caps each file and the total at 5 MiB, so it adds confusion rather than clarity. Baseline 3 applies.

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?

States a specific verb and resource ('Replace a skill's files with a new upload') plus the concrete side effects: reparse of SKILL.md, update of name/description/metadata, and new version creation. It does not distinguish itself from siblings like create_skill, delete_skill, or update_agent_skills, so it stops 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 Guidelines3/5

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

Provides some operational guidance — explicit confirmation is required, and unknown outcomes must not be auto-resubmitted — which implies when it is safe to call. However, it never names an alternative (create_skill, update_agent_skills, delete_skill) or states the condition that selects this tool over them, so usage is only implied.

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

Deploy Server

Update skill

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools