Skip to main content
Glama

workspace

Destructive

Workspace management: list/details/update/delete, archive, members, notes, quickshares, share import, import toggle. NOTE: metadata actions MOVED — the workspace metadata vocabulary → metadata tool; node-level metadata → storage tool. There are no metadata-* actions on this tool. Call action='describe' for the full action/param reference. Destructive: delete (workspace + all files). ⚠️ intelligence COSTS CREDITS (10/page) — only enable on explicit user request; toggle is rate-limited. Verbosity (detail param): list/available/members/list-shares default to terse (compact rows). details defaults to full (drill-down). Pass an explicit detail='standard'|'full' to override.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName. Send "null" to clear on update.
limitNoMaximum number of items to return (1-500, default 100)
actionYesOperation. Use 'describe' for full action reference.
detailNoPer-entity verbosity for list/available/members/list-shares/details. Defaults: terse for list/available/members/list-shares, full for details. See action='describe' for per-level field lists.
offsetNoNumber of items to skip (default 0)
org_idNoFilter workspaces to this org.
blob_idNoBlob ID from POST /blob. Preferred for large note content (UTF-8 decoded). Single-use.
confirmNoMust match folder_name or numeric ID.
contentNoPlain text/markdown. Notes: max 102400 bytes (100 KiB) — use blob_id for larger.
node_idNoStorage tree node opaque ID. Both files and folders are nodes — use this name regardless of which.
archivedNoFilter by archive status (default "false").
blob_refNoAlias for blob_id (deprecated).
share_idNo19-digit numeric ID or custom name of share to import.
note_nameNoNote filename (must end with .md).
parent_idNoParent folder opaque ID or 'root'.
perm_joinNoWho can join the workspace.
descriptionNoDescription. Newlines allowed. Send "null"/"" to clear on update.
folder_nameNoURL-safe workspace folder name (4-80 chars).
accent_colorNoBrand accent color JSON. "null" to clear.
check_org_idNoOrg ID for check-name — suggests org-prefixed alternative if name taken.
intelligenceNoToggle AI features. ⚠️ COSTS CREDITS (10/page) — only enable on explicit user request. Disable flushes embeddings; re-enable re-indexes. Rate-limited.
workspace_idNoWorkspace opaque ID. Use this when only workspaces are valid (not shares or other contexts). For polymorphic contexts use profile_id. 19-digit numeric ID or custom name.
display_limitNoHow many items to return. Default 10, max 500. The MCP trims post-fetch; backend page_size stays MCP-internal so the platform cache stays warm. Applies to list, list-shares, members.
name_to_checkNoFolder name to check availability.
owner_definedNoCustom properties JSON. "null"/"" to clear.
describe_actionNoWhen action='describe', narrow the output to ONE action's full params/notes (e.g. 'list'). Omit to get the compact action index.
background_color1NoBackground color 1 JSON. "null" to clear.
background_color2NoBackground color 2 JSON. "null" to clear.
perm_member_manageNoWho can manage members.

TDQS

A4.7/5.0
Behavior5/5

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

The description exposes destructive scope ('delete (workspace + all files)'), cost/rate-limit implications ('intelligence COSTS CREDITS (10/page)'), side effects of toggling intelligence ('Disable flushes embeddings; re-enable re-indexes'), and verbosity defaults. Annotations only mark destructiveHint=true and readOnlyHint=false, so the description adds substantial behavioral context without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence carries load-bearing operational information: exclusions, destructive warning, cost caveats, verbosity defaults. It front-loads purpose and is organized logically, so an agent can quickly scan the key points without wading through fluff.

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 tool with 29 parameters and 20 actions, the description covers the full scope, explicit exclusions, destructive/cost behavior, and points to action='describe' for exhaustive per-action details. It is complete enough for an agent to decide whether to invoke this tool and how to route the intent.

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 100%, so the baseline is 3. The tool description mostly echoes schema details like the `detail` param defaults and intelligence cost warning, which are already present in the schema's property descriptions. It does not add meaningful new parameter-level explanation beyond what the schema already conveys.

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?

Description opens with 'Workspace management: list/details/update/delete, archive, members, notes, quickshares, share import, import toggle' – a concrete verb+resource scope that names the operations. It further distinguishes itself from siblings by stating metadata actions moved to `metadata` and `storage` tools, so an agent knows this tool's boundaries.

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?

Explicitly tells the agent when not to use this tool: 'metadata actions MOVED — ... There are no `metadata-*` actions on this tool.' It also instructs calling action='describe' for the full action/param reference and warns to enable intelligence only on explicit user request. These are clear usage conditions beyond generic descriptions.

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.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool covers a clearly distinct domain (auth, storage, shares, comments, events, AI, etc.), and overlapping concepts like share vs. fileshare are explicitly disambiguated with deprecation notes and cross-references. An agent can reliably select the correct tool for a task without ambiguity.

Naming Consistency3/5

Tool names are all lowercase single words, but they mix nouns (user, org, workspace) with verbs (download, find, upload) and include a hyphenated 'how-to'. There is no consistent verb_noun or noun-only pattern, though the names are still readable and memorable.

Tool Count4/5

19 tools is slightly above the typical 3-15 sweet spot, but the platform's breadth (auth, file management, sharing, collaboration, AI, metadata, and help) justifies this count. Each tool represents a substantial domain area, so none feel redundant.

Completeness5/5

The toolset provides full lifecycle coverage for the platform: authentication, user/org/workspace management, file storage/upload/download/search, sharing (both quickshare and durable file shares), comments, events, metadata pipelines, AI assistance, and product help. No obvious dead ends or missing operations are apparent.

Resources