Skip to main content
Glama

Storage Management

storage_manage
Destructive

Fastio files and folders (write): create folders, copy, move, rename, restore, add files/links, transfer, versions, locks, node metadata set/extract. Destructive: delete (to trash), purge (permanent), metadata-delete. Reads are on storage. action='describe' gives the full reference.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keysNometadata-delete: JSON array of metadata keys to delete (omit to clear all).
nameNoName for new folder or file.
actionYesOperation. Use 'describe' for full action reference.
node_idNoStorage node opaque ID (files and folders are both nodes), or 'root'.
durationNolock-acquire: lock length in seconds (60-3600). The platform default is short (300s measured).
new_nameNoNew name for file or folder.
node_idsNoStorage node opaque IDs (details: 1-25 max).
share_idNoadd-link: the share to link. Dual-type actions: alias for profile_id implying profile_type=share.
node_typeNorename: optional type hint; skips the type-probe round-trip. Omit to probe.
upload_idNoOpaque ID of completed upload session.
context_idNoAlias for profile_id (either name works)
key_valuesNometadata-set: JSON object of field-name -> value (max 100) from the workspace field vocabulary. Writes only the named fields; cannot clear one (metadata-delete clears).
lock_tokenNolock-release: the token lock-acquire returned (required).
profile_idNoWorkspace or share ID (19-digit, or custom name); pair with profile_type. Typed aliases imply the type: workspace_id (workspace), share_id (share, dual-type actions); also context_id / instance_id.
version_idNoVersion ID to restore.
instance_idNoAlias for profile_id (REST/how-to name; profile_id is canonical).
template_idNoRETIRED (metadata templates were removed): supplying it fails the request. Write with key_values; scope extraction with extract_fields.
context_typeNoAlias for profile_type (either name works)
profile_typeNoProfile type: "workspace" or "share".
workspace_idNoAlias for profile_id that implies profile_type=workspace. Valid on every action.
if_version_idNorename: compare-and-swap base, the node's `version` from your last read. A stale base is rejected with a 409 naming the current version; nothing changes.
transfer_modeNo'copy' (default) or 'move'. 'move' invalid for node_id 'root'.
dest_parent_idNotransfer: destination parent folder in the OTHER instance, or 'root'. copy/move: alias for target_parent_id.
extract_fieldsNometadata-extract(-all): JSON array of field names (e.g. `["vendor","amount"]`); omit for a full extract. Not a strict filter on single-node extraction (see describe).
parent_node_idNoParent folder opaque ID, or 'root'.
describe_actionNoWith action='describe': return one action's params and notes instead of the action index.
dest_instance_idNoDestination workspace or share profile ID.
target_parent_idNoDestination folder opaque ID, or 'root'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / if_version_id
      Added value: +{
      +  "description": "rename: compare-and-swap base, the node's `version` from your last read. A stale base is rejected with a 409 naming the current version; nothing changes.",
      +  "minLength": 1,
      +  "type": "string"
      +}
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations flag destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds real value beyond that by grading destruction: delete goes 'to trash' while purge is 'permanent', and metadata-delete is destructive. It does not cover auth/permission requirements or return behavior, keeping it below a 5.

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?

Three dense sentences, front-loaded with the write scope and followed by the destructive list and the escape hatch. Efficient, though the action list is compressed to near-telegraphic style with minimal connective text.

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 tool with 18 actions, 28 params, and no output schema, the description summarizes scope correctly and delegates full detail to action='describe', which is an adequate completeness strategy. It could say more about the dual-instance transfer/auth model, but nothing critical for correct invocation is missing.

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 100% and the schema itself documents every parameter (including aliases, lock durations, extract_fields). The description adds no parameter-level syntax beyond pointing the agent to action='describe', so the schema does the heavy lifting and baseline 3 applies.

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 class (write operations) on a specific resource (Fastio files and folders), then enumerates the mutation categories. It explicitly distinguishes itself from the 'storage' sibling by declaring 'Reads are on `storage`', so an agent can route without opening either 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?

Clearly routes read vs write via the 'storage' pointer and directs discovery through action='describe'. It gives clear context for when to use this tool versus the read sibling, but does not disambiguate among the many actions beyond grouping them.

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