AI-first file sharing and collaboration. 251 tools give agents a full workspace: file storage, branded shares, comments, workflows, and built-in RAG. 50GB free, no credit card.
Ripley — the MCP delegation surface over Fastio's RAG agent. Ripley is read-only for storage CONTENT: it answers natural-language questions about workspace/share files & folders (with citations) and never creates/edits/deletes your files — for content writes, call the primitive MCP tools directly. It DOES create/manage chat threads (chat-create/chat-update/chat-delete/message-send) and can generate shares (share-generate). Prefer Ripley over issuing many primitive reads: ask one NL question and let the server-side agent search + synthesize. Quick start: action='ask' (question + profile) → returns {answer_text, citations, chat_id, message_id, web_url}; action='status' for an engineered workspace-status summary. Lower-level chat/message actions remain for multi-turn control. Call action='describe' for the full action/param reference. Destructive: chat-delete. Side effects: ask/status/chat-create/message-send consume credits; chat-cancel terminates an in-progress message (partial tokens billed; idempotent). Verbosity (detail param): chat-list/message-list default to terse (compact rows). chat-details/message-details default to full (drill-down). Pass an explicit detail='standard'|'full' to override (best-effort: chat/message/activity endpoints may not yet honor detail server-side).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | chat-create (workspace only): 'user' (default) or 'agent' — flags the chat as agentic; set at creation, immutable; not accepted on share chats. chat-list: filter by 'user'|'agent'|'all'. | |
| name | No | New chat name. | |
| wait | No | message-read only. Default true: bounded-wait for completion (up to ~24s on a workspace via the activity long-poll). Set false for a single-shot status probe (one details fetch, ~1 round-trip) — useful against strict ~30s client timeouts. | |
| files | No | File opaque IDs (max 25, share share-generate). | |
| limit | No | chat-list/message-list page size. Best-effort: the AI API spec documents NO pagination on the chat-list or message-list endpoints (both return all rows under {count, items}), so this is forwarded but may be a silent no-op until the platform adds paging. | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| detail | No | Per-entity verbosity for chat-list/chat-details/message-list/message-details (best-effort: chat/message/activity endpoints may not yet honor detail server-side). Defaults: terse for list-style (chat-list, message-list), full for details (chat-details, message-details). See action='describe' for per-level field lists. | |
| offset | No | chat-list/message-list pagination offset — see the limit caveat (no documented paging on these endpoints; forwarded best-effort). | |
| chat_id | No | AI chat ID. | |
| privacy | No | Chat privacy (default: private). Workspace chat-create only — share chats are always private. | |
| node_ids | No | File node IDs (max 25, workspace share-generate). | |
| share_id | No | Alias for profile_id when the profile is a share — implies profile_type=share (so profile_type may be omitted). | |
| context_id | No | Alias for profile_id (either name works) | |
| message_id | No | AI message ID. | |
| profile_id | No | Polymorphic context ID (pair with profile_type=workspace|share). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also context_id / instance_id. 19-digit workspace or share ID. | |
| query_text | No | Question or prompt (max 32,000 chars). | |
| instance_id | No | Alias for profile_id (REST/how-to name; profile_id is canonical). | |
| context_type | No | Alias for profile_type (either name works) | |
| files_attach | No | Attach workspace FILES for the AI to read directly (comma-separated nodeId:versionId pairs; versionId optional → backend resolves current). Works regardless of workspace intelligence. A missing/inaccessible/ineligible node ERRORS (not a silent drop). See describe. | |
| profile_type | No | Profile type: "workspace" or "share". | |
| workspace_id | No | Alias for profile_id when the profile is a workspace — implies profile_type=workspace (so profile_type may be omitted). | |
| folders_attach | No | Attach workspace FOLDERS for the AI to read (comma-separated folder nodeIds; no depth). Denied on restricted-view shares. See describe. | |
| include_deleted | No | chat-list: if true, list deleted chats via the /deleted variant (workspace AND share). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=true), the description details that storage content is read-only, but chat threads and shares are created, and specifically names 'Destructive: chat-delete'. It further discloses credit consumption for certain actions, idempotency of chat-cancel, and best-effort behavior of detail/pagination parameters — no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, every sentence carries actionable information: purpose, usage preference, write caveat, quick start, side effects, destructive actions, and verbosity defaults. The structure is front-loaded and logically organized, making the length appropriate for a 23-parameter multi-action tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is exceptionally complete for a complex tool with no output schema. It covers the core workflows (ask, status, chat management, share generation), return shape for ask, side effects (credits, cancellation), and edge cases like the wait parameter and best-effort detail/pagination. Combined with the rich schema, an agent has all necessary context to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 23 parameters (100% coverage), so baseline is 3, but the description adds meaning beyond the schema: it highlights the 'ask' quick start with its return shape, 'status' and 'describe' actions, and explains default verbosity for list vs details actions. It also clarifies that 'limit' and 'offset' may silently be no-ops.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'the MCP delegation surface over Fastio's RAG agent' with a specific verb: 'answers natural-language questions about workspace/share files & folders (with citations)'. It also distinguishes itself from siblings by stating it never creates/edits/deletes files and that content writes should use primitive MCP tools directly, plus it manages chat threads and shares.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Prefer Ripley over issuing many primitive reads: ask one NL question' and 'for content writes, call the primitive MCP tools directly' — a clear when-to-use and when-not-to-use. It also notes lower-level chat/message actions for multi-turn control and points to 'describe' for full reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brand asset management (logos, banners, profile photos) on org/workspace/share/user. Upload, delete, list, read. Call action='describe' for the full action/param reference. Destructive: delete.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Operation. Use 'describe' for full action reference. | |
| content | No | Plain text content (e.g. SVG). | |
| asset_id | No | Asset ID or name. | |
| metadata | No | Additional metadata as JSON array string. | |
| entity_id | No | Opaque ID of a specific object (file, comment, etc.). Pair with entity_type to disambiguate. Entity ID (optional for user). | |
| file_name | No | Original file name. | |
| asset_type | No | Asset type key (e.g. 'logo', 'banner', 'photo'). | |
| entity_type | No | Entity type. | |
| file_base64 | No | Base64-encoded binary content. | |
| content_type | No | MIME type (default application/octet-stream). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, and the description explicitly calls out 'Destructive: delete', adding specificity beyond the annotation. It also discloses the range of actions. No contradiction with annotations (readOnlyHint=false, destructiveHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, followed by operational scope and a clear pointer to the describe action. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters and no output schema, but the schema itself is richly described. The description covers the main actions and explicitly defers to action='describe' for full details. Minor gap: the 'types' action is not mentioned, but the pointer to describe mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all parameters are already documented in the schema. The tool description does not add parameter-level meaning beyond the schema, but it does provide domain context (e.g., logos, banners, profile photos). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb+resource: 'Brand asset management' with concrete asset types (logos, banners, profile photos) and scope (org/workspace/share/user). It lists key operations (upload, delete, list, read) and distinguishes itself from generic sibling tools like upload/download by naming the asset domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on what the tool manages and its entity scope. Points users to action='describe' for the full action/param reference, which is useful meta-guidance. However, it does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auth & sessions: signin, signup, signout, 2FA, PKCE, API keys, OAuth sessions. Call action='describe' for the full action/param reference. Destructive: api-key-delete, oauth-revoke, oauth-revoke-all.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Verification or authorization code. Meaning is action-specific — see action='describe' for the per-action reference (e.g. 2FA code for 2fa-verify, reset code for password-reset, OAuth code for pkce-complete). | |
| name | No | API key label. | |
| No | Email address. | ||
| token | No | 2FA / verification token. Meaning is action-specific — see action='describe' for the per-action reference (e.g. 2FA-disable token, 2fa-verify-setup token, 2FA token for api-key-create/api-key-delete). | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| key_id | No | API key identifier. | |
| scopes | No | Scope strings, e.g. ['org:123:rw']. Omit for full access. | |
| api_key | No | Fastio API key. | |
| channel | No | 2FA channel. | |
| expires | No | Token lifetime in seconds. | |
| password | No | Account password. | |
| last_name | No | Family name. | |
| password1 | No | New password. | |
| password2 | No | New password confirmation. | |
| agent_name | No | Agent name for the approval screen and audit logs. If omitted on pkce-login this DEFAULTS to the MCP client's self-reported name (clientInfo.name from initialize), which is caller-supplied and NOT platform-verified — a human approves it on the consent screen, but it is not a vouched vendor. Pass it explicitly to control what is recorded. | |
| first_name | No | Given name. | |
| scope_type | No | PKCE scope type. Default 'user' (full access). | |
| session_id | No | OAuth session identifier. | |
| email_token | No | Email verification code. | |
| key_expires | No | ISO 8601 expiration datetime. | |
| describe_action | No | When action='describe', narrow the output to ONE action's full params/notes (e.g. 'status'). Omit to get the compact action index. | |
| exclude_current | No | Skip current session in revoke-all. | |
| current_session_id | No | Current session ID for exclusion. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as potentially destructive, and the description goes further by naming the specific destructive actions: api-key-delete, oauth-revoke, and oauth-revoke-all. This is valuable context beyond the annotation. However, it does not describe side effects like session invalidation or credential revocation details, so it earns a 4 rather than 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: it states the domain, lists operation categories, points to the self-describing describe action, and flags destructive operations. The most important usage instructions are front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 23 parameters, 29 actions, and no output schema, the description is incomplete on its own but compensates by directing the agent to action='describe' for the complete reference. It also covers the key risk factor (destructive actions). The absence of output/return-value information is a minor gap, but the describe mechanism reduces the impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description itself does not add much new parameter-level meaning beyond directing the agent to action='describe' for per-action parameter details. This meets the baseline for high schema coverage but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool's domain as authentication and sessions, and enumerates the main operation families: signin, signup, signout, 2FA, PKCE, API keys, and OAuth sessions. While it lacks a single imperative verb like 'manage', it is not a tautology and is clearly distinct from the non-auth sibling tools. The action='describe' pointer also clarifies that this is an action-dispatching tool rather than a simple resource tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage guidance by telling the agent to call action='describe' for the full action/parameter reference, which is essential for a 29-action tool. It also flags which actions are destructive, helping the agent choose appropriately. It does not explicitly state when not to use the tool, but the auth/session domain and sibling list make the boundary reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comments on files: add/list/delete/react, anchor to image regions, A/V timestamps, PDF pages, or text selections. Call action='describe' for the full action/param reference. Destructive: delete, bulk-delete. Verbosity (detail param): list/list-all default to terse (compact rows). details defaults to full (drill-down). Pass an explicit detail='standard'|'full' to override (best-effort — may be a silent no-op until the comments API honors output=; see describe).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort: 'created' or '-created' (default newest first). | |
| text | No | Max 8192 body / 500 DISPLAY text (mention markup discounted) — the 500 usually BINDS. Both count CHARACTERS — CJK and emoji cost one each, same as ASCII. Mentions count toward 8192 only. A separate 2048-BYTE budget applies to the JSON-encoded `reference` anchor, where each non-ASCII character costs SIX bytes. | |
| emoji | No | Single emoji character. | |
| limit | No | Page size 2-200. | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| detail | No | Per-comment verbosity for list/list-all/details. Defaults: terse for list/list-all (compact rows), full for details (drill-down). See action='describe' for per-level field lists. | |
| offset | No | Offset for pagination. | |
| node_id | No | Storage tree node opaque ID. Both files and folders are nodes — use this name regardless of which. | |
| share_id | No | Alias for profile_id when the profile is a share — implies profile_type=share (so profile_type may be omitted). | |
| reference | No | Anchor: image region, A/V timestamp, PDF page, or text selection. | |
| comment_id | No | Comment opaque ID. | |
| context_id | No | Alias for profile_id (either name works) | |
| profile_id | No | Polymorphic context ID (pair with profile_type=workspace|share). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also context_id. 19-digit profile ID. | |
| properties | No | Arbitrary key-value JSON object metadata (edit action only). Accepts a native object or a JSON string. Merged into the comment's stored properties; server-managed keys (reactions, version, version_hash, edited_at, content_filtered, mentions) supplied here are ignored. | |
| comment_ids | No | Array of comment opaque IDs. | |
| context_type | No | Alias for profile_type (either name works) | |
| profile_type | No | Profile type. | |
| workspace_id | No | Alias for profile_id when the profile is a workspace — implies profile_type=workspace (so profile_type may be omitted). | |
| display_limit | No | list-all only — ignored on the markdown list action. Number of comments to return to the agent (default 10, max 200). Backend page_size unchanged for cache warmth (JSON only). Trims post-fetch only. | |
| include_total | No | Include total count in response. | |
| reference_type | No | Filter by anchor type. | |
| include_deleted | No | Include soft-deleted. | |
| parent_comment_id | No | Parent comment ID for reply (single-level threading). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds meaningful behavioral context: explicitly stating 'Destructive: delete, bulk-delete' and disclosing that the detail override is 'best-effort — may be a silent no-op until the comments API honors output='. This goes beyond the annotations but doesn't fully describe all behaviors, making 4 appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, covering purpose, action discovery, destructive behavior, and verbosity controls in just a few sentences. It is front-loaded with the main purpose and every sentence contributes, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (23 parameters, 10 actions, nested reference objects), the description does a good job by summarizing scope, pointing to action='describe' for full details, and covering key behavioral nuances. It doesn't explain return values or the full reference structure, but the schema and describe action compensate, so a 4 is fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 description adds a small amount of parameter semantics via the verbosity discussion (detail defaults), but this is already present in the schema's detail parameter description. No significant new parameter meaning is introduced, so the baseline score stands.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Comments on files: add/list/delete/react' and explicitly mentions anchoring to image regions, A/V timestamps, PDF pages, or text selections. This specific verb+resource pairing distinguishes it from all sibling tools, none of which relate to comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, such as calling action='describe' for the full reference and explaining verbosity defaults for list/list-all vs details. However, it does not explicitly mention when not to use this tool or compare it to alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download URLs for files (file-url), folder ZIPs (zip-url), and quickshare links (quickshare-details — DEPRECATED, use the fileshare tool's create action for new shares). Consumes bandwidth credits. Call action='describe' for the full action/param reference.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Operation. Use 'describe' for full action reference. | |
| node_id | No | Storage tree node opaque ID. Both files and folders are nodes — use this name regardless of which. | |
| share_id | No | Alias for profile_id when the profile is a share — implies profile_type=share (so profile_type may be omitted). | |
| context_id | No | Alias for profile_id (either name works) | |
| profile_id | No | Polymorphic context ID. Pair with profile_type=workspace|share. Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also context_id / instance_id. 19-digit profile ID or custom name. | |
| version_id | No | Specific file version ID. | |
| instance_id | No | Alias for profile_id (REST/how-to name; profile_id is canonical). | |
| context_type | No | Alias for profile_type (either name works) | |
| profile_type | No | Profile type. | |
| workspace_id | No | Alias for profile_id when the profile is a workspace — implies profile_type=workspace (so profile_type may be omitted). | |
| quickshare_id | No | Quickshare opaque identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, and the description adds 'Consumes bandwidth credits' which is valuable non-obvious behavior beyond the annotations. It also notes deprecation. No contradiction with structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and includes essential caveats (deprecation, bandwidth credits, describe action) without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter, multi-action tool, the description plus 100% schema coverage and the `describe` action provides a fairly complete picture. It doesn't detail return values, but the `describe` action is explicitly offered to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning to the `action` parameter by explaining what each enum value (file-url, zip-url, quickshare-details) does, something the schema's action description omits. It also flags deprecation, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Download URLs for files (file-url), folder ZIPs (zip-url), and quickshare links'. It identifies specific actions and differentiates from siblings like `fileshare` by noting the deprecated quickshare-details and the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context by mentioning bandwidth credits and explicitly deprecating quickshare-details with a pointer to the `fileshare` tool for new shares. However, it doesn't explicitly state when to prefer this tool over all alternatives beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Event log and activity monitoring for workspaces and shares. Also surfaces the per-member DASHBOARD — a 'what's on your plate' feed of cards (@mentions, file activity) for one workspace, with view-only dismiss/snooze and a best-effort AI overlay. Call action='describe' for the full action/param reference. Verbosity (detail param): search/activity-list/activity-poll default to terse (compact rows). summarize defaults to standard (envelope around the AI summary). details defaults to full (drill-down). Pass an explicit detail='terse'|'standard'|'full' to override (best-effort on summarize/activity-list/activity-poll — only search/details honor output=; see describe).
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Max seconds server holds connection (1-95, default 95). | |
| event | No | Exact event name. See describe action for catalog. | |
| limit | No | Max results (1-250, default 100). | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| cursor | No | Last activity timestamp for incremental polling. | |
| detail | No | Per-record verbosity for search/summarize/details/activity-list/activity-poll. Defaults: terse for search/activity-list/activity-poll (compact rows), standard for summarize, full for details (drill-down). See action='describe' for per-level field lists. | |
| offset | No | Pagination offset. | |
| org_id | No | Filter by organization profile ID. | |
| user_id | No | Filter by the event's stored subject column. DO NOT read it as "the person this event is about": the platform DERIVES that column instead of taking it from the emitter, so it can name an arbitrary related user rather than the subject. For "what did this person do", use calling_user_id (the actor) and read its note. See the search note before relying on either. | |
| card_key | No | Dashboard card identity "<lane>:<id>" (e.g. "mention:123"). From a dashboard-list card. Required for dashboard-dismiss/dashboard-undismiss; URL-encoded into the path by the server. | |
| category | No | Event category. See describe action for valid values. `node` IS THE AI/RAG PIPELINE, NOT FILE OPERATIONS — file activity lives under `workspace` AND `share`, so query both. CLOUD IMPORT IS NOT `cloudsync` HERE — that is an ACTIVITY field on a different taxonomy and returns nothing rather than erroring. Use category="import", narrowed with subcategory="cloud_import" for graft traffic only. | |
| event_id | No | Alphanumeric event opaque ID. | |
| share_id | No | Filter by share profile ID. | |
| entity_id | No | Opaque ID of a specific object (file, comment, etc.). Pair with entity_type to disambiguate. 19-digit workspace, share, or File Share ID to monitor (activity-poll long-polls GET /activity/poll/{id}/ — for a File Share id this surfaces its file_share_* feed to WORKSPACE MEMBERS only; recipients get no feed). | |
| object_id | No | Filter by related object opaque ID (file, folder, etc.). | |
| context_id | No | Alias for profile_id (either name works) | |
| profile_id | No | Polymorphic context ID. Pair with profile_type=workspace|share|org|fileshare. Use workspace_id instead when only workspaces are valid. 19-digit profile ID (workspace, share, or File Share). | |
| visibility | No | Filter by event visibility level (external_audit_log | external). Default returns both, excludes internal. | |
| created_max | No | ISO 8601 datetime — events on or before. | |
| created_min | No | ISO 8601 datetime — events on or after. | |
| subcategory | No | Event subcategory. See describe action for valid values. | |
| acknowledged | No | Filter by acknowledgment status. | |
| context_type | No | Alias for profile_type (either name works). | |
| lastactivity | No | Timestamp from prior poll's response. Omit on first call. | |
| profile_type | No | Profile type: "workspace", "share", or "fileshare". `fileshare` is valid for activity-list (long-poll a File Share's feed — workspace members only; recipients get no feed). | |
| snooze_until | No | Optional for dashboard-dismiss: a future "Y-m-d H:i:s UTC" timestamp to snooze the card until (it reappears after). Omit for a permanent dismiss. | |
| user_context | No | Focus guidance for AI summary, e.g. "Focus on uploads". | |
| workspace_id | No | Workspace opaque ID. Use this when only workspaces are valid (not shares or other contexts). For polymorphic contexts use profile_id. Filter by workspace profile ID. | |
| calling_user_id | No | Filter by the user who triggered the event. | |
| parent_event_id | No | Filter by parent event ID for serial/batch events. SCOPE-EXCLUSIVE: cannot combine with any filter other than acknowledged, limit, offset. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behaviors: DASHBOARD dismiss/snooze is view-only, the AI overlay is best-effort, activity-poll long-polls with server-held connections, File Share feeds are visible to workspace members only, and incorrect category choices like 'cloudsync' return nothing rather than erroring. This is substantial, decision-critical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with purpose, then moves into actionable defaults and exceptions. It is slightly run-on in the verbosity section, but every sentence carries useful information, especially for a 30-parameter umbrella tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, multi-action tool with no output schema, the description covers major caveats, defaults, and points to action='describe' for the full action/param reference. It does not spell out return shapes beyond compact rows/envelope/drill-down hints, but the schema plus describe action make the definition reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds high-value semantics beyond the schema: user_id is not the actor, category 'node' means AI/RAG pipeline rather than file operations, cloud import is not 'cloudsync', and only search/details honor output=. These nuances prevent real invocation errors that the schema alone would not catch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's resource: event log and activity monitoring for workspaces and shares, plus the per-member DASHBOARD feed. It has a specific scope, though it does not explicitly differentiate itself from sibling tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives actionable usage guidance: call action='describe' for the full reference, and it explains verbosity defaults and which actions honor which parameters. It lacks explicit exclusion statements for sibling tools, but the context is clear enough for an agent to know when event activity/dashboard functionality is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unified search across a workspace or share — ONE query, results GROUPED BY TYPE into buckets (files, metadata [workspace only], comments), each independently paginated and health-reported. Call action='describe' for the full action/param reference. For a FILE lookup start with storage action=search — smaller default page, files_scope/metadata_filters, the depth surface. Use find when you also need metadata-only hits or comments in the same call; metadata action=search for lexical metadata fields alone.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Alias for search (the name storage + code-mode search use). | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| detail | No | Files-bucket rows on workspaces AND shares: caps `content_snippet` (standard 600 bytes, terse 200, full untrimmed). On a WORKSPACE also the `facts` tier: standard (default) up to 8 fields WITH values, full up to 100, terse names-only so a terse row carries NO `facts`. Shares carry no facts at any tier. See action='describe'. | |
| search | No | Search query string. 1-1024 chars; empty/blank rejected (platform 1605). Searched across every applicable bucket. (Alias: query.) | |
| share_id | No | Alias for profile_id when profile_type=share. | |
| search_in | No | filename | content | both (DEFAULT). filename = name only, find-style. content = the AI's summary + semantic, NOT grep. OMIT unless you mean it — sending it changes the response shape (adds a search_metadata block); omitting reproduces today's behavior byte-for-byte. Pair filename with name_match. | |
| context_id | No | Alias for profile_id. | |
| name_match | No | auto (DEFAULT) | exact | prefix | contains | glob. exact = whole name; prefix = starts with; contains = substring — those three are LITERAL (* and ? are ordinary chars). glob = wildcards over the WHOLE name: *.pdf, report-*.xlsx. Do NOT pre-escape. Applies when search_in is filename or both; auto keeps today's relevance. Precise modes cap the pattern at 256 chars, reject an empty one. | |
| profile_id | No | Workspace or share opaque ID (19-digit numeric ID or custom name). Pair with profile_type. Four accepted aliases besides this one (five id params total): workspace_id, share_id, context_id, instance_id — the supplied id must match profile_type (workspace_id only with profile_type=workspace, share_id only with share). | |
| files_limit | No | files bucket page size (default 25). | |
| instance_id | No | Alias for profile_id (REST/how-to name; profile_id is canonical). | |
| context_type | No | Alias for profile_type. | |
| files_offset | No | files bucket result offset (default 0). | |
| profile_type | No | Profile to search: "workspace" or "share". (Alias: context_type.) | |
| workspace_id | No | Alias for profile_id when profile_type=workspace. | |
| case_sensitive | No | Case-sensitive matching for exact/prefix/contains/glob. Default false (like find -iname), which folds non-ASCII too. Ignored under name_match=auto. | |
| comments_limit | No | comments bucket page size (default 25). | |
| metadata_limit | No | metadata bucket page size (default 25). Workspace only — dropped from the request on a share (shares have no metadata bucket). | |
| comments_offset | No | comments bucket result offset (default 0). | |
| metadata_offset | No | metadata bucket result offset (default 0). Workspace only — dropped from the request on a share (shares have no metadata bucket). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds genuinely useful behavioral detail beyond those annotations: grouped buckets, independent pagination, health reports, search_in changing the response shape when sent, and the detail tier affecting the facts field. It does not fully enumerate every behavioral nuance, but with annotations covering the core safety profile, the added context justifies a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it front-loads the core behavior, then siblings, then parameter semantics, then the action='describe' pointer. The main trade-off is that the opening sentence is long. The structure is otherwise tight, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 20-parameter tool with 6 enums and no output schema, the description is strong: it covers result shape, pagination, health reporting, workspace-vs-share differences, and the action='describe' escape hatch. It does not restate every schema property, which is appropriate given 100% schema coverage. The main omission is not describing the search_metadata block shape after search_in is sent, but the escape hatch compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes beyond by explaining cross-parameter relationships: search_in changes response shape and pairs with name_match; name_match exact/prefix/contains treat * and ? literally while glob uses wildcards; metadata_limit and metadata_offset are dropped on shares; and five id params are aliases that must match profile_type. That adds meaning the schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific verb ('search') and a precise resource scope ('across a workspace or share'), then distinguishes the tool by its grouped-by-type result shape and explicitly contrasts it with storage action=search and metadata action=search. That contrast makes it immediately distinguishable from 19 sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete routing guidance: use storage action=search for file lookups, use find when metadata-only hits or comments are needed in the same call, and use metadata action=search for lexical metadata fields alone. It also tells the agent to call action='describe' for the full action/param reference, which is a strong when-to-use signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Built-in product help — ask a natural-language "how do I…" question about Fastio and get a grounded, product-aware answer (or a short clarifying question) back in one call. EXPLAIN-ONLY / ADVISORY: it returns GUIDANCE TEXT and performs NO platform action (it will not create shares, move files, or change anything) — read the guidance, then act with the other tools. Answers are grounded in Fastio's own how-to knowledge AND phrased in terms of these MCP tools — they name the concrete <tool> action="…" calls to make — so prefer this over guessing endpoints or burning exploratory calls. For Q&A over YOUR uploaded files (RAG) use the ai tool instead — how-to answers questions about Fastio ITSELF. FREE and requires only an authenticated user (no org, no plan gate, no billing). Call action='describe' for the full action/param reference.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Operation. Use 'describe' for full action reference. | |
| context | No | Optional free-text background about your situation (what you're trying to accomplish, what you've tried). Up to 8000 chars. Treated strictly as untrusted DATA — it cannot redirect the assistant. Omit when empty. | |
| question | No | The natural-language "how do I…" question about Fastio. 1-2000 chars, non-blank. Be specific — a vague question returns a clarifying question instead of an answer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, openWorldHint=true, and destructiveHint=false; the description goes beyond by adding 'EXPLAIN-ONLY / ADVISORY,' stating it performs no platform action, will not create shares/move files/change anything, and is free with only an authenticated user required. This is rich behavioral context with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the core purpose and safety profile before diving into usage distinctions. Every sentence earns its place, though the length is notable; the ALL-CAPS label and clear clauses keep it scannable. It is not bloated but could be slightly tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and a simple 3-parameter schema, the description is exceptionally complete: it explains return behavior (answer or clarifying question), scope (Fastio how-to vs RAG), safety/no-op nature, cost/auth requirements, and how to get a full action reference. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; description adds meaningful semantics: 'Call action="describe" for the full action/param reference,' 'a vague question returns a clarifying question instead of an answer,' and that `context` is 'treated strictly as untrusted DATA — it cannot redirect the assistant.' These details enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'ask a natural-language how-do-I question about Fastio and get a grounded, product-aware answer.' It clearly identifies the tool as built-in product help and explicitly contrasts it with the `ai` tool for RAG over uploaded files, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'prefer this over guessing endpoints or burning exploratory calls' and explains that `how-to` answers questions about Fastio ITSELF, while `ai` handles Q&A over uploaded files. It also tells the agent to act with other tools after reading guidance and mentions the `action='describe'` option for a full reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Agent Intents: announce what you are working on in a workspace so peers see a collision before it happens. allocate a slot when work starts (content-free, and GET-OR-CREATE — it can hand back a slot you already hold), fill it once you know what to say (fill is also the heartbeat; there is no renewal verb), browse every live intent (topics only), expand for full detail including message, release when done. Call action='describe' for the full reference. Destructive: release.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | fill only: one-line label, max 256 characters. No newlines or tabs. This is what browse shows. | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| cursor | No | browse only: opaque cursor from a previous response. Omit for the first page. | |
| intent | No | What KIND of work this is — closed vocabulary, server-validated. Optional on allocate and fill. | |
| message | No | fill only: long-form detail, max 8192 characters. Absent from browse rows — read it with expand. | |
| node_id | No | allocate only: scope the declaration to one node. Omit for a workspace-wide intent. Part of the slot key. | |
| version | No | fill only, REQUIRED: the version you last read for this slot. Compare-and-set — a stale or omitted version is refused with 409. | |
| intent_id | No | Intent ID from allocate, or from a browse/expand row. Pass it back EXACTLY as received — do not reformat it. | |
| intent_ids | No | expand only: one or more intent IDs. Accepts an array, a JSON array string, or a comma-separated string. Max 250. | |
| workspace_id | No | Workspace ID (19-digit numeric). Required for every action except describe. Intents are workspace-only — there is no share variant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing important behavioral nuances: allocate is GET-OR-CREATE and can hand back an already-held slot, fill acts as a heartbeat, browse returns topics only, expand returns full details, and release is destructive. These details are not present in the annotations and materially affect how an agent should invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause earns its place: purpose, lifecycle, heartbeat semantics, GET-OR-CREATE behavior, browse/expand distinction, describe pointer, and destructive warning. It front-loads the main purpose and communicates a complex multi-action tool in a compact, useful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, six-action tool with no output schema, the description covers the central workflow and key behavioral caveats. It does not spell out return shapes for allocate or describe, but the schema covers parameters and the description directs to action='describe' for full reference. A small gap remains, so 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter thoroughly. The description adds action-level semantics rather than parameter-level detail, which is appropriate, but it does not add much beyond the schema. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('Agent Intents') and the core purpose: announcing workspace work so peers see collisions. It names all six actions and their roles, making the tool's function unmistakable. However, it does not explicitly contrast with any sibling tool, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a precise lifecycle: allocate when work starts, fill once content is known, browse live intents, expand for detail, release when done. It also provides an explicit exclusion ('there is no renewal verb') and directs users to action='describe' for the full reference. This is strong, actionable guidance for when to use each action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Workspace/share invitations: list, filter by state, update, revoke. Call action='describe' for the full action/param reference. Destructive: delete.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Invitation state filter. | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| expires | No | Updated expiration — `YYYY-MM-DD HH:MM:SS UTC`. ISO 8601 is NOT documented as accepted. | |
| entity_id | No | Workspace or share ID (19-digit numeric or custom name). Must match entity_type. | |
| new_state | No | New invitation state. | |
| entity_type | No | Workspace or share. | |
| permissions | No | Updated permission level. | |
| invitation_id | No | Invitation opaque ID or invitee email. | |
| notifications | No | Notification preference (workspace). | |
| notify_options | No | Notification preference (share). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior (destructiveHint=true), and the description reinforces this with 'Destructive: delete.' It adds context about update/revoke operations but does not detail side effects, permissions, or response behavior. The safety profile is mostly covered by annotations, with the description adding minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences that front-load the primary purpose, provide a clear directive for obtaining full details, and flag destructive actions. Every sentence serves a distinct and necessary role, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, multiple actions) and absence of an output schema, the description provides a high-level overview and directs to action='describe' for complete details. It does not explicitly list all actions or parameter groups, but the describe reference compensates, making the description sufficiently complete for initial orientation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 10 parameters are already described in the schema. The description adds no additional parameter semantics beyond referencing action='describe' for full details. This matches the baseline for high schema coverage; no extra credit needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages 'Workspace/share invitations' with actions like list, filter, update, revoke, which distinguishes it from sibling tools like share or member. It could be more exhaustive by listing all actions (e.g., delete, describe), but the pointer to action='describe' compensates, making the purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when managing workspace/share invitations, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. The advice to call action='describe' for the full reference is helpful though limited. No direct comparison to sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Workspace/share member management: list, add, remove, update, transfer ownership, join, leave. Call action='describe' for the full action/param reference. Destructive: remove.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Share permission level. | |
| limit | No | Maximum number of items to return (1-500, default 100) | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| offset | No | Number of items to skip (default 0) | |
| expires | No | Membership expiration — `YYYY-MM-DD HH:MM:SS UTC` for BOTH workspace and share. ISO 8601 is NOT accepted (406). | |
| message | No | Invitation email message (10-255 chars). | |
| user_id | No | User profile ID (share). | |
| entity_id | No | Workspace or share ID (19-digit numeric or custom name). Must match entity_type. | |
| member_id | No | Member ID (workspace). | |
| expiration | No | Alias for expires (share only). | |
| entity_type | No | Workspace or share. | |
| permissions | No | Workspace permission level. | |
| display_limit | No | How many members to return for the list action. Default 10, max 500. The MCP trims post-fetch; backend paging stays MCP-internal so the platform cache stays warm. | |
| notifications | No | Notification preference (workspace string). | |
| invitation_key | No | Invitation key string. | |
| notify_options | No | Notification preference (share). | |
| email_or_user_id | No | Email (to invite) or user ID (to add directly). | |
| invitation_action | No | Accept or decline. | |
| force_notification | No | Force notify existing user (workspace-only). | |
| invitation_expires | No | Invitation expiration ISO 8601 (workspace-only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true. The description goes beyond this by identifying 'remove' as the destructive action and by disclosing the self-describing action='describe' behavior. This adds specific context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences: purpose with operations, the 'describe' instruction, and a destructive warning. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 actions, 20 parameters, no output schema), the description provides a concise overview and leverages the built-in 'describe' action for full detail. It doesn't outline return values, but that's acceptable without an output schema. It is sufficient for orientation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all 20 parameters have descriptions. The description text itself adds no parameter-level detail beyond pointing to action='describe' for more information, so it meets the baseline for fully-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies 'Workspace/share member management' and enumerates the operations: list, add, remove, update, transfer ownership, join, leave. This distinguishes it from sibling tools like share (managing shares) and workspace (workspace settings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (member management for workspace/share) and instructs to call action='describe' for the full action/param reference. It does not explicitly contrast with sibling tools or state exclusions, but the resource scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Workspace metadata: the field VOCABULARY (fields-list), lexical value search (search), metadata+content matching (compound-search), extraction eligibility (eligible), and folding near-duplicate field names together (fields-merge, DESTRUCTIVE). RETIRED: metadata TEMPLATES and SAVED VIEWS are gone — the platform removed those endpoints, so template-, nodes-, auto-match, preview-match, suggest-fields, extract-all and view-*/views-list no longer exist here. Per-file extraction lives on the storage tool (metadata-extract for one file, metadata-extract-all for a folder subtree).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | search keyword(s). 1-1024 chars. Multi-token = ALL tokens (AND); case-insensitive; substring for <=64 chars, else whole-word. | |
| limit | No | search: page size (1-100, default 100). | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| cursor | No | eligible/fields-list: opaque pagination cursor from a prior page's response — echo it back verbatim rather than constructing one. Omit for the first page. | |
| offset | No | search: results to skip (default 0). offset+limit must stay <= 10000. | |
| confirm | No | fields-merge: must be 'true' to proceed. The merge is IRREVERSIBLE and workspace-wide; the gate exists because the platform's guards check DATA safety, not whether the two fields mean the same thing. | |
| page_size | No | eligible/fields-list: cursor page size (1-250, default 100). Server caps at 250. | |
| template_id | No | RETIRED — metadata templates were removed, so there is no template to scope to. This tool REFUSES it on EVERY action: supplying it FAILS the request rather than narrowing it (the platform hard-refuses it too, and OPTIONS deliberately does not advertise it). Narrow by FIELD NAME instead — list valid names with `metadata action=fields-list`. | |
| source_field | No | fields-merge: the field NAME that is FOLDED AWAY and stops existing. Names, not ids. | |
| target_field | No | fields-merge: the field NAME that SURVIVES and absorbs the source's values. | |
| workspace_id | No | Workspace opaque ID (19-digit numeric ID or custom name). Required for every action. | |
| content_query | No | compound-search: free-text query run against INDEXED FILE CONTENT (1-1024 chars). Required for compound-search and AND-ed with metadata_filters — a file matches only if it satisfies BOTH. A file with no indexed content can never match, however well its metadata fits. | |
| display_limit | No | search: how many items to return post-fetch. Default 10, max 100 (the backend fetches at most 100 per page — a higher value has no effect; use offset to page past 100). | |
| describe_action | No | When action='describe', narrow the output to ONE action's full params/notes (e.g. 'fields-list'). Omit to get the compact action index. | |
| metadata_filters | No | compound-search: JSON predicate array `[{"field","operator","value"}]` (sent to the platform as `filters`). Required for compound-search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description flags fields-merge as DESTRUCTIVE and clarifies what that means: it folds near-duplicate field names together, which is a meaningful mutation warning beyond the generic destructiveHint annotation. It also discloses platform removals (RETIRED TEMPLATES and SAVED VIEWS) and redirects extraction to storage, setting accurate expectations. No contradiction with the annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description fits a broad multi-action tool into three compact sentences, with the action index front-loaded, retired functionality next, and storage routing last. Parentheticals keep the action list scannable, and the all-caps DESTRUCTIVE and RETIRED flags highlight the non-obvious parts. There is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter tool with no output schema, the overview plus the highly descriptive schema gives an agent strong grounding: it identifies all live actions, warns about retired ones, and routes adjacent work to storage. It does not state return shapes or per-action eligibility semantics directly, but the `describe` action exists and the schema is thorough, so the agent can proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all 15 parameters in detail, including nuanced ones like template_id hard-refusal and content_query AND semantics. The top-level description adds useful conceptual labels (field vocabulary, lexical value search, compound matching) but does not go deeper on individual parameters than the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description anchors to a concrete resource ('Workspace metadata') and enumerates each operation with its action name and a short gloss, e.g. 'lexical value search (search)' and 'folding near-duplicate field names together (fields-merge, DESTRUCTIVE).' It also explicitly distinguishes what the tool is not: templates/views are retired and per-file extraction lives on storage. This makes it easy to identify among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly redirects per-file extraction to the `storage` tool (metadata-extract and metadata-extract-all), addressing the most likely tool-selection confusion. It also warns that retired template/view actions no longer exist here, preventing wasted calls. It does not give a full decision tree among the six metadata actions, but the schema and `describe` action fill that gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Organization management: CRUD, billing, members, invitations, ownership transfer, assets, discovery. Call action='describe' for the full action/param reference. Destructive: close (permanently deletes org and all data).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name (3-100 chars). | |
| role | No | Org permission level — `member` or `admin` ONLY. `owner` is not assignable (it is returned when READING members, alongside admin/member). `guest` and `view` are WORKSPACE/SHARE roles and are rejected here (1605). | |
| No | Email address of user to invite. | ||
| limit | No | Page size. | |
| meter | No | Meter type, e.g. storage_bytes, transfer_bytes, ai_tokens. | |
| state | No | Invitation state, e.g. pending, accepted. | |
| token | No | Transfer token for ownership claim. | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| detail | No | Per-entity verbosity for list/discover-*/members/list-workspaces/details. Defaults: terse for list/discover-*/members/list-workspaces, full for details. See action='describe' for per-level field lists. | |
| domain | No | URL-safe subdomain (2-80 chars, lowercase alphanumeric + hyphens, globally unique, not reserved). | |
| offset | No | Pagination offset (0-based). | |
| org_id | No | Organization 19-digit ID or domain string. | |
| confirm | No | Confirmation string, must match org domain or ID. | |
| content | No | Plain text content. asset-upload: e.g. SVG body. | |
| expires | No | Updated expiration datetime. | |
| message | No | Custom invitation email message (10-255 chars). | |
| user_id | No | User ID. | |
| end_time | No | End datetime (default now). | |
| industry | No | Industry type, e.g. technology, healthcare, financial. | |
| metadata | No | Additional metadata as JSON array string. | |
| share_id | No | Filter by share ID. | |
| token_id | No | Transfer token ID. | |
| file_name | No | Original file name, e.g. logo.png. | |
| member_id | No | User ID or email of member. | |
| perm_join | No | Permission level required to join workspace. | |
| asset_name | No | Asset name, e.g. "logo", "banner". | |
| start_time | No | Start datetime (default 30 days ago). | |
| description | No | Description (10-1000 chars). | |
| domain_name | No | Domain to check for availability. | |
| file_base64 | No | Base64 file content for binary assets. | |
| folder_name | No | URL-safe workspace folder name (4-80 chars). | |
| join_action | No | Invitation action: accept or decline (default accept). Appended to the join URL path — restricted to these two values to prevent path injection. | |
| permissions | No | Updated permission level. | |
| twitter_url | No | Twitter/X profile URL. | |
| youtube_url | No | YouTube channel URL. | |
| accent_color | No | Brand accent color as JSON. | |
| billing_plan | No | Paid plan ID for billing-create, e.g. 'solo_monthly', 'business_v2_monthly', 'growth_monthly' (each has an annual variant). New orgs require a paid plan — free/agent plans are legacy and closed to new subscriptions; legacy 'pro_monthly'/'business_monthly' are also closed. Call billing-plans for the currently-offered plan IDs. | |
| content_type | No | MIME type, e.g. image/png. Defaults to application/octet-stream. | |
| facebook_url | No | Facebook page URL. | |
| homepage_url | No | Organization website URL. | |
| intelligence | No | Enable RAG indexing. COSTS 10 credits/page. Defaults "false". See describe. | |
| workspace_id | No | Workspace opaque ID. Use this when only workspaces are valid (not shares or other contexts). For polymorphic contexts use profile_id. Filter by workspace ID. | |
| billing_email | No | Billing contact email. | |
| display_limit | No | Number of orgs to return to the agent (default 10, max 100). Backend page_size unchanged for cache warmth — applies to list. Trims post-fetch only. | |
| instagram_url | No | Instagram profile URL. | |
| invitation_id | No | Invitation ID or invitee email. | |
| owner_defined | No | Custom owner-defined properties as JSON. | |
| invitation_key | No | Invitation key from invite link. | |
| starting_after | No | billing-invoices cursor: pass a prior invoice's `id` to fetch the next page (cursor pagination, not offset). | |
| use_background | No | Enable/disable background, "true"/"false". | |
| background_mode | No | Background display mode, e.g. 'stretched', 'fixed'. | |
| describe_action | No | When action='describe', narrow the output to ONE action's full params/notes (e.g. 'list'). Omit to get the compact action index. | |
| background_color | No | Background color as JSON. | |
| background_color1 | No | Primary background color as JSON. | |
| background_color2 | No | Secondary background color as JSON. | |
| perm_member_manage | No | Who can manage members, e.g. 'Owner only'. | |
| perm_authorized_domains | No | Authorized email domain for auto-join. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, and the description adds a specific, high-impact behavioral warning: 'close (permanently deletes org and all data).' This is valuable context beyond the generic annotation. However, it does not elaborate on other potentially destructive actions like asset-delete or transfer-ownership, so it's not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and scope, ending with a critical destructive warning and a self-help pointer. Every sentence earns its place with zero fluff. It is appropriately sized for a high-level overview that delegates detail to the describe action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 57 parameters, 40+ actions, and no output schema, this description is skeletal. It gives a high-level capability list and points to describe for the full reference, which is a useful workaround, but it does not cover return values, authentication, or action-specific side effects. The description relies heavily on the agent calling describe before use, which is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the 57 parameters already having detailed descriptions. The tool description text itself adds no parameter-level semantics, so the baseline of 3 applies. It correctly points to action='describe' for deeper parameter details, but that is meta-guidance, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages organizations, listing major capabilities (CRUD, billing, members, invitations, ownership transfer, assets, discovery). This is specific and avoids tautology, but it does not differentiate org from sibling tools like member, invitation, or workspace, which appear to be sub-features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing the tool's broad scope, but gives no explicit guidance on when to use org versus sibling tools. The only hint is 'Call action='describe' for the full action/param reference,' which is a navigation aid rather than a decision rule. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Files & folders on workspaces/shares: list, search, copy, move, delete, rename, trash, transfer, versions, locks, previews, and per-node metadata (get/set/delete/extract/versions). FILES OFTEN ALREADY CARRY AI-EXTRACTED METADATA, AND IT IS SEARCHABLE — check or search metadata before reading files: it frequently answers the question without opening anything, and finds files by value without listing folders. Call action='describe' for the full action/param reference. Destructive: purge (irreversible). delete moves to trash. metadata-delete removes metadata keys. Verbosity (detail param): list/recent/trash-list default to terse (compact rows); search defaults to standard (rows keep their facts values); details defaults to full (drill-down). Pass an explicit detail to override.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | list/search: alias for `query`. content: the relevance query (1-512 chars) — BM25 over THAT ONE FILE's chunks, never across the workspace, so it cannot find another file; returns every one of the top `limit` hits (default 3, max 20) with FULL text, is not byte-budgeted, and cannot be combined with `cursor`, `max_bytes`, or a page/chunk window. | |
| keys | No | metadata-delete: JSON array of metadata keys to delete (omit to clear all). | |
| name | No | Name for new folder or file. | |
| page | No | content: read one page (1-based). A window selector. | |
| size | No | Size preset: "IconSmall", "IconMedium", "Preview", or custom. | |
| type | No | Filter by node type. | |
| limit | No | Max results — 1-500, default 100 on list/search. content NARROWS it to 1-20, default 5 (3 with q); a value outside 1-20 is refused before any platform call. | |
| query | No | Search query — keyword, or keyword + semantic when intelligence is on. | |
| width | No | Target width in pixels. | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| cursor | No | Opaque cursor from a previous response. | |
| detail | No | Per-node verbosity for list/recent/search/trash-list/details. Defaults: terse for list/recent/trash-list, STANDARD for search (terse drops fact values), full for details. Bump to full when you need ai.attach (files_attach preflight), virus, hashes, file_attributes, lock_info, or long-form summaries. See action='describe' for per-level field lists. Not to be confused with `details` (search-only). | |
| height | No | Target height in pixels. | |
| offset | No | Results to skip (default 0). | |
| output | No | content-only response tier (default full). terse OMITS each chunk's `text` — every other field still comes back, so it is the cheap way to map a file's chunks before reading any. Not `detail`, the per-node tier on list/recent/search/details. EXACTLY ONE tier: markdown composition is NOT supported here, so `full,markdown` is rejected before the request is built. | |
| details | No | Search-only. Return fully-hydrated node objects per result (default limit drops to 10). Distinct from `detail` — call action='describe' for the contrast. | |
| node_id | No | Storage tree node opaque ID. Both files and folders are nodes — use this name regardless of which. Storage node opaque ID, or 'root'. On `list`, the target folder may also be given as parent_node_id or parent_id (aliases), and defaults to 'root' (the storage top level) when all three are omitted. | |
| sort_by | No | Sort column (default: name). | |
| chunk_to | No | content: last chunk `position` of a chunk range (0-based, >= chunk_from, and under 10000). Requires chunk_from. | |
| duration | No | lock-acquire only — how long the lock should hold, in seconds (60-3600). Omit for the platform default, which is SHORT: measured at 300s (5 minutes) on dev1. | |
| max_size | No | Max read-content bytes (default 512000, max 1048576). | |
| new_name | No | New name for file or folder. | |
| node_ids | No | Storage node opaque IDs (details: 1-25 max). | |
| share_id | No | For add-link: the target share to link (workspace-only). For the dual-type actions (list/details/copy/move/etc.): a profile alias implying profile_type=share — the share you are operating in (so profile_type may be omitted). | |
| sort_dir | No | Sort direction (default: asc). | |
| max_bytes | No | content, ORDERED reads only: UTF-8 byte budget for the returned passages (1024-262144, default 32768). Text is never cut inside a chunk — the page stops BEFORE the chunk that would exceed the budget. Refused alongside q: a relevance read is unbudgeted. | |
| node_type | No | rename-only OPTIONAL hint: the node's type, when the caller already knows it. Notes route to a dedicated endpoint, so supplying node_type lets rename skip the /details/ type-probe round-trip. Omit to have rename probe automatically. Distinct from the list/recent `type` filter. | |
| parent_id | No | Alias for node_id on `list` (the folder whose contents to list), or 'root'. `list` defaults to 'root' when omitted. | |
| search_in | No | filename | content | both (DEFAULT). filename = name only, find-style. content = the AI's summary + semantic, NOT grep. OMIT unless you mean it — sending it changes the response shape (adds a search_metadata block); omitting reproduces today's behavior byte-for-byte. Pair filename with name_match. | |
| upload_id | No | Opaque ID of completed upload session. | |
| chunk_from | No | content: start of an inclusive chunk `position` range (0-based, a chunk's ordinal in read order, under 10000). LEGAL ALONE — it reads on from that position; chunk_from=N chunk_to=N reads one chunk in full. | |
| context_id | No | Alias for profile_id (either name works) | |
| key_values | No | metadata-set: JSON object of field-name -> value, max 100 entries, matching the workspace field VOCABULARY (list names with `metadata action=fields-list`) — NOT template fields; templates were removed. ADDITIVE: send ONLY the fields you are changing, and note it CANNOT clear a field (use metadata-delete with an explicit `keys` list). | |
| lock_token | No | lock-release only — the token returned by lock-acquire. REQUIRED to release a lock. | |
| name_match | No | auto (DEFAULT) | exact | prefix | contains | glob. exact = whole name; prefix = starts with; contains = substring — those three are LITERAL (* and ? are ordinary chars). glob = wildcards over the WHOLE name: *.pdf, report-*.xlsx. Do NOT pre-escape. Applies when search_in is filename or both; auto keeps today's relevance. Precise modes cap the pattern at 256 chars, reject an empty one. | |
| profile_id | No | Polymorphic context ID (pair with profile_type=workspace|share). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share, on dual-type actions); also context_id / instance_id. 19-digit workspace or share ID, or custom name. | |
| version_id | No | Version ID to restore. | |
| as_markdown | No | Opt-in (list/recent/search/details/trash-list): when true, the platform renders the response as GitHub-flavored Markdown (?output=<detail>,markdown) for compact, human/agent-readable output instead of JSON. Omit (default) for the unchanged JSON shape with web_url enrichment + _next hints. Markdown is a passthrough — no client-side reshaping. | |
| files_scope | No | Scope semantic search to file versions. See describe for full constraints. | |
| instance_id | No | Alias for profile_id (REST/how-to name; profile_id is canonical). | |
| template_id | No | RETIRED — metadata templates were removed, so there is no template to scope to. Supplying it FAILS the request: the platform hard-refuses it on metadata-extract, metadata-set and the search routes alike, and OPTIONS does not advertise it. Node metadata is written as facts against the workspace field vocabulary — use key_values to write, and extract_fields to scope an extraction. | |
| context_type | No | Alias for profile_type (either name works) | |
| preview_type | No | Type of preview to generate. See describe for which preview_types apply to which file categories. | |
| profile_type | No | Profile type: "workspace" or "share". | |
| workspace_id | No | Alias for profile_id when the profile is a workspace — implies profile_type=workspace (so profile_type may be omitted). Valid on every storage action. | |
| display_limit | No | How many items to return. Default 10, max 500. The MCP trims post-fetch; backend cache stays warm. Used by: list, recent, search. list/recent paginate via the `cursor` param; search paginates via `offset` (increase offset by the page size) for additional pages. | |
| folders_scope | No | Scope semantic search to folders via BFS. See describe for full constraints. | |
| output_format | No | Output format: "png", "jpg", "webp". | |
| transfer_mode | No | 'copy' (default) or 'move'. 'move' invalid for node_id 'root'. | |
| case_sensitive | No | Case-sensitive matching for exact/prefix/contains/glob. Default false (like find -iname), which folds non-ASCII too. Ignored under name_match=auto. | |
| dest_parent_id | No | Destination parent folder opaque ID, or 'root'. Primary param for transfer (the parent in the OTHER instance). For copy/move within the same instance use target_parent_id — dest_parent_id is also accepted there as an alias. | |
| extract_fields | No | metadata-extract: JSON array of field names (e.g. `["vendor","amount"]`); omit for a full-row extract. WITH a template bound it narrows extraction to those fields. WITHOUT one it is NOT a filter: the request may be REFUSED, and where accepted the names act only as a re-run key — the file is still read in full, other fields are still written, and named fields are not guaranteed to return. | |
| parent_node_id | No | Parent folder opaque ID, or 'root'. (On `list`, also accepted as an alias for node_id — the folder to list; `list` defaults to 'root' when omitted.) | |
| transform_name | No | Transform name, e.g. "image" for resize/crop/format. | |
| describe_action | No | When action='describe', narrow the output to ONE action's full params/notes (e.g. 'list'). Omit to get the compact action index. | |
| dest_instance_id | No | Destination workspace or share profile ID. | |
| metadata_filters | No | search: JSON array of metadata predicates, e.g. '[{"field":"category","operator":"=","value":"Legal"}]'. Narrows to files whose metadata satisfies EVERY predicate BEFORE the query ranks — see describe. | |
| target_parent_id | No | Destination folder opaque ID, or 'root'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already flagging destructiveHint=true and readOnlyHint=false, the description goes well beyond them by specifying which operations are destructive and what they actually do: "purge (irreversible). delete moves to trash. metadata-delete removes metadata keys." It also discloses the searchable metadata behavior and the verbosity default tiers per action. This is exactly the kind of beyond-annotation context the dimension rewards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the tool's scope, then gives high-value usage hints, destructive warnings, and verbosity defaults in a compact block. Despite covering a 31-action tool, every sentence carries distinct, decision-relevant information and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 58-parameter, 31-action tool with no output schema, the description provides an efficient high-level orientation, flags safety-critical destructive behavior, and points to action='describe' for the full action/parameter reference. The richly documented schema covers the remaining invocation details, so the combination is sufficient for correct selection and safe initial use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a small amount of parameter context by explaining the `detail` parameter defaults and the action='describe' reference for full parameter docs, but it does not meaningfully enrich parameter semantics beyond the already very detailed per-parameter schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise resource and verb set: "Files & folders on workspaces/shares: list, search, copy, move, delete, rename, trash, transfer, versions, locks, previews, and per-node metadata". This is specific and clearly distinguishes the tool's scope from a mere tautology. However, it does not explicitly position itself against overlapping sibling tools like find, metadata, share, or upload/download, so it misses the top criterion of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear, actionable workflow guidance: "check or search metadata before reading files" and explicitly warns about destructive actions (purge vs delete vs metadata-delete). It also explains verbosity defaults and how to override them. Still, it names no sibling tools or when-not-to-use conditions, so it falls short of the explicit exclusions/alternatives required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File upload: stream-upload (one-shot — auto-finalizes, no filesize needed), chunked (create-session → chunk → finalize, for files over the 100 MB blob cap), web URL import, and batch (many small files). Call action='describe' for the full action/param reference. Side effects: finalize/stream/stream-upload/web-import/batch create files and consume storage credits. Same-name uploads to a folder OVERWRITE the existing node in place (preserved as a recoverable version). BYTES → SERVER: the DEFAULT for every file/binary is the POST /blob sidecar — a plain HTTP POST outside the MCP pipe (the create-session/blob-info response hands you a ready-to-run curl command) carrying RAW BYTES — no base64 inflation, no MCP size limit, up to 100 MB. stream-upload forwards them to the platform as a raw octet stream; chunk and batch send them as multipart. Either way the bytes never pass through base64. It returns a blob_id you pass to stream-upload/chunk/batch. ⚠️ content_base64 is a LAST RESORT, NOT a peer option — ~33% inflation plus a few-MB MCP transport cap means it FAILS for all but the smallest files. If you cannot reach POST /blob, that is almost always a CLIENT-SIDE FIREWALL/PROXY/EGRESS restriction: tell the user to allow the /blob endpoint rather than degrading to base64. content is for text you are composing ON THE FLY through the MCP (verbatim UTF-8) — not a file-upload fallback. UPLOAD STRATEGY (read top-to-bottom, pick the FIRST that matches): (1) Have a URL? → web-import (single call). (2) EVERYTHING ELSE up to 100 MB → POST /blob, then stream-upload with blob_id (single call, auto-finalizes, NO filesize required). Use this EVEN WHEN THE EXACT BYTE COUNT IS KNOWN — knowing the size does not make the chunked path better, it only makes it possible, and it costs 3+ round-trips plus the 10522 mismatch trap. If /blob seems unreachable, CHECK FIREWALL/SECURITY SETTINGS FIRST — falling back to content_base64 will fail for anything but a tiny file. (3) Over the 100 MB blob cap (must split across several blobs), or you need the session id between calls → create-session + chunk(blob_id) + finalize. filesize must match the bytes you actually upload — mismatch causes finalize to fail with code 10522 and you must cancel the session. (4) Multiple small files (≤4 MB each, ≤200 total) into one folder? → batch. Use blob_id (POST /blob) for every file/binary upload. If /blob is unreachable, raise the client-side firewall/proxy restriction with the user — content_base64 is a last resort that fails above a few MB, not a substitute. Do NOT guess filesize for generated content — use stream-upload. max_size is a hard ceiling that aborts mid-transfer — always overestimate or omit (server uses plan limit).
| Name | Required | Description | Default |
|---|---|---|---|
| org | No | Org ID for limit resolution. | |
| url | No | Source URL to import from. | |
| hash | No | File hash for verification. | |
| plan | No | Override billing plan to check (e.g. free, pro). | |
| wait | No | Long-poll wait in SECONDS, 1-590 (NOT milliseconds; 0/omitted returns immediately). The server holds the connection until the upload reaches a terminal status. Sending a millisecond value here would hold for minutes and blow past the tool-call timeout. | |
| files | No | Batch manifest (1..200 entries). Each: filename + one of blob_id/content/content_base64. | |
| limit | No | Max results (1-100, default 50). | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| offset | No | Pagination offset. | |
| status | No | Filter by status. | |
| stream | No | Stream mode — size optional, single POST, auto-finalizes. | |
| blob_id | No | Blob ID from POST /blob — the **default source** for all file & binary uploads (no base64, no MCP size limit, up to 100 MB). Single-use. | |
| content | No | **Text only** — stored verbatim UTF-8. This is for writing content you are composing **on the fly** directly through the MCP (a note, a generated report, a snippet you just produced) — NOT a fallback for uploading an existing file. Do NOT pass base64 here (use content_base64). One of content/content_base64/blob_id. | |
| creator | No | Client identifier echoed back (alphanumeric + hyphens). | |
| file_id | No | File ID for update context. | |
| blob_ref | No | Alias for blob_id (deprecated). Accepted on chunk/stream/stream-upload only. | |
| chunk_id | No | Specific chunk number (omit for all). | |
| filename | No | File name. Optional when target_node_id is set (auto-resolved); pass to rename-on-replace. | |
| filesize | No | Total file size in bytes. | |
| max_size | No | Stream-body byte ceiling — aborts mid-transfer if exceeded. Always overestimate; omit to use plan limit. Stream sessions only. | |
| password | No | File Share link password (profile_type=fileshare only). Forwarded ONLY as the x-ve-password header on every upload phase — never in a URL/log. Supply when the target share is password-protected. | |
| share_id | No | Alias for profile_id when the profile is a share — implies profile_type=share (so profile_type may be omitted). | |
| folder_id | No | Target folder OpaqueId or "root". Omit for instance root. | |
| hash_algo | No | Hash algorithm (e.g. 'sha256'). | |
| upload_id | No | Upload session ID or web upload job ID. | |
| chunk_size | No | Chunk size in bytes (server picks default). | |
| context_id | No | Alias for profile_id (either name works) | |
| profile_id | No | Polymorphic context ID (pair with profile_type=workspace|share|fileshare). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also context_id / instance_id. Target workspace/share ID, or the File Share id for a fileshare write-back. fileshare has NO typed alias — pass profile_type=fileshare explicitly. | |
| instance_id | No | Target workspace/share ID — also the profile_id alias for upload flows; profile_id is canonical. | |
| chunk_number | No | 1-indexed chunk number. | |
| context_type | No | Alias for profile_type (either name works). | |
| include_hash | No | Compute SHA-256 client-side for entries without a hash (default true when omitted). | |
| profile_type | No | Target type: workspace | share | fileshare (alias: context_type). Use `fileshare` ONLY for content write-back to a File Share's bound file (requires target_node_id = the bound node id from `fileshare details`; create-style new-file flows are rejected for fileshare). | |
| workspace_id | No | Alias for profile_id when the profile is a workspace — implies profile_type=workspace (so profile_type may be omitted). | |
| if_version_id | No | Compare-and-swap base for an overwrite. Enforced on EVERY update target — workspace, share and File Share. Pass the version id your edit was based on; record it on create-session/stream-upload (finalize does NOT read it). On a stale base the session ends assembly_failed with CONFLICT_VERSION_MISMATCH:<id> — rebase and retry. Omitting it is last-write-wins. See action=describe. | |
| action_context | No | Context: create or update. | |
| content_base64 | No | Base64-encoded **binary**, server-decoded. ⚠️ **LAST RESORT — expect FAILURE above a few MB** (~33% inflation + MCP transport cap). If POST /blob is unreachable that is almost always a CLIENT-SIDE FIREWALL/PROXY restriction, not a server limit — have the user allow /blob instead of falling back here. Use `blob_id` for any real file. | |
| parent_node_id | No | Parent folder OpaqueId or "root". On create-session, stream-upload, and web-import, folder_id is accepted as an alias (either name works). | |
| target_node_id | No | Overwrite this specific node (preserves node_id; new version). When set, parent_node_id is ignored and filename is optional (auto-resolved). Must be a file node. REQUIRED for profile_type=fileshare write-back — set it to the File Share's bound node id (from `fileshare details` → fileshare.file.id). | |
| describe_action | No | When action='describe', narrow the output to ONE action's full params/notes (e.g. 'chunk'). Omit to get the compact action index. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=true, but the description adds substantial behavioral context: overwriting same-name uploads in place while preserving a recoverable version, consuming storage credits on certain actions, the 10522 filesize mismatch failure, max_size aborting mid-transfer, wait being in seconds, and password being sent only as a header. This goes far beyond what annotations reveal and matches the destructiveHint of overwrites and credit consumption.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and contains notable redundancy: the content_base64-is-a-last-resort and firewall advice is repeated multiple times, and the 'no base64, no MCP size limit, up to 100 MB' claim appears more than once. Although the UPLOAD STRATEGY section is well-structured and front-loaded, the overall block is far from concise, and some sentences restate earlier warnings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 40 parameters, 20 actions, and no output schema, this description is remarkably complete: it covers the full decision tree, side effects, failure modes, error codes, CAS semantics, profile aliases, and the POST /blob sidecar flow. It also tells the agent to call action='describe' for the full per-action reference, covering remaining gaps in an actionable way.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema for key parameters: blob_id is the default single-use source for file uploads, content_base64 is a last resort likely to fail above a few MB, content is only for on-the-fly text, filesize must match uploaded bytes to avoid the 10522 trap, and max_size should be overestimated. Not every one of the 40 parameters gets extra treatment, but the critical ambiguous ones are clarified substantially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — "File upload" — and immediately enumerates the distinct modes: stream-upload, chunked, web URL import, and batch. This clearly differentiates the tool from siblings like download, storage, and fileshare, and gives an agent a precise mental model of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit, top-to-bottom UPLOAD STRATEGY with numbered decision rules: use web-import when a URL is available, prefer POST /blob + stream-upload for everything up to 100 MB, switch to chunked only over the cap or when a session id is needed, and use batch for many small files. It also explicitly warns when NOT to use content_base64 and tells the agent to check firewall settings instead, giving clear guidance versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
User profile, contacts, invitations, and assets. Call action='describe' for the full action/param reference. Destructive: close.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-500, default 100) | |
| query | No | Contact search substring. | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| offset | No | Number of items to skip (default 0) | |
| content | No | Plain text content for asset upload. | |
| user_id | No | 19-digit user ID or email. | |
| archived | No | True for archived shares, false for active. | |
| filename | No | Original filename. | |
| last_name | No | Family name. | |
| asset_name | No | Asset type name (e.g. profile_pic). | |
| first_name | No | Given name. | |
| confirmation | No | Email or user ID confirmation for account close. | |
| content_type | No | MIME type. | |
| display_limit | No | How 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-shares. | |
| email_address | No | Email address. | |
| invitation_id | No | Invitation opaque ID or key. | |
| content_base64 | No | Base64-encoded binary content. | |
| invitation_key | No | Invitation key. | |
| describe_action | No | When action='describe', narrow the output to ONE action's full params/notes (e.g. 'me'). Omit to get the compact action index. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already note destructiveHint=true and readOnlyHint=false. The description adds the specific information that the 'close' action is destructive, naming the exact operation. It also points to 'describe' for more detail, which is useful transparency about how to learn behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences that convey the tool's scope, the key action to invoke for reference, and the destructive hint. Every clause earns its place, with no redundancy or filler. The 'Destructive: close' note is specific and valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex multi-action tool with 19 parameters, no output schema, and broad capabilities. The description provides a high-level overview and defers to describe, which partially mitigates the lack of action-specific details. However, it omits return-value expectations and tool-selection guidance relative to siblings, leaving gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 19 parameters have complete descriptions in the schema (100% coverage), so the description does not need to elaborate on them. It adds the hint to use describe for a full action/param reference, which is helpful but does not materially enhance parameter understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as covering user profile, contacts, invitations, and assets, which gives a clear resource scope. It lacks a specific verb for a single action but is appropriate for a multi-action hub. The instruction to call action='describe' helps the agent discover specifics, and the resource list differentiates it from sibling tools like 'invitation' and 'auth'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. The only directive is to call action='describe' for the full reference, which is a within-tool navigation aid, not a selection guideline. No exclusions or sibling comparisons are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name. Send "null" to clear on update. | |
| limit | No | Maximum number of items to return (1-500, default 100) | |
| action | Yes | Operation. Use 'describe' for full action reference. | |
| detail | No | Per-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. | |
| offset | No | Number of items to skip (default 0) | |
| org_id | No | Filter workspaces to this org. | |
| blob_id | No | Blob ID from POST /blob. Preferred for large note content (UTF-8 decoded). Single-use. | |
| confirm | No | Must match folder_name or numeric ID. | |
| content | No | Plain text/markdown. Notes: max 102400 bytes (100 KiB) — use blob_id for larger. | |
| node_id | No | Storage tree node opaque ID. Both files and folders are nodes — use this name regardless of which. | |
| archived | No | Filter by archive status (default "false"). | |
| blob_ref | No | Alias for blob_id (deprecated). | |
| share_id | No | 19-digit numeric ID or custom name of share to import. | |
| note_name | No | Note filename (must end with .md). | |
| parent_id | No | Parent folder opaque ID or 'root'. | |
| perm_join | No | Who can join the workspace. | |
| description | No | Description. Newlines allowed. Send "null"/"" to clear on update. | |
| folder_name | No | URL-safe workspace folder name (4-80 chars). | |
| accent_color | No | Brand accent color JSON. "null" to clear. | |
| check_org_id | No | Org ID for check-name — suggests org-prefixed alternative if name taken. | |
| intelligence | No | Toggle AI features. ⚠️ COSTS CREDITS (10/page) — only enable on explicit user request. Disable flushes embeddings; re-enable re-indexes. Rate-limited. | |
| workspace_id | No | Workspace 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_limit | No | How 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_check | No | Folder name to check availability. | |
| owner_defined | No | Custom properties JSON. "null"/"" to clear. | |
| describe_action | No | When action='describe', narrow the output to ONE action's full params/notes (e.g. 'list'). Omit to get the compact action index. | |
| background_color1 | No | Background color 1 JSON. "null" to clear. | |
| background_color2 | No | Background color 2 JSON. "null" to clear. | |
| perm_member_manage | No | Who can manage members. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
find1 field changedInput schema / properties / detail / descriptionPrevious value: -"WORKSPACE files rows only — the per-row tier for extracted fields (`facts`); a share carries none at any tier. Default standard: up to 8 fields WITH their values. full: up to 100. terse asks for a names-only list this tool cannot render, so a terse row carries NO `facts` at all. See action='describe'."New value: +"Files-bucket rows on workspaces AND shares: caps `content_snippet` (standard 600 bytes, terse 200, full untrimmed). On a WORKSPACE also the `facts` tier: standard (default) up to 8 fields WITH values, full up to 100, terse names-only so a terse row carries NO `facts`. Shares carry no facts at any tier. See action='describe'."storage1 field changedInput schema / properties / detail / descriptionPrevious value: -"Per-node verbosity for list/recent/search/trash-list/details. Defaults: terse for list/recent/search/trash-list, full for details. Bump to full when you need ai.attach (files_attach preflight), virus, hashes, file_attributes, lock_info, or long-form summaries. See action='describe' for per-level field lists. Not to be confused with `details` (search-only)."New value: +"Per-node verbosity for list/recent/search/trash-list/details. Defaults: terse for list/recent/trash-list, STANDARD for search (terse drops fact values), full for details. Bump to full when you need ai.attach (files_attach preflight), virus, hashes, file_attributes, lock_info, or long-form summaries. See action='describe' for per-level field lists. Not to be confused with `details` (search-only)."find1 field changedInput schema / properties / detailAdded value: +{
+ "description": "WORKSPACE files rows only — the per-row tier for extracted fields (`facts`); a share carries none at any tier. Default standard: up to 8 fields WITH their values. full: up to 100. terse asks for a names-only list this tool cannot render, so a terse row carries NO `facts` at all. See action='describe'.",
+ "enum": [
+ "terse",
+ "standard",
+ "full"
+ ],
+ "type": "string"
+}storage8 fields changedInput schema / properties / action / enumPrevious value: -[
- "describe",
- "list",
- "recent",
- "details",
- "search",
- "trash-list",
- "create-folder",
- "copy",
- "move",
- "delete",
- "rename",
- "purge",
- "restore",
- "add-file",
- "add-link",
- "transfer",
- "version-list",
- "version-restore",
- "lock-acquire",
- "lock-status",
- "lock-release",
- "preview-url",
- "preview-transform",
- "read-content",
- "metadata-facts",
- "metadata-get",
- "metadata-set",
- "metadata-delete",
- "metadata-extract",
- "metadata-extract-all",
- "metadata-versions"
-]New value: +[
+ "describe",
+ "list",
+ "recent",
+ "details",
+ "search",
+ "trash-list",
+ "create-folder",
+ "copy",
+ "move",
+ "delete",
+ "rename",
+ "purge",
+ "restore",
+ "add-file",
+ "add-link",
+ "transfer",
+ "version-list",
+ "version-restore",
+ "lock-acquire",
+ "lock-status",
+ "lock-release",
+ "preview-url",
+ "preview-transform",
+ "read-content",
+ "content",
+ "metadata-facts",
+ "metadata-get",
+ "metadata-set",
+ "metadata-delete",
+ "metadata-extract",
+ "metadata-extract-all",
+ "metadata-versions"
+]Input schema / properties / chunk_fromAdded value: +{
+ "description": "content: start of an inclusive chunk `position` range (0-based, a chunk's ordinal in read order, under 10000). LEGAL ALONE — it reads on from that position; chunk_from=N chunk_to=N reads one chunk in full.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / chunk_toAdded value: +{
+ "description": "content: last chunk `position` of a chunk range (0-based, >= chunk_from, and under 10000). Requires chunk_from.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / limit / descriptionPrevious value: -"Max results (1-500, default 100)."New value: +"Max results — 1-500, default 100 on list/search. content NARROWS it to 1-20, default 5 (3 with q); a value outside 1-20 is refused before any platform call."Input schema / properties / max_bytesAdded value: +{
+ "description": "content, ORDERED reads only: UTF-8 byte budget for the returned passages (1024-262144, default 32768). Text is never cut inside a chunk — the page stops BEFORE the chunk that would exceed the budget. Refused alongside q: a relevance read is unbudgeted.",
+ "maximum": 262144,
+ "minimum": 1024,
+ "type": "integer"
+}Input schema / properties / outputAdded value: +{
+ "description": "content-only response tier (default full). terse OMITS each chunk's `text` — every other field still comes back, so it is the cheap way to map a file's chunks before reading any. Not `detail`, the per-node tier on list/recent/search/details. EXACTLY ONE tier: markdown composition is NOT supported here, so `full,markdown` is rejected before the request is built.",
+ "enum": [
+ "terse",
+ "standard",
+ "full"
+ ],
+ "type": "string"
+}Input schema / properties / pageAdded value: +{
+ "description": "content: read one page (1-based). A window selector.",
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / q / descriptionPrevious value: -"Alias for query."New value: +"list/search: alias for `query`. content: the relevance query (1-512 chars) — BM25 over THAT ONE FILE's chunks, never across the workspace, so it cannot find another file; returns every one of the top `limit` hits (default 3, max 20) with FULL text, is not byte-budgeted, and cannot be combined with `cursor`, `max_bytes`, or a page/chunk window."workspace8 fields changedInput schema / properties / action / enumPrevious value: -[
- "describe",
- "list",
- "details",
- "update",
- "delete",
- "archive",
- "unarchive",
- "members",
- "list-shares",
- "import-share",
- "available",
- "check-name",
- "create-note",
- "update-note",
- "read-note",
- "quickshare-get",
- "quickshare-delete",
- "quickshares-list",
- "metadata-get",
- "metadata-set",
- "metadata-delete",
- "metadata-extract",
- "jobs-status",
- "metadata-versions",
- "metadata-search",
- "enable-import",
- "disable-import"
-]New value: +[
+ "describe",
+ "list",
+ "details",
+ "update",
+ "delete",
+ "archive",
+ "unarchive",
+ "members",
+ "list-shares",
+ "import-share",
+ "available",
+ "check-name",
+ "create-note",
+ "update-note",
+ "read-note",
+ "quickshare-get",
+ "quickshare-delete",
+ "quickshares-list",
+ "jobs-status",
+ "enable-import",
+ "disable-import"
+]Input schema / properties / display_limit / descriptionPrevious value: -"How 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, metadata-search."New value: +"How 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."Input schema / properties / extract_fieldsRemoved value: -{
- "description": "JSON array of field names (e.g. `[\"vendor\",\"amount\"]`); omit for a full-row extract. WITH a template bound it narrows extraction to those fields. WITHOUT one it is NOT a filter: the request may be REFUSED, and where accepted the names act only as a re-run key — the file is still read in full, other fields are still written, and named fields are not guaranteed to return.",
- "type": "string"
-}Input schema / properties / key_valuesRemoved value: -{
- "description": "JSON object of field-name -> value, max 100 entries, matching the workspace field VOCABULARY (list names with `metadata action=fields-list`) — NOT template fields; templates were removed. ADDITIVE: send ONLY the fields you are changing; it CANNOT clear a field (use metadata-delete with an explicit `keys` list).",
- "type": "string"
-}Input schema / properties / keysRemoved value: -{
- "description": "JSON array of metadata keys to delete (omit for all).",
- "type": "string"
-}Input schema / properties / node_idsRemoved value: -{
- "description": "JSON array of node IDs (1-25, same workspace; deduped server-side). Bulk metadata-get returns {format:'multi', objects, templates, errors}.",
- "type": "string"
-}Input schema / properties / qRemoved value: -{
- "description": "Search keyword(s). 1-1024 chars. Multi-token = ALL tokens (AND); case-insensitive; substring for ≤64 chars, else whole-word.",
- "maxLength": 1024,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / template_idRemoved value: -{
- "description": "RETIRED — metadata templates were removed, so there is no template to scope to. Supplying it FAILS the request on EVERY action here, including `metadata-extract`: the platform hard-refuses it on the extract, set and search routes alike. Narrow by FIELD NAME instead — list valid names with `metadata action=fields-list`, and scope an extraction with `extract_fields`.",
- "type": "string"
-}auth1 field changedInput schema / properties / agent_name / descriptionPrevious value: -"Agent name for approval screen and audit logs."New value: +"Agent name for the approval screen and audit logs. If omitted on pkce-login this DEFAULTS to the MCP client's self-reported name (clientInfo.name from initialize), which is caller-supplied and NOT platform-verified — a human approves it on the consent screen, but it is not a vouched vendor. Pass it explicitly to control what is recorded."event2 fields changedInput schema / properties / category / descriptionPrevious value: -"Event category. See describe action for valid values."New value: +"Event category. See describe action for valid values. `node` IS THE AI/RAG PIPELINE, NOT FILE OPERATIONS — file activity lives under `workspace` AND `share`, so query both. CLOUD IMPORT IS NOT `cloudsync` HERE — that is an ACTIVITY field on a different taxonomy and returns nothing rather than erroring. Use category=\"import\", narrowed with subcategory=\"cloud_import\" for graft traffic only."Input schema / properties / user_id / descriptionPrevious value: -"Filter by user profile ID."New value: +"Filter by the event's stored subject column. DO NOT read it as \"the person this event is about\": the platform DERIVES that column instead of taking it from the emitter, so it can name an arbitrary related user rather than the subject. For \"what did this person do\", use calling_user_id (the actor) and read its note. See the search note before relying on either."intentmetadata25 fields changedInput schema / properties / action / enumPrevious value: -[
- "describe",
- "template-create",
- "template-list",
- "template-details",
- "template-update",
- "template-clone",
- "template-delete",
- "template-assign",
- "template-unassign",
- "template-resolve",
- "template-assignments",
- "preview-match",
- "suggest-fields",
- "eligible",
- "nodes-add",
- "nodes-remove",
- "nodes-list",
- "auto-match",
- "extract-all",
- "view-get",
- "view-save",
- "view-delete",
- "views-list",
- "view-export",
- "search"
-]New value: +[
+ "describe",
+ "eligible",
+ "fields-list",
+ "search",
+ "compound-search",
+ "fields-merge"
+]Input schema / properties / batch_sizeRemoved value: -{
- "description": "auto-match: optional batch-size override (clamped server-side). Omit for default.",
- "maximum": 9007199254740991,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / categoryRemoved value: -{
- "description": "Metadata template category (accepted but ignored server-side — no effect).",
- "enum": [
- "legal",
- "financial",
- "business",
- "medical",
- "technical",
- "engineering",
- "insurance",
- "educational",
- "multimedia",
- "hr"
- ],
- "type": "string"
-}Input schema / properties / configRemoved value: -{
- "description": "view-save config JSON: `{version:1, columns:[{field,visible?,width?}], sort:{field,dir}, filters:[{field,operator,value_type,value}]}`. Max 5 filters AND-chained; operator in `= != < <= > >=`; value_type in `string|int|float|bool`.",
- "type": "string"
-}Input schema / properties / confirmAdded value: +{
+ "description": "fields-merge: must be 'true' to proceed. The merge is IRREVERSIBLE and workspace-wide; the gate exists because the platform's guards check DATA safety, not whether the two fields mean the same thing.",
+ "enum": [
+ "true",
+ "false"
+ ],
+ "type": "string"
+}Input schema / properties / content_queryAdded value: +{
+ "description": "compound-search: free-text query run against INDEXED FILE CONTENT (1-1024 chars). Required for compound-search and AND-ed with metadata_filters — a file matches only if it satisfies BOTH. A file with no indexed content can never match, however well its metadata fits.",
+ "maxLength": 1024,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / cursor / descriptionPrevious value: -"eligible/nodes-list: opaque pagination cursor from a prior page's response. Omit for the first page."New value: +"eligible/fields-list: opaque pagination cursor from a prior page's response — echo it back verbatim rather than constructing one. Omit for the first page."Input schema / properties / describe_action / descriptionPrevious value: -"When action='describe', narrow the output to ONE action's full params/notes (e.g. 'template-list'). Omit to get the compact action index."New value: +"When action='describe', narrow the output to ONE action's full params/notes (e.g. 'fields-list'). Omit to get the compact action index."Input schema / properties / descriptionRemoved value: -{
- "description": "Template description. ≤255 chars, empty allowed (template-create/-update/-clone). preview-match: required, 1-2000. suggest-fields: optional, ≤2000.",
- "maxLength": 2000,
- "type": "string"
-}Input schema / properties / extract_fieldsRemoved value: -{
- "description": "extract-all: JSON array of field names to restrict the batch job to (e.g. `[\"vendor\",\"amount\"]`); omit for all fields.",
- "type": "string"
-}Input schema / properties / fieldsRemoved value: -{
- "description": "JSON array of field defs (template-create/-update/-clone). At least one field must have autoextract:true (default) or API returns 1605. Each: {name, description, type (string|int|float|bool|json|url|datetime), min?, max?, default?, fixed_list?, can_be_null?, autoextract?}.",
- "type": "string"
-}Input schema / properties / filtersRemoved value: -{
- "description": "template-list filter (default 'all'): all|enabled|disabled|custom|system. (Replaces the old workspace `template_filter` param.)",
- "enum": [
- "all",
- "enabled",
- "disabled",
- "custom",
- "system"
- ],
- "type": "string"
-}Input schema / properties / forceRemoved value: -{
- "description": "extract-all: when 'true', re-extract every mapped node even if it already has KV data (re-extract flow). Default 'false' skips nodes with values present.",
- "enum": [
- "true",
- "false"
- ],
- "type": "string"
-}Input schema / properties / metadata_filtersAdded value: +{
+ "description": "compound-search: JSON predicate array `[{\"field\",\"operator\",\"value\"}]` (sent to the platform as `filters`). Required for compound-search. ",
+ "type": "string"
+}Input schema / properties / nameRemoved value: -{
- "description": "Template name (1-255 chars: template-create/-update/-clone and preview-match), OR an optional saved-view label on view-save (≤30 chars; omit to keep the existing label).",
- "maxLength": 255,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / node_idRemoved value: -{
- "description": "Storage tree node opaque ID (used by template-resolve, and template-assign to scope an assignment).",
- "type": "string"
-}Input schema / properties / node_idsRemoved value: -{
- "description": "JSON array of node IDs. suggest-fields: 1-25 file nodes. nodes-add/-remove: nodes to map/unmap (files+notes; folders/links rejected) — deduped first-seen, max 50 unique per call (the server hard-rejects >50 per request; the per-template TOTAL node cap is separate and enforced server-side).",
- "type": "string"
-}Input schema / properties / page_size / descriptionPrevious value: -"eligible/nodes-list: cursor page size (1-250, default 100). Server caps at 250."New value: +"eligible/fields-list: cursor page size (1-250, default 100). Server caps at 250."Input schema / properties / parent_node_idRemoved value: -{
- "description": "view-export destination folder opaque ID (must be a folder, not trashed). Omit for workspace root.",
- "maxLength": 64,
- "type": "string"
-}Input schema / properties / sort_dirRemoved value: -{
- "description": "nodes-list: asc|desc (only with sort_field).",
- "enum": [
- "asc",
- "desc"
- ],
- "type": "string"
-}Input schema / properties / sort_fieldRemoved value: -{
- "description": "nodes-list: optional template field name to sort by.",
- "type": "string"
-}Input schema / properties / source_fieldAdded value: +{
+ "description": "fields-merge: the field NAME that is FOLDED AWAY and stops existing. Names, not ids.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / target_fieldAdded value: +{
+ "description": "fields-merge: the field NAME that SURVIVES and absorbs the source's values.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / template_id / descriptionPrevious value: -"Metadata template ID (e.g. mt_abc123). For search, restricts to nodes with values from this template (custom fields excluded)."New value: +"RETIRED — metadata templates were removed, so there is no template to scope to. This tool REFUSES it on EVERY action: supplying it FAILS the request rather than narrowing it (the platform hard-refuses it too, and OPTIONS deliberately does not advertise it). Narrow by FIELD NAME instead — list valid names with `metadata action=fields-list`."Input schema / properties / user_contextRemoved value: -{
- "description": "suggest-fields: short view/template hint (1-64 chars, letters/numbers/spaces). Example: \"photo collection\".",
- "maxLength": 64,
- "minLength": 1,
- "type": "string"
-}roomshare1 field changedInput schema / properties / room_goal / descriptionPrevious value: -"update only, Coordination Rooms only. Correct a room's purpose; share_id IS the room_id. 1-500 chars, no control chars; blank NOT accepted. ANY member of the parent workspace may do this — a room grants share-level Admin to workspace members. The only mutable manifest key; topic_slug is immutable. Non-room share: REFUSED 406. Most OTHER update params are refused on a room — see the action note."New value: +"REMOVED — Coordination Rooms were deleted from the platform on 2026-08-25 and this parameter no longer does anything. Supplying it is REFUSED rather than ignored, so a stale tool list cannot silently drop your value. Do not use it."storage9 fields changedInput schema / properties / action / enumPrevious value: -[
- "describe",
- "list",
- "recent",
- "details",
- "search",
- "trash-list",
- "create-folder",
- "copy",
- "move",
- "delete",
- "rename",
- "purge",
- "restore",
- "add-file",
- "add-link",
- "transfer",
- "version-list",
- "version-restore",
- "lock-acquire",
- "lock-status",
- "lock-release",
- "preview-url",
- "preview-transform",
- "read-content",
- "metadata-get",
- "metadata-set",
- "metadata-delete",
- "metadata-extract",
- "metadata-versions",
- "metadata-list-files",
- "metadata-list-templates-in-use"
-]New value: +[
+ "describe",
+ "list",
+ "recent",
+ "details",
+ "search",
+ "trash-list",
+ "create-folder",
+ "copy",
+ "move",
+ "delete",
+ "rename",
+ "purge",
+ "restore",
+ "add-file",
+ "add-link",
+ "transfer",
+ "version-list",
+ "version-restore",
+ "lock-acquire",
+ "lock-status",
+ "lock-release",
+ "preview-url",
+ "preview-transform",
+ "read-content",
+ "metadata-facts",
+ "metadata-get",
+ "metadata-set",
+ "metadata-delete",
+ "metadata-extract",
+ "metadata-extract-all",
+ "metadata-versions"
+]Input schema / properties / durationAdded value: +{
+ "description": "lock-acquire only — how long the lock should hold, in seconds (60-3600). Omit for the platform default, which is SHORT: measured at 300s (5 minutes) on dev1.",
+ "maximum": 3600,
+ "minimum": 60,
+ "type": "integer"
+}Input schema / properties / extract_fields / descriptionPrevious value: -"metadata-extract: JSON array of field names to extract (e.g. `[\"vendor\",\"amount\"]`); omit/null for full row."New value: +"metadata-extract: JSON array of field names (e.g. `[\"vendor\",\"amount\"]`); omit for a full-row extract. WITH a template bound it narrows extraction to those fields. WITHOUT one it is NOT a filter: the request may be REFUSED, and where accepted the names act only as a re-run key — the file is still read in full, other fields are still written, and named fields are not guaranteed to return."Input schema / properties / key_values / descriptionPrevious value: -"metadata-set: JSON object of key-value pairs matching template fields."New value: +"metadata-set: JSON object of field-name -> value, max 100 entries, matching the workspace field VOCABULARY (list names with `metadata action=fields-list`) — NOT template fields; templates were removed. ADDITIVE: send ONLY the fields you are changing, and note it CANNOT clear a field (use metadata-delete with an explicit `keys` list)."Input schema / properties / lock_token / descriptionPrevious value: -"lock-release/lock-heartbeat only — the token returned by lock-acquire. REQUIRED to release or refresh a lock."New value: +"lock-release only — the token returned by lock-acquire. REQUIRED to release a lock."Input schema / properties / metadata_filters / descriptionPrevious value: -"metadata-list-files: JSON filter criteria for the metadata file listing."New value: +"search: JSON array of metadata predicates, e.g. '[{\"field\":\"category\",\"operator\":\"=\",\"value\":\"Legal\"}]'. Narrows to files whose metadata satisfies EVERY predicate BEFORE the query ranks — see describe."Input schema / properties / order_byRemoved value: -{
- "description": "metadata-list-files: field key to sort by.",
- "type": "string"
-}Input schema / properties / order_descRemoved value: -{
- "description": "metadata-list-files: sort descending ('true' or 'false').",
- "type": "string"
-}Input schema / properties / template_id / descriptionPrevious value: -"Metadata template ID (e.g. mt_abc123). Required for metadata-set/metadata-list-files. The template SYSTEM (CRUD/assign/AI-extraction) lives on the `metadata` tool."New value: +"RETIRED — metadata templates were removed, so there is no template to scope to. Supplying it FAILS the request: the platform hard-refuses it on metadata-extract, metadata-set and the search routes alike, and OPTIONS does not advertise it. Node metadata is written as facts against the workspace field vocabulary — use key_values to write, and extract_fields to scope an extraction."upload4 fields changedInput schema / properties / content / descriptionPrevious value: -"**Text only** — stored verbatim UTF-8. Do NOT pass base64 here (use content_base64). One of content/content_base64/blob_id."New value: +"**Text only** — stored verbatim UTF-8. This is for writing content you are composing **on the fly** directly through the MCP (a note, a generated report, a snippet you just produced) — NOT a fallback for uploading an existing file. Do NOT pass base64 here (use content_base64). One of content/content_base64/blob_id."Input schema / properties / content_base64 / descriptionPrevious value: -"Base64-encoded **binary**, server-decoded (whitespace stripped). **Fallback only** — capped a few MB by the MCP transport. Prefer `blob_id` (POST /blob) for any file/binary; use this only when your client cannot make the POST /blob call."New value: +"Base64-encoded **binary**, server-decoded. ⚠️ **LAST RESORT — expect FAILURE above a few MB** (~33% inflation + MCP transport cap). If POST /blob is unreachable that is almost always a CLIENT-SIDE FIREWALL/PROXY restriction, not a server limit — have the user allow /blob instead of falling back here. Use `blob_id` for any real file."Input schema / properties / if_version_id / descriptionPrevious value: -"File Share write-back compare-and-swap (profile_type=fileshare only). Pass the version id your edit was based on (from fileshare details / versions-list). If the file advanced, NOTHING is written — the session ends assembly_failed with CONFLICT_VERSION_MISMATCH:<id>; rebase and retry. Omitting it is last-write-wins. See action=describe."New value: +"Compare-and-swap base for an overwrite. Enforced on EVERY update target — workspace, share and File Share. Pass the version id your edit was based on; record it on create-session/stream-upload (finalize does NOT read it). On a stale base the session ends assembly_failed with CONFLICT_VERSION_MISMATCH:<id> — rebase and retry. Omitting it is last-write-wins. See action=describe."Input schema / properties / if_version_id / minLengthAdded value: +1workspace15 fields changedInput schema / properties / action / enumPrevious value: -[
- "describe",
- "list",
- "details",
- "update",
- "delete",
- "archive",
- "unarchive",
- "members",
- "list-shares",
- "import-share",
- "available",
- "check-name",
- "create-note",
- "update-note",
- "read-note",
- "quickshare-get",
- "quickshare-delete",
- "quickshares-list",
- "metadata-template-create",
- "metadata-template-delete",
- "metadata-template-list",
- "metadata-template-details",
- "metadata-template-update",
- "metadata-template-clone",
- "metadata-template-preview-match",
- "metadata-template-suggest-fields",
- "metadata-template-assign",
- "metadata-template-unassign",
- "metadata-template-resolve",
- "metadata-template-assignments",
- "metadata-get",
- "metadata-set",
- "metadata-delete",
- "metadata-extract",
- "jobs-status",
- "metadata-list-files",
- "metadata-list-templates-in-use",
- "metadata-versions",
- "metadata-view-get",
- "metadata-view-save",
- "metadata-view-delete",
- "metadata-views-list",
- "metadata-view-export",
- "metadata-search",
- "enable-import",
- "disable-import"
-]New value: +[
+ "describe",
+ "list",
+ "details",
+ "update",
+ "delete",
+ "archive",
+ "unarchive",
+ "members",
+ "list-shares",
+ "import-share",
+ "available",
+ "check-name",
+ "create-note",
+ "update-note",
+ "read-note",
+ "quickshare-get",
+ "quickshare-delete",
+ "quickshares-list",
+ "metadata-get",
+ "metadata-set",
+ "metadata-delete",
+ "metadata-extract",
+ "jobs-status",
+ "metadata-versions",
+ "metadata-search",
+ "enable-import",
+ "disable-import"
+]Input schema / properties / categoryRemoved value: -{
- "description": "Metadata template category.",
- "enum": [
- "legal",
- "financial",
- "business",
- "medical",
- "technical",
- "engineering",
- "insurance",
- "educational",
- "multimedia",
- "hr"
- ],
- "type": "string"
-}Input schema / properties / configRemoved value: -{
- "description": "Saved-view config JSON: `{version:1, columns:[{field,visible?,width?}], sort:{field,dir}, filters:[{field,operator,value_type,value}]}`. Max 5 filters AND-chained; operator in `= != < <= > >=`; value_type in `string|int|float|bool`.",
- "type": "string"
-}Input schema / properties / description / descriptionPrevious value: -"Description. metadata-template-create: required, 0-1000 (empty allowed); metadata-template-update/-clone: 10-1000; preview-match/suggest-fields: 1-2000. Newlines allowed. Send \"null\"/\"\" to clear on update."New value: +"Description. Newlines allowed. Send \"null\"/\"\" to clear on update."Input schema / properties / extract_fields / descriptionPrevious value: -"JSON array of field names to extract (e.g. `[\"vendor\",\"amount\"]`); omit/null for full row."New value: +"JSON array of field names (e.g. `[\"vendor\",\"amount\"]`); omit for a full-row extract. WITH a template bound it narrows extraction to those fields. WITHOUT one it is NOT a filter: the request may be REFUSED, and where accepted the names act only as a re-run key — the file is still read in full, other fields are still written, and named fields are not guaranteed to return."Input schema / properties / fieldsRemoved value: -{
- "description": "JSON array of field defs. At least one field must have autoextract:true (default) or API returns 1605. Each: {name, description, type (string|int|float|bool|json|url|datetime), min?, max?, default?, fixed_list?, can_be_null?, autoextract?}.",
- "type": "string"
-}Input schema / properties / key_values / descriptionPrevious value: -"JSON object of key-value pairs matching template fields."New value: +"JSON object of field-name -> value, max 100 entries, matching the workspace field VOCABULARY (list names with `metadata action=fields-list`) — NOT template fields; templates were removed. ADDITIVE: send ONLY the fields you are changing; it CANNOT clear a field (use metadata-delete with an explicit `keys` list)."Input schema / properties / metadata_filtersRemoved value: -{
- "description": "JSON filter criteria for metadata file listing.",
- "type": "string"
-}Input schema / properties / name / descriptionPrevious value: -"Name. 1-255 (metadata-template-create, preview-match); 2-100 (metadata-template-update/-clone). Send \"null\" to clear on update."New value: +"Name. Send \"null\" to clear on update."Input schema / properties / order_byRemoved value: -{
- "description": "Field key to sort metadata file list by.",
- "type": "string"
-}Input schema / properties / order_descRemoved value: -{
- "description": "Sort descending: 'true' or 'false'.",
- "type": "string"
-}Input schema / properties / parent_node_idRemoved value: -{
- "description": "Destination folder opaque ID for TSV export (must be folder, not trashed). Omit for workspace root.",
- "maxLength": 64,
- "type": "string"
-}Input schema / properties / template_filterRemoved value: -{
- "description": "Filter for metadata template list.",
- "enum": [
- "enabled",
- "disabled",
- "custom",
- "system"
- ],
- "type": "string"
-}Input schema / properties / template_id / descriptionPrevious value: -"Metadata template ID (e.g. mt_abc123). For metadata-search, restricts to nodes with values from this template (custom fields excluded)."New value: +"RETIRED — metadata templates were removed, so there is no template to scope to. Supplying it FAILS the request on EVERY action here, including `metadata-extract`: the platform hard-refuses it on the extract, set and search routes alike. Narrow by FIELD NAME instead — list valid names with `metadata action=fields-list`, and scope an extraction with `extract_fields`."Input schema / properties / user_contextRemoved value: -{
- "description": "Short view/template hint (1-64 chars, letters/numbers/spaces). Example: \"photo collection\".",
- "maxLength": 64,
- "minLength": 1,
- "type": "string"
-}room4 fields changedInput schema / properties / body / descriptionPrevious value: -"1-8192 CHARACTERS, counted in code points — a CJK or emoji character costs exactly one, same as ASCII. (A byte ceiling underneath this used to refuse non-ASCII far sooner; it was raised out of reach on 2026-08-05.) post only. Do NOT put secrets here."New value: +"1-8192 CHARACTERS, counted in code points — a CJK or emoji character costs exactly one, same as ASCII. (A byte ceiling underneath this used to refuse non-ASCII far sooner; it was raised out of reach on 2026-08-05.) post only. Do NOT put secrets here. File refs: `@[file:<id>:<name>]` is valid here and counts toward the 8192 in FULL (no discount on this path); full grammar in action=describe."Input schema / properties / goal / descriptionPrevious value: -"create only. 1-500 chars, no control chars. ⚠️ SET ONCE — server-owned and IMMUTABLE. If the (workspace, topic_slug) room exists, create ADOPTS it (created:false) and the STORED goal wins — yours is discarded silently, no error. You cannot correct a goal by re-creating, so write one that survives: the durable purpose, not the current step. No secrets."New value: +"create only, OPTIONAL. 1-500 chars, no control chars — blank is REJECTED, so omit it rather than sending an empty string. On adopt (created:false) a goal that DIFFERS from the stored one is refused 409 (120719), not discarded: omit it to join, or fix it with share action=update room_goal. Correctable after creation. No secrets."Input schema / properties / status_summary / descriptionPrevious value: -"status only. Free-text summary of what you're doing (max 500 chars)."New value: +"status only. Free-text summary of what you're doing (max 8,192 CHARACTERS, code points — not the 500 that caps a message's display_text)."Input schema / properties / status_summary / maxLengthPrevious value: -1000New value: +16384share1 field changedInput schema / properties / room_goalAdded value: +{
+ "description": "update only, Coordination Rooms only. Correct a room's purpose; share_id IS the room_id. 1-500 chars, no control chars; blank NOT accepted. ANY member of the parent workspace may do this — a room grants share-level Admin to workspace members. The only mutable manifest key; topic_slug is immutable. Non-room share: REFUSED 406. Most OTHER update params are refused on a room — see the action note.",
+ "maxLength": 1000,
+ "minLength": 1,
+ "type": "string"
+}ai2 fields changedInput schema / properties / query_text / descriptionPrevious value: -"Question or prompt (max 12,768 chars)."New value: +"Question or prompt (max 32,000 chars)."Input schema / properties / query_text / maxLengthPrevious value: -12768New value: +32000comment13 fields changedInput schema / properties / reference / properties / region / descriptionPrevious value: -"Spatial region for image/video/PDF."New value: +"Spatial region for image/video/PDF — CORNERS on a 0-100 PERCENT scale: {x1,y1,x2,y2}, not {x,y,width,height} and not 0-1 normalized."Input schema / properties / reference / properties / region / properties / heightRemoved value: -{
- "description": "Height (0-1).",
- "maximum": 1,
- "minimum": 0,
- "type": "number"
-}Input schema / properties / reference / properties / region / properties / widthRemoved value: -{
- "description": "Width (0-1).",
- "maximum": 1,
- "minimum": 0,
- "type": "number"
-}Input schema / properties / reference / properties / region / properties / xRemoved value: -{
- "description": "X (0-1 normalized).",
- "maximum": 1,
- "minimum": 0,
- "type": "number"
-}Input schema / properties / reference / properties / region / properties / x1Added value: +{
+ "description": "Left edge, 0-100 PERCENT.",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / reference / properties / region / properties / x2Added value: +{
+ "description": "Right edge, 0-100 PERCENT (must be > x1).",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / reference / properties / region / properties / yRemoved value: -{
- "description": "Y (0-1 normalized).",
- "maximum": 1,
- "minimum": 0,
- "type": "number"
-}Input schema / properties / reference / properties / region / properties / y1Added value: +{
+ "description": "Top edge, 0-100 PERCENT.",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / reference / properties / region / properties / y2Added value: +{
+ "description": "Bottom edge, 0-100 PERCENT (must be > y1).",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / reference / properties / region / requiredPrevious value: -[
- "x",
- "y"
-]New value: +[
+ "x1",
+ "y1",
+ "x2",
+ "y2"
+]Input schema / properties / reference / properties / type / enumPrevious value: -[
- "image",
- "video",
- "audio",
- "pdf",
- "document",
- "text"
-]New value: +[
+ "image",
+ "video",
+ "audio",
+ "pdf",
+ "document",
+ "text",
+ "general"
+]Input schema / properties / reference_type / enumPrevious value: -[
- "image",
- "video",
- "audio",
- "pdf",
- "document",
- "text"
-]New value: +[
+ "image",
+ "video",
+ "audio",
+ "pdf",
+ "document",
+ "text",
+ "general"
+]Input schema / properties / text / descriptionPrevious value: -"Max 8192 body / 500 DISPLAY text (mention markup discounted) — the 500 usually BINDS. Servers count BYTES today, so non-ASCII trips it sooner: ~500 English but ~166 Japanese. Mentions count toward 8192 only. A separate 2048-BYTE budget applies to the JSON-encoded `reference` anchor, where each non-ASCII character costs SIX bytes."New value: +"Max 8192 body / 500 DISPLAY text (mention markup discounted) — the 500 usually BINDS. Both count CHARACTERS — CJK and emoji cost one each, same as ASCII. Mentions count toward 8192 only. A separate 2048-BYTE budget applies to the JSON-encoded `reference` anchor, where each non-ASCII character costs SIX bytes."invitation1 field changedInput schema / properties / expires / descriptionPrevious value: -"Updated expiration (ISO 8601 or YYYY-MM-DD HH:MM:SS)."New value: +"Updated expiration — `YYYY-MM-DD HH:MM:SS UTC`. ISO 8601 is NOT documented as accepted."member1 field changedInput schema / properties / expires / descriptionPrevious value: -"Expiration: workspace ISO 8601, share YYYY-MM-DD HH:MM:SS."New value: +"Membership expiration — `YYYY-MM-DD HH:MM:SS UTC` for BOTH workspace and share. ISO 8601 is NOT accepted (406)."metadata1 field changedInput schema / properties / description / descriptionPrevious value: -"Template description. ≤1000 chars, empty allowed (template-create/-update/-clone). preview-match: required, 1-2000. suggest-fields: optional, ≤2000."New value: +"Template description. ≤255 chars, empty allowed (template-create/-update/-clone). preview-match: required, 1-2000. suggest-fields: optional, ≤2000."org5 fields changedInput schema / properties / action / enumPrevious value: -[
- "describe",
- "list",
- "details",
- "create",
- "update",
- "close",
- "public-details",
- "limits",
- "industry-list",
- "list-workspaces",
- "list-shares",
- "create-workspace",
- "billing-plans",
- "billing-create",
- "billing-cancel",
- "billing-reactivate",
- "billing-details",
- "billing-invoices",
- "billing-members",
- "billing-meters",
- "members",
- "invite-member",
- "remove-member",
- "update-member-role",
- "member-details",
- "leave",
- "transfer-ownership",
- "join",
- "invitations-list",
- "invitation-update",
- "invitation-delete",
- "transfer-token-create",
- "transfer-token-list",
- "transfer-token-delete",
- "transfer-claim",
- "discover-all",
- "discover-available",
- "discover-check-domain",
- "discover-external",
- "asset-upload",
- "asset-delete",
- "asset-types",
- "asset-list",
- "custom-domain-get",
- "custom-domain-create",
- "custom-domain-delete",
- "custom-domain-validate"
-]New value: +[
+ "describe",
+ "list",
+ "details",
+ "create",
+ "update",
+ "close",
+ "public-details",
+ "limits",
+ "industry-list",
+ "list-workspaces",
+ "list-shares",
+ "create-workspace",
+ "billing-plans",
+ "billing-create",
+ "billing-cancel",
+ "billing-reactivate",
+ "billing-details",
+ "billing-invoices",
+ "billing-members",
+ "billing-meters",
+ "members",
+ "invite-member",
+ "remove-member",
+ "update-member-role",
+ "member-details",
+ "leave",
+ "transfer-ownership",
+ "join",
+ "invitations-list",
+ "invitation-update",
+ "invitation-delete",
+ "transfer-token-create",
+ "transfer-token-list",
+ "transfer-token-delete",
+ "transfer-claim",
+ "discover-all",
+ "discover-available",
+ "discover-check-domain",
+ "discover-external",
+ "asset-upload",
+ "asset-delete",
+ "asset-types",
+ "asset-list"
+]Input schema / properties / domain / descriptionPrevious value: -"URL-safe subdomain (2-63 chars, lowercase, unique)."New value: +"URL-safe subdomain (2-80 chars, lowercase alphanumeric + hyphens, globally unique, not reserved)."Input schema / properties / domain / maxLengthPrevious value: -63New value: +80Input schema / properties / hostnameRemoved value: -{
- "description": "Custom domain FQDN, e.g. files.acme.com.",
- "type": "string"
-}Input schema / properties / role / descriptionPrevious value: -"Permission level: admin, member, guest, view (not 'owner')."New value: +"Org permission level — `member` or `admin` ONLY. `owner` is not assignable (it is returned when READING members, alongside admin/member). `guest` and `view` are WORKSPACE/SHARE roles and are rejected here (1605)."room4 fields changedInput schema / properties / body / descriptionPrevious value: -"1-8192 CHARACTERS, but an UNDOCUMENTED 8192-BYTE ceiling underneath refuses non-ASCII far sooner: ~2730 CJK chars, ~2048 emoji, with a bare 174088 and no stated cause. post only. Do NOT put secrets here."New value: +"1-8192 CHARACTERS, counted in code points — a CJK or emoji character costs exactly one, same as ASCII. (A byte ceiling underneath this used to refuse non-ASCII far sooner; it was raised out of reach on 2026-08-05.) post only. Do NOT put secrets here."Input schema / properties / goal / descriptionPrevious value: -"create only. 1-500 chars, no control characters. Do NOT put secrets here."New value: +"create only. 1-500 chars, no control chars. ⚠️ SET ONCE — server-owned and IMMUTABLE. If the (workspace, topic_slug) room exists, create ADOPTS it (created:false) and the STORED goal wins — yours is discarded silently, no error. You cannot correct a goal by re-creating, so write one that survives: the durable purpose, not the current step. No secrets."Input schema / properties / since / descriptionPrevious value: -"messages only. Opaque keyset cursor from a prior page's next_cursor. Omit for the first page; never parse it."New value: +"messages only. Opaque keyset cursor from a prior page's next_cursor (or latest_cursor to start the follow loop). Omit for the first page; never parse it. A cursor REMEMBERS its direction — send it back WITHOUT sort; passing a conflicting sort is an error, not a silent flip. To change direction, drop since and start a new page."Input schema / properties / sortAdded value: +{
+ "description": "messages only. asc (DEFAULT) = oldest-first, FOLLOWS the log and is never finished — has_more:false just means caught up for now, so keep polling. desc = newest-first BACKFILL and IS terminal: a page that does not fill means you reached the beginning. Joining a busy room? Do NOT drain from the start — read the tail once with sort=desc, then follow with since=<latest_cursor>.",
+ "enum": [
+ "asc",
+ "desc"
+ ],
+ "type": "string"
+}share1 field changedInput schema / properties / custom_name / descriptionPrevious value: -"Custom share URL name (4-80 chars, alphanumeric)."New value: +"Custom share URL name (4-80 chars; Unicode letters, digits, hyphens, underscores). Omit to have one auto-generated."storage1 field changedInput schema / properties / lock_tokenAdded value: +{
+ "description": "lock-release/lock-heartbeat only — the token returned by lock-acquire. REQUIRED to release or refresh a lock.",
+ "type": "string"
+}upload2 fields changedInput schema / properties / wait / descriptionPrevious value: -"Long-poll duration ms (0 = return immediately)."New value: +"Long-poll wait in SECONDS, 1-590 (NOT milliseconds; 0/omitted returns immediately). The server holds the connection until the upload reaches a terminal status. Sending a millisecond value here would hold for minutes and blow past the tool-call timeout."Input schema / properties / wait / maximumPrevious value: -9007199254740991New value: +590ai6 fields changedInput schema / properties / detail / descriptionPrevious value: -"Per-entity verbosity for chat-list/chat-details/message-list/message-details (best-effort: chat/message/activity endpoints may not yet honor detail…"New value: +"Per-entity verbosity for chat-list/chat-details/message-list/message-details (best-effort: chat/message/activity endpoints may not yet honor detail server-side). Defaults: terse for list-style (chat-list, message-list), full for details (chat-details, message-details). See action='describe' for per-level field lists."Input schema / properties / files_attach / descriptionPrevious value: -"Attach workspace FILES for the AI to read directly (comma-separated nodeId:versionId pairs; versionId optional → backend resolves current). Works regardless of…"New value: +"Attach workspace FILES for the AI to read directly (comma-separated nodeId:versionId pairs; versionId optional → backend resolves current). Works regardless of workspace intelligence. A missing/inaccessible/ineligible node ERRORS (not a silent drop). See describe."Input schema / properties / kind / descriptionPrevious value: -"chat-create (workspace only): 'user' (default) or 'agent' — flags the chat as agentic; set at creation, immutable; not accepted on share chats. chat-list:…"New value: +"chat-create (workspace only): 'user' (default) or 'agent' — flags the chat as agentic; set at creation, immutable; not accepted on share chats. chat-list: filter by 'user'|'agent'|'all'."Input schema / properties / limit / descriptionPrevious value: -"chat-list/message-list page size. Best-effort: the AI API spec documents NO pagination on the chat-list or message-list endpoints (both return all rows under…"New value: +"chat-list/message-list page size. Best-effort: the AI API spec documents NO pagination on the chat-list or message-list endpoints (both return all rows under {count, items}), so this is forwarded but may be a silent no-op until the platform adds paging."Input schema / properties / profile_id / descriptionPrevious value: -"Polymorphic context ID (pair with profile_type=workspace|share). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also…"New value: +"Polymorphic context ID (pair with profile_type=workspace|share). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also context_id / instance_id. 19-digit workspace or share ID."Input schema / properties / wait / descriptionPrevious value: -"message-read only. Default true: bounded-wait for completion (up to ~24s on a workspace via the activity long-poll). Set false for a single-shot status probe…"New value: +"message-read only. Default true: bounded-wait for completion (up to ~24s on a workspace via the activity long-poll). Set false for a single-shot status probe (one details fetch, ~1 round-trip) — useful against strict ~30s client timeouts."auth2 fields changedInput schema / properties / code / descriptionPrevious value: -"Verification or authorization code. Meaning is action-specific — see action='describe' for the per-action reference (e.g. 2FA code for 2fa-verify, reset code…"New value: +"Verification or authorization code. Meaning is action-specific — see action='describe' for the per-action reference (e.g. 2FA code for 2fa-verify, reset code for password-reset, OAuth code for pkce-complete)."Input schema / properties / token / descriptionPrevious value: -"2FA / verification token. Meaning is action-specific — see action='describe' for the per-action reference (e.g. 2FA-disable token, 2fa-verify-setup token, 2FA…"New value: +"2FA / verification token. Meaning is action-specific — see action='describe' for the per-action reference (e.g. 2FA-disable token, 2fa-verify-setup token, 2FA token for api-key-create/api-key-delete)."comment11 fields changedInput schema / properties / detail / descriptionPrevious value: -"Per-comment verbosity for list/list-all/details. Defaults: terse for list/list-all (compact rows), full for details (drill-down). See action='describe' for…"New value: +"Per-comment verbosity for list/list-all/details. Defaults: terse for list/list-all (compact rows), full for details (drill-down). See action='describe' for per-level field lists."Input schema / properties / display_limit / descriptionPrevious value: -"list-all only — ignored on the markdown list action. Number of comments to return to the agent (default 10, max 200). Backend page_size unchanged for cache…"New value: +"list-all only — ignored on the markdown list action. Number of comments to return to the agent (default 10, max 200). Backend page_size unchanged for cache warmth (JSON only). Trims post-fetch only."Input schema / properties / profile_id / descriptionPrevious value: -"Polymorphic context ID (pair with profile_type=workspace|share). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also…"New value: +"Polymorphic context ID (pair with profile_type=workspace|share). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also context_id. 19-digit profile ID."Input schema / properties / properties / descriptionPrevious value: -"Arbitrary key-value JSON object metadata (edit action only). Accepts a native object or a JSON string. Merged into the comment's stored properties;…"New value: +"Arbitrary key-value JSON object metadata (edit action only). Accepts a native object or a JSON string. Merged into the comment's stored properties; server-managed keys (reactions, version, version_hash, edited_at, content_filtered, mentions) supplied here are ignored."Input schema / properties / reference / properties / exact / descriptionPrevious value: -"Verbatim selected text."New value: +"Verbatim selected text (max 500 characters)."Input schema / properties / reference / properties / exact / maxLengthPrevious value: -500New value: +1000Input schema / properties / reference / properties / prefix / descriptionPrevious value: -"~30-50 chars before selection."New value: +"~30-50 chars before selection (max 100 characters)."Input schema / properties / reference / properties / prefix / maxLengthPrevious value: -100New value: +200Input schema / properties / reference / properties / suffix / descriptionPrevious value: -"~30-50 chars after selection."New value: +"~30-50 chars after selection (max 100 characters)."Input schema / properties / reference / properties / suffix / maxLengthPrevious value: -100New value: +200Input schema / properties / text / descriptionPrevious value: -"Comment body (max 8192 chars; max 500 display chars with mention tags stripped). Supports @[profile|user|file:...] mentions."New value: +"Max 8192 body / 500 DISPLAY text (mention markup discounted) — the 500 usually BINDS. Servers count BYTES today, so non-ASCII trips it sooner: ~500 English but ~166 Japanese. Mentions count toward 8192 only. A separate 2048-BYTE budget applies to the JSON-encoded `reference` anchor, where each non-ASCII character costs SIX bytes."download1 field changedInput schema / properties / profile_id / descriptionPrevious value: -"Polymorphic context ID. Pair with profile_type=workspace|share. Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also…"New value: +"Polymorphic context ID. Pair with profile_type=workspace|share. Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also context_id / instance_id. 19-digit profile ID or custom name."event6 fields changedInput schema / properties / card_key / descriptionPrevious value: -"Dashboard card identity \"<lane>:<id>\" (e.g. \"mention:123\"). From a dashboard-list card. Required for dashboard-dismiss/dashboard-undismiss; URL-encoded into…"New value: +"Dashboard card identity \"<lane>:<id>\" (e.g. \"mention:123\"). From a dashboard-list card. Required for dashboard-dismiss/dashboard-undismiss; URL-encoded into the path by the server."Input schema / properties / detail / descriptionPrevious value: -"Per-record verbosity for search/summarize/details/activity-list/activity-poll. Defaults: terse for search/activity-list/activity-poll (compact rows), standard…"New value: +"Per-record verbosity for search/summarize/details/activity-list/activity-poll. Defaults: terse for search/activity-list/activity-poll (compact rows), standard for summarize, full for details (drill-down). See action='describe' for per-level field lists."Input schema / properties / entity_id / descriptionPrevious value: -"Opaque ID of a specific object (file, comment, etc.). Pair with entity_type to disambiguate. 19-digit workspace, share, or File Share ID to monitor…"New value: +"Opaque ID of a specific object (file, comment, etc.). Pair with entity_type to disambiguate. 19-digit workspace, share, or File Share ID to monitor (activity-poll long-polls GET /activity/poll/{id}/ — for a File Share id this surfaces its file_share_* feed to WORKSPACE MEMBERS only; recipients get no feed)."Input schema / properties / profile_id / descriptionPrevious value: -"Polymorphic context ID. Pair with profile_type=workspace|share|org|fileshare. Use workspace_id instead when only workspaces are valid. 19-digit profile ID…"New value: +"Polymorphic context ID. Pair with profile_type=workspace|share|org|fileshare. Use workspace_id instead when only workspaces are valid. 19-digit profile ID (workspace, share, or File Share)."Input schema / properties / profile_type / descriptionPrevious value: -"Profile type: \"workspace\", \"share\", or \"fileshare\". `fileshare` is valid for activity-list (long-poll a File Share's feed — workspace members only; recipients…"New value: +"Profile type: \"workspace\", \"share\", or \"fileshare\". `fileshare` is valid for activity-list (long-poll a File Share's feed — workspace members only; recipients get no feed)."Input schema / properties / workspace_id / descriptionPrevious value: -"Workspace opaque ID. Use this when only workspaces are valid (not shares or other contexts). For polymorphic contexts use profile_id. Filter by workspace…"New value: +"Workspace opaque ID. Use this when only workspaces are valid (not shares or other contexts). For polymorphic contexts use profile_id. Filter by workspace profile ID."fileshare4 fields changedInput schema / properties / access_option / descriptionPrevious value: -"Access tier: anyone_with_link | any_registered | named_people. create / update. `edit` capability is NEVER conferred by a tier — it always needs an explicit…"New value: +"Access tier: anyone_with_link | any_registered | named_people. create / update. `edit` capability is NEVER conferred by a tier — it always needs an explicit edit grant."Input schema / properties / email / descriptionPrevious value: -"grant-add / grant-revoke: the grantee's email. EXACTLY ONE of user / email. An unregistered email becomes a PENDING invite (auto-activates on signup; capped to…"New value: +"grant-add / grant-revoke: the grantee's email. EXACTLY ONE of user / email. An unregistered email becomes a PENDING invite (auto-activates on signup; capped to the share's expiry)."Input schema / properties / expires_at / descriptionPrevious value: -"create/update: absolute expiry as 'YYYY-MM-DD HH:MM:SS UTC' (no timezone = UTC). Mutually exclusive with expires. update: send '' (empty string) to CLEAR the…"New value: +"create/update: absolute expiry as 'YYYY-MM-DD HH:MM:SS UTC' (no timezone = UTC). Mutually exclusive with expires. update: send '' (empty string) to CLEAR the expiry and make the share durable again."Input schema / properties / password / descriptionPrevious value: -"create/update: SET the share password. On consumer actions (details / download-url / preview-url / versions-list / version-download-url): supply the recipient…"New value: +"create/update: SET the share password. On consumer actions (details / download-url / preview-url / versions-list / version-download-url): supply the recipient password — forwarded ONLY as the x-ve-password header, never in a URL/log. update: send '' (empty string) to CLEAR an existing password."find4 fields changedInput schema / properties / case_sensitiveAdded value: +{
+ "description": "Case-sensitive matching for exact/prefix/contains/glob. Default false (like find -iname), which folds non-ASCII too. Ignored under name_match=auto.",
+ "type": "boolean"
+}Input schema / properties / name_matchAdded value: +{
+ "description": "auto (DEFAULT) | exact | prefix | contains | glob. exact = whole name; prefix = starts with; contains = substring — those three are LITERAL (* and ? are ordinary chars). glob = wildcards over the WHOLE name: *.pdf, report-*.xlsx. Do NOT pre-escape. Applies when search_in is filename or both; auto keeps today's relevance. Precise modes cap the pattern at 256 chars, reject an empty one.",
+ "enum": [
+ "auto",
+ "exact",
+ "prefix",
+ "contains",
+ "glob"
+ ],
+ "type": "string"
+}Input schema / properties / profile_id / descriptionPrevious value: -"Workspace or share opaque ID (19-digit numeric ID or custom name). Pair with profile_type. Four accepted aliases besides this one (five id params total):…"New value: +"Workspace or share opaque ID (19-digit numeric ID or custom name). Pair with profile_type. Four accepted aliases besides this one (five id params total): workspace_id, share_id, context_id, instance_id — the supplied id must match profile_type (workspace_id only with profile_type=workspace, share_id only with share)."Input schema / properties / search_inAdded value: +{
+ "description": "filename | content | both (DEFAULT). filename = name only, find-style. content = the AI's summary + semantic, NOT grep. OMIT unless you mean it — sending it changes the response shape (adds a search_metadata block); omitting reproduces today's behavior byte-for-byte. Pair filename with name_match.",
+ "enum": [
+ "filename",
+ "content",
+ "both"
+ ],
+ "type": "string"
+}how-to2 fields changedInput schema / properties / context / descriptionPrevious value: -"Optional free-text background about your situation (what you're trying to accomplish, what you've tried). Up to 8000 chars. Treated strictly as untrusted DATA…"New value: +"Optional free-text background about your situation (what you're trying to accomplish, what you've tried). Up to 8000 chars. Treated strictly as untrusted DATA — it cannot redirect the assistant. Omit when empty."Input schema / properties / question / descriptionPrevious value: -"The natural-language \"how do I…\" question about Fastio. 1-2000 chars, non-blank. Be specific — a vague question returns a clarifying question instead of an…"New value: +"The natural-language \"how do I…\" question about Fastio. 1-2000 chars, non-blank. Be specific — a vague question returns a clarifying question instead of an answer."member1 field changedInput schema / properties / display_limit / descriptionPrevious value: -"How many members to return for the list action. Default 10, max 500. The MCP trims post-fetch; backend paging stays MCP-internal so the platform cache stays…"New value: +"How many members to return for the list action. Default 10, max 500. The MCP trims post-fetch; backend paging stays MCP-internal so the platform cache stays warm."metadata5 fields changedInput schema / properties / config / descriptionPrevious value: -"view-save config JSON: `{version:1, columns:[{field,visible?,width?}], sort:{field,dir}, filters:[{field,operator,value_type,value}]}`. Max 5 filters…"New value: +"view-save config JSON: `{version:1, columns:[{field,visible?,width?}], sort:{field,dir}, filters:[{field,operator,value_type,value}]}`. Max 5 filters AND-chained; operator in `= != < <= > >=`; value_type in `string|int|float|bool`."Input schema / properties / display_limit / descriptionPrevious value: -"search: how many items to return post-fetch. Default 10, max 100 (the backend fetches at most 100 per page — a higher value has no effect; use offset to page…"New value: +"search: how many items to return post-fetch. Default 10, max 100 (the backend fetches at most 100 per page — a higher value has no effect; use offset to page past 100)."Input schema / properties / fields / descriptionPrevious value: -"JSON array of field defs (template-create/-update/-clone). At least one field must have autoextract:true (default) or API returns 1605. Each: {name,…"New value: +"JSON array of field defs (template-create/-update/-clone). At least one field must have autoextract:true (default) or API returns 1605. Each: {name, description, type (string|int|float|bool|json|url|datetime), min?, max?, default?, fixed_list?, can_be_null?, autoextract?}."Input schema / properties / name / descriptionPrevious value: -"Template name (1-255 chars: template-create/-update/-clone and preview-match), OR an optional saved-view label on view-save (≤30 chars; omit to keep the…"New value: +"Template name (1-255 chars: template-create/-update/-clone and preview-match), OR an optional saved-view label on view-save (≤30 chars; omit to keep the existing label)."Input schema / properties / node_ids / descriptionPrevious value: -"JSON array of node IDs. suggest-fields: 1-25 file nodes. nodes-add/-remove: nodes to map/unmap (files+notes; folders/links rejected) — deduped first-seen, max…"New value: +"JSON array of node IDs. suggest-fields: 1-25 file nodes. nodes-add/-remove: nodes to map/unmap (files+notes; folders/links rejected) — deduped first-seen, max 50 unique per call (the server hard-rejects >50 per request; the per-template TOTAL node cap is separate and enforced server-side)."org2 fields changedInput schema / properties / billing_plan / descriptionPrevious value: -"Paid plan ID for billing-create, e.g. 'solo_monthly', 'business_v2_monthly', 'growth_monthly' (each has an annual variant). New orgs require a paid plan —…"New value: +"Paid plan ID for billing-create, e.g. 'solo_monthly', 'business_v2_monthly', 'growth_monthly' (each has an annual variant). New orgs require a paid plan — free/agent plans are legacy and closed to new subscriptions; legacy 'pro_monthly'/'business_monthly' are also closed. Call billing-plans for the currently-offered plan IDs."Input schema / properties / detail / descriptionPrevious value: -"Per-entity verbosity for list/discover-*/members/list-workspaces/details. Defaults: terse for list/discover-*/members/list-workspaces, full for details. See…"New value: +"Per-entity verbosity for list/discover-*/members/list-workspaces/details. Defaults: terse for list/discover-*/members/list-workspaces, full for details. See action='describe' for per-level field lists."room10 fields changedInput schema / properties / agent_label / descriptionPrevious value: -"Your agent's PUBLIC SENDER IDENTITY — the display name peers and humans see on EVERY message and roster row, for the room's life (the roster `id` is keyed off…"New value: +"Your agent's PUBLIC SENDER IDENTITY — the name peers and humans see on every message and roster row. Use a MEANINGFUL, STABLE name (your real assistant name), never a placeholder. Max 120 chars, room-wide unique among LIVE participants (409 if held). Pass it on state/status/post/messages/wait or your presence drifts to alive:false. Full rules: action=describe."Input schema / properties / agent_label / maxLengthPrevious value: -120New value: +240Input schema / properties / body / descriptionPrevious value: -"post only. Message body, 1-8192 chars. Do NOT put secrets here."New value: +"1-8192 CHARACTERS, but an UNDOCUMENTED 8192-BYTE ceiling underneath refuses non-ASCII far sooner: ~2730 CJK chars, ~2048 emoji, with a bare 174088 and no stated cause. post only. Do NOT put secrets here."Input schema / properties / display_text / maxLengthPrevious value: -500New value: +1000Input schema / properties / goal / maxLengthPrevious value: -500New value: +1000Input schema / properties / lastactivity / descriptionPrevious value: -"wait only. Activity cursor from a prior wait response — echo it VERBATIM (it carries fractional seconds; truncating/reformatting to Y-m-d H:i:s causes instant…"New value: +"wait only. Activity cursor from a prior wait response — echo it VERBATIM (it carries fractional seconds; truncating/reformatting to Y-m-d H:i:s causes instant stale re-wakes). Omit on the first wait."Input schema / properties / status_summary / maxLengthPrevious value: -500New value: +1000Input schema / properties / status_version / descriptionPrevious value: -"status only. The CAS version you last read. REQUIRED for an existing participant; omit ONLY on your VERY FIRST join (when you have no participant row yet). A…"New value: +"status only. The CAS version you last read. REQUIRED for an existing participant — omit ONLY on your VERY FIRST join. A re-keyed agent already HAS a row, so read its status_version from `state` first rather than omitting. On CAS conflict (192604 / 182596) retry with error.params.current_status_version. See action=describe."Input schema / properties / suggested_label / descriptionPrevious value: -"invite-create only. The redeeming agent's default agent_label = its PUBLIC SENDER IDENTITY in the room (the name peers and humans see on every message + roster…"New value: +"invite-create only. Default agent_label for the redeeming agent — its PUBLIC SENDER IDENTITY in the room. Suggest a MEANINGFUL, STABLE name, never a placeholder. 1-120 chars, no control chars, room-wide unique among LIVE participants (409 if held). Baked into the link; the redeemer may override. See action=describe."Input schema / properties / suggested_label / maxLengthPrevious value: -120New value: +240share3 fields changedInput schema / properties / detail / descriptionPrevious value: -"Per-entity verbosity for list/available/members/public-details/details. Defaults: terse for list/available/members, standard for public-details, full for…"New value: +"Per-entity verbosity for list/available/members/public-details/details. Defaults: terse for list/available/members, standard for public-details, full for details. See action='describe' for per-level field lists."Input schema / properties / limit / descriptionPrevious value: -"Internal backend page_size — stays MCP-internal so the platform cache stays warm. Use display_limit to control how many rows are actually returned. Forwarded…"New value: +"Internal backend page_size — stays MCP-internal so the platform cache stays warm. Use display_limit to control how many rows are actually returned. Forwarded by list/members."Input schema / properties / node_id / descriptionPrevious value: -"Storage tree node opaque ID. Both files and folders are nodes — use this name regardless of which. File node opaque ID. Quickshares: single file, max 1 GB,…"New value: +"Storage tree node opaque ID. Both files and folders are nodes — use this name regardless of which. File node opaque ID. Quickshares: single file, max 1 GB, default 3h, max 7 days."storage12 fields changedInput schema / properties / as_markdown / descriptionPrevious value: -"Opt-in (list/recent/search/details/trash-list): when true, the platform renders the response as GitHub-flavored Markdown (?output=<detail>,markdown) for…"New value: +"Opt-in (list/recent/search/details/trash-list): when true, the platform renders the response as GitHub-flavored Markdown (?output=<detail>,markdown) for compact, human/agent-readable output instead of JSON. Omit (default) for the unchanged JSON shape with web_url enrichment + _next hints. Markdown is a passthrough — no client-side reshaping."Input schema / properties / case_sensitiveAdded value: +{
+ "description": "Case-sensitive matching for exact/prefix/contains/glob. Default false (like find -iname), which folds non-ASCII too. Ignored under name_match=auto.",
+ "type": "boolean"
+}Input schema / properties / dest_parent_id / descriptionPrevious value: -"Destination parent folder opaque ID, or 'root'. Primary param for transfer (the parent in the OTHER instance). For copy/move within the same instance use…"New value: +"Destination parent folder opaque ID, or 'root'. Primary param for transfer (the parent in the OTHER instance). For copy/move within the same instance use target_parent_id — dest_parent_id is also accepted there as an alias."Input schema / properties / detail / descriptionPrevious value: -"Per-node verbosity for list/recent/search/trash-list/details. Defaults: terse for list/recent/search/trash-list, full for details. Bump to full when you need…"New value: +"Per-node verbosity for list/recent/search/trash-list/details. Defaults: terse for list/recent/search/trash-list, full for details. Bump to full when you need ai.attach (files_attach preflight), virus, hashes, file_attributes, lock_info, or long-form summaries. See action='describe' for per-level field lists. Not to be confused with `details` (search-only)."Input schema / properties / display_limit / descriptionPrevious value: -"How many items to return. Default 10, max 500. The MCP trims post-fetch; backend cache stays warm. Used by: list, recent, search. list/recent paginate via the…"New value: +"How many items to return. Default 10, max 500. The MCP trims post-fetch; backend cache stays warm. Used by: list, recent, search. list/recent paginate via the `cursor` param; search paginates via `offset` (increase offset by the page size) for additional pages."Input schema / properties / name_matchAdded value: +{
+ "description": "auto (DEFAULT) | exact | prefix | contains | glob. exact = whole name; prefix = starts with; contains = substring — those three are LITERAL (* and ? are ordinary chars). glob = wildcards over the WHOLE name: *.pdf, report-*.xlsx. Do NOT pre-escape. Applies when search_in is filename or both; auto keeps today's relevance. Precise modes cap the pattern at 256 chars, reject an empty one.",
+ "enum": [
+ "auto",
+ "exact",
+ "prefix",
+ "contains",
+ "glob"
+ ],
+ "type": "string"
+}Input schema / properties / node_id / descriptionPrevious value: -"Storage tree node opaque ID. Both files and folders are nodes — use this name regardless of which. Storage node opaque ID, or 'root'. On `list`, the target…"New value: +"Storage tree node opaque ID. Both files and folders are nodes — use this name regardless of which. Storage node opaque ID, or 'root'. On `list`, the target folder may also be given as parent_node_id or parent_id (aliases), and defaults to 'root' (the storage top level) when all three are omitted."Input schema / properties / node_type / descriptionPrevious value: -"rename-only OPTIONAL hint: the node's type, when the caller already knows it. Notes route to a dedicated endpoint, so supplying node_type lets rename skip the…"New value: +"rename-only OPTIONAL hint: the node's type, when the caller already knows it. Notes route to a dedicated endpoint, so supplying node_type lets rename skip the /details/ type-probe round-trip. Omit to have rename probe automatically. Distinct from the list/recent `type` filter."Input schema / properties / profile_id / descriptionPrevious value: -"Polymorphic context ID (pair with profile_type=workspace|share). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share, on…"New value: +"Polymorphic context ID (pair with profile_type=workspace|share). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share, on dual-type actions); also context_id / instance_id. 19-digit workspace or share ID, or custom name."Input schema / properties / search_inAdded value: +{
+ "description": "filename | content | both (DEFAULT). filename = name only, find-style. content = the AI's summary + semantic, NOT grep. OMIT unless you mean it — sending it changes the response shape (adds a search_metadata block); omitting reproduces today's behavior byte-for-byte. Pair filename with name_match.",
+ "enum": [
+ "filename",
+ "content",
+ "both"
+ ],
+ "type": "string"
+}Input schema / properties / share_id / descriptionPrevious value: -"For add-link: the target share to link (workspace-only). For the dual-type actions (list/details/copy/move/etc.): a profile alias implying profile_type=share —…"New value: +"For add-link: the target share to link (workspace-only). For the dual-type actions (list/details/copy/move/etc.): a profile alias implying profile_type=share — the share you are operating in (so profile_type may be omitted)."Input schema / properties / template_id / descriptionPrevious value: -"Metadata template ID (e.g. mt_abc123). Required for metadata-set/metadata-list-files. The template SYSTEM (CRUD/assign/AI-extraction) lives on the `metadata`…"New value: +"Metadata template ID (e.g. mt_abc123). Required for metadata-set/metadata-list-files. The template SYSTEM (CRUD/assign/AI-extraction) lives on the `metadata` tool."upload9 fields changedInput schema / properties / content_base64 / descriptionPrevious value: -"Base64-encoded **binary**, server-decoded (whitespace stripped). **Fallback only** — capped a few MB by the MCP transport. Prefer `blob_id` (POST /blob) for…"New value: +"Base64-encoded **binary**, server-decoded (whitespace stripped). **Fallback only** — capped a few MB by the MCP transport. Prefer `blob_id` (POST /blob) for any file/binary; use this only when your client cannot make the POST /blob call."Input schema / properties / files / items / properties / filename / descriptionPrevious value: -"File name (1-255 chars; server truncates >100 chars while preserving extension)."New value: +"File name (1-255 characters). An over-length name is a hard ERROR — the platform no longer truncates."Input schema / properties / files / items / properties / filename / maxLengthRemoved value: -255Input schema / properties / files / items / properties / relative_path / maxLengthRemoved value: -8192Input schema / properties / if_version_id / descriptionPrevious value: -"File Share write-back compare-and-swap (profile_type=fileshare only). Pass the version id the edit was based on (from `fileshare details` / `fileshare…"New value: +"File Share write-back compare-and-swap (profile_type=fileshare only). Pass the version id your edit was based on (from fileshare details / versions-list). If the file advanced, NOTHING is written — the session ends assembly_failed with CONFLICT_VERSION_MISMATCH:<id>; rebase and retry. Omitting it is last-write-wins. See action=describe."Input schema / properties / password / descriptionPrevious value: -"File Share link password (profile_type=fileshare only). Forwarded ONLY as the x-ve-password header on every upload phase — never in a URL/log. Supply when the…"New value: +"File Share link password (profile_type=fileshare only). Forwarded ONLY as the x-ve-password header on every upload phase — never in a URL/log. Supply when the target share is password-protected."Input schema / properties / profile_id / descriptionPrevious value: -"Polymorphic context ID (pair with profile_type=workspace|share|fileshare). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒…"New value: +"Polymorphic context ID (pair with profile_type=workspace|share|fileshare). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also context_id / instance_id. Target workspace/share ID, or the File Share id for a fileshare write-back. fileshare has NO typed alias — pass profile_type=fileshare explicitly."Input schema / properties / profile_type / descriptionPrevious value: -"Target type: workspace | share | fileshare (alias: context_type). Use `fileshare` ONLY for content write-back to a File Share's bound file (requires…"New value: +"Target type: workspace | share | fileshare (alias: context_type). Use `fileshare` ONLY for content write-back to a File Share's bound file (requires target_node_id = the bound node id from `fileshare details`; create-style new-file flows are rejected for fileshare)."Input schema / properties / target_node_id / descriptionPrevious value: -"Overwrite this specific node (preserves node_id; new version). When set, parent_node_id is ignored and filename is optional (auto-resolved). Must be a file…"New value: +"Overwrite this specific node (preserves node_id; new version). When set, parent_node_id is ignored and filename is optional (auto-resolved). Must be a file node. REQUIRED for profile_type=fileshare write-back — set it to the File Share's bound node id (from `fileshare details` → fileshare.file.id)."user1 field changedInput schema / properties / display_limit / descriptionPrevious value: -"How 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…"New value: +"How 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-shares."workspace6 fields changedInput schema / properties / config / descriptionPrevious value: -"Saved-view config JSON: `{version:1, columns:[{field,visible?,width?}], sort:{field,dir}, filters:[{field,operator,value_type,value}]}`. Max 5 filters…"New value: +"Saved-view config JSON: `{version:1, columns:[{field,visible?,width?}], sort:{field,dir}, filters:[{field,operator,value_type,value}]}`. Max 5 filters AND-chained; operator in `= != < <= > >=`; value_type in `string|int|float|bool`."Input schema / properties / description / descriptionPrevious value: -"Description. metadata-template-create: required, 0-1000 (empty allowed); metadata-template-update/-clone: 10-1000; preview-match/suggest-fields: 1-2000.…"New value: +"Description. metadata-template-create: required, 0-1000 (empty allowed); metadata-template-update/-clone: 10-1000; preview-match/suggest-fields: 1-2000. Newlines allowed. Send \"null\"/\"\" to clear on update."Input schema / properties / detail / descriptionPrevious value: -"Per-entity verbosity for list/available/members/list-shares/details. Defaults: terse for list/available/members/list-shares, full for details. See…"New value: +"Per-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."Input schema / properties / display_limit / descriptionPrevious value: -"How 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…"New value: +"How 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, metadata-search."Input schema / properties / fields / descriptionPrevious value: -"JSON array of field defs. At least one field must have autoextract:true (default) or API returns 1605. Each: {name, description, type…"New value: +"JSON array of field defs. At least one field must have autoextract:true (default) or API returns 1605. Each: {name, description, type (string|int|float|bool|json|url|datetime), min?, max?, default?, fixed_list?, can_be_null?, autoextract?}."Input schema / properties / workspace_id / descriptionPrevious value: -"Workspace 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…"New value: +"Workspace 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."roomcomment4 fields changedInput schema / properties / action / enumPrevious value: -[
- "describe",
- "list",
- "list-all",
- "add",
- "edit",
- "delete",
- "bulk-delete",
- "details",
- "reaction-add",
- "reaction-remove",
- "link",
- "unlink",
- "linked"
-]New value: +[
+ "describe",
+ "list",
+ "list-all",
+ "add",
+ "edit",
+ "delete",
+ "bulk-delete",
+ "details",
+ "reaction-add",
+ "reaction-remove"
+]Input schema / properties / detail / descriptionPrevious value: -"Per-comment verbosity for list/list-all/details/linked. Defaults: terse for list/list-all/linked (compact rows), full for details (drill-down). See…"New value: +"Per-comment verbosity for list/list-all/details. Defaults: terse for list/list-all (compact rows), full for details (drill-down). See action='describe' for…"Input schema / properties / linked_entity_idRemoved value: -{
- "description": "Task opaque ID.",
- "minLength": 1,
- "type": "string"
-}Input schema / properties / linked_entity_typeRemoved value: -{
- "description": "Linked entity type — only 'task' is supported today.",
- "enum": [
- "task"
- ],
- "type": "string"
-}event3 fields changedInput schema / properties / action / enumPrevious value: -[
- "describe",
- "search",
- "summarize",
- "details",
- "acknowledge",
- "activity-list",
- "activity-poll",
- "dashboard-list",
- "dashboard-dismiss",
- "dashboard-undismiss",
- "dashboard-sign-link"
-]New value: +[
+ "describe",
+ "search",
+ "summarize",
+ "details",
+ "acknowledge",
+ "activity-list",
+ "activity-poll",
+ "dashboard-list",
+ "dashboard-dismiss",
+ "dashboard-undismiss"
+]Input schema / properties / card_key / descriptionPrevious value: -"Dashboard card identity \"<lane>:<id>\" (e.g. \"obligation:123\"). From a dashboard-list card. Required for dashboard-dismiss/dashboard-undismiss; URL-encoded into…"New value: +"Dashboard card identity \"<lane>:<id>\" (e.g. \"mention:123\"). From a dashboard-list card. Required for dashboard-dismiss/dashboard-undismiss; URL-encoded into…"Input schema / properties / envelope_idRemoved value: -{
- "description": "Signature envelope id (a signature card's target.id). Required for dashboard-sign-link.",
- "minLength": 1,
- "type": "string"
-}find2 fields changedInput schema / properties / workflows_limitRemoved value: -{
- "description": "workflows bucket page size (default 25).",
- "maximum": 9007199254740991,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / workflows_offsetRemoved value: -{
- "description": "workflows bucket result offset (default 0).",
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
-}share21 fields changedInput schema / properties / action / enumPrevious value: -[
- "describe",
- "list",
- "details",
- "create",
- "update",
- "delete",
- "public-details",
- "archive",
- "unarchive",
- "password-auth",
- "members",
- "available",
- "check-name",
- "quickshare-create",
- "enable-workflow",
- "disable-workflow",
- "autotitle",
- "review-surface-create",
- "review-surface-get",
- "review-list-active",
- "review-cancel",
- "review-admin-resolve",
- "review-reviewer-add-member",
- "review-reviewer-add-external",
- "review-reviewer-remove",
- "review-decision"
-]New value: +[
+ "describe",
+ "list",
+ "details",
+ "create",
+ "update",
+ "delete",
+ "public-details",
+ "archive",
+ "unarchive",
+ "password-auth",
+ "members",
+ "available",
+ "check-name",
+ "quickshare-create",
+ "autotitle"
+]Input schema / properties / asset_idRemoved value: -{
- "description": "Share-review asset id (one reviewed file). review-decision.",
- "type": "string"
-}Input schema / properties / comment_textRemoved value: -{
- "description": "review-decision: the reason. REQUIRED (non-blank) for decision='reject'/'request_changes'; optional for 'approve'. A blank reason on reject/request_changes is…",
- "maxLength": 65535,
- "type": "string"
-}Input schema / properties / confirm / descriptionPrevious value: -"delete: must match the share's custom_name or id (validated client-side before the call). review-admin-resolve: must be 'true' (the force-resolve confirmation…"New value: +"delete: must match the share's custom_name or id (validated client-side before the call)."Input schema / properties / deadline_atRemoved value: -{
- "description": "review-surface-create: optional review deadline ('YYYY-MM-DD HH:MM:SS' UTC).",
- "type": "string"
-}Input schema / properties / decisionRemoved value: -{
- "description": "review-decision: approve | reject | request_changes (sent to the platform as `action`).",
- "enum": [
- "approve",
- "reject",
- "request_changes"
- ],
- "type": "string"
-}Input schema / properties / emailRemoved value: -{
- "description": "review-reviewer-add-external: external reviewer email.",
- "minLength": 3,
- "type": "string"
-}Input schema / properties / idempotency_keyRemoved value: -{
- "description": "review-surface-create: replay-safe key (1-128). REQUIRED; same key returns the existing surface.",
- "maxLength": 128,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / invite_notesRemoved value: -{
- "description": "review-reviewer-add-external: optional note included in the magic-link invite email.",
- "maxLength": 4000,
- "type": "string"
-}Input schema / properties / member_user_idRemoved value: -{
- "description": "Share member's User ID to add as a reviewer. review-reviewer-add-member (must be a share member).",
- "type": "string"
-}Input schema / properties / messageRemoved value: -{
- "description": "review-surface-create: optional message to reviewers (max 4000).",
- "maxLength": 4000,
- "type": "string"
-}Input schema / properties / node_idsRemoved value: -{
- "description": "review-surface-create (target_mode=fileset): JSON array of node ids to review. Native or string.",
- "type": "string"
-}Input schema / properties / outcomeRemoved value: -{
- "description": "review-admin-resolve: force-resolve outcome approved|rejected.",
- "enum": [
- "approved",
- "rejected"
- ],
- "type": "string"
-}Input schema / properties / policy_modeRemoved value: -{
- "description": "review-surface-create: approval policy. quorum needs policy_quorum_n.",
- "enum": [
- "single",
- "unanimous",
- "quorum",
- "all_assets_all_approved",
- "overall_signoff"
- ],
- "type": "string"
-}Input schema / properties / policy_quorum_nRemoved value: -{
- "description": "review-surface-create: required approvals when policy_mode='quorum'.",
- "maximum": 9007199254740991,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / reviewer_idRemoved value: -{
- "description": "Share-review reviewer roster id. review-reviewer-remove.",
- "type": "string"
-}Input schema / properties / reviewer_nameRemoved value: -{
- "description": "review-reviewer-add-external: external reviewer's display name (1-255 chars; sent to the platform body field `name`). REQUIRED for review-reviewer-add-external.",
- "maxLength": 255,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / reviewersRemoved value: -{
- "description": "review-surface-create: REQUIRED non-empty JSON array of reviewer entries. Each entry is {\"kind\":\"member\",\"user_id\":\"<member user id>\"} OR…",
- "type": "string"
-}Input schema / properties / surface_idRemoved value: -{
- "description": "Share-review surface OpaqueId. review-surface-get/-cancel/-admin-resolve/-reviewer-*/-decision.",
- "type": "string"
-}Input schema / properties / target_modeRemoved value: -{
- "description": "review-surface-create: fileset (specific node_ids) or whole_share.",
- "enum": [
- "fileset",
- "whole_share"
- ],
- "type": "string"
-}Input schema / properties / version_id_pinnedRemoved value: -{
- "description": "review-decision: pinned asset version (CAS).",
- "type": "string"
-}taskupload2 fields changedInput schema / properties / blob_id / descriptionPrevious value: -"Blob ID from POST /blob. Preferred for binary/large files. Single-use."New value: +"Blob ID from POST /blob — the **default source** for all file & binary uploads (no base64, no MCP size limit, up to 100 MB). Single-use."Input schema / properties / content_base64 / descriptionPrevious value: -"Base64-encoded **binary** — server decodes before writing. Whitespace stripped. Practical cap a few MB; use blob_id for larger."New value: +"Base64-encoded **binary**, server-decoded (whitespace stripped). **Fallback only** — capped a few MB by the MCP transport. Prefer `blob_id` (POST /blob) for…"workflowworkspace5 fields changedInput schema / properties / action / enumPrevious value: -[
- "describe",
- "list",
- "details",
- "update",
- "delete",
- "archive",
- "unarchive",
- "members",
- "list-shares",
- "import-share",
- "available",
- "check-name",
- "create-note",
- "update-note",
- "read-note",
- "quickshare-get",
- "quickshare-delete",
- "quickshares-list",
- "metadata-template-create",
- "metadata-template-delete",
- "metadata-template-list",
- "metadata-template-details",
- "metadata-template-update",
- "metadata-template-clone",
- "metadata-template-preview-match",
- "metadata-template-suggest-fields",
- "metadata-template-assign",
- "metadata-template-unassign",
- "metadata-template-resolve",
- "metadata-template-assignments",
- "metadata-get",
- "metadata-set",
- "metadata-delete",
- "metadata-extract",
- "jobs-status",
- "metadata-list-files",
- "metadata-list-templates-in-use",
- "metadata-versions",
- "metadata-view-get",
- "metadata-view-save",
- "metadata-view-delete",
- "metadata-views-list",
- "metadata-view-export",
- "metadata-search",
- "enable-workflow",
- "disable-workflow",
- "enable-import",
- "disable-import",
- "settings-get"
-]New value: +[
+ "describe",
+ "list",
+ "details",
+ "update",
+ "delete",
+ "archive",
+ "unarchive",
+ "members",
+ "list-shares",
+ "import-share",
+ "available",
+ "check-name",
+ "create-note",
+ "update-note",
+ "read-note",
+ "quickshare-get",
+ "quickshare-delete",
+ "quickshares-list",
+ "metadata-template-create",
+ "metadata-template-delete",
+ "metadata-template-list",
+ "metadata-template-details",
+ "metadata-template-update",
+ "metadata-template-clone",
+ "metadata-template-preview-match",
+ "metadata-template-suggest-fields",
+ "metadata-template-assign",
+ "metadata-template-unassign",
+ "metadata-template-resolve",
+ "metadata-template-assignments",
+ "metadata-get",
+ "metadata-set",
+ "metadata-delete",
+ "metadata-extract",
+ "jobs-status",
+ "metadata-list-files",
+ "metadata-list-templates-in-use",
+ "metadata-versions",
+ "metadata-view-get",
+ "metadata-view-save",
+ "metadata-view-delete",
+ "metadata-views-list",
+ "metadata-view-export",
+ "metadata-search",
+ "enable-import",
+ "disable-import"
+]Input schema / properties / nl_summaries_daily_capRemoved value: -{
- "description": "Per-workspace daily ceiling on AI enrichment operations (0-100000, default 100). 0 disables enrichment without flipping nl_summaries_enabled.",
- "maximum": 100000,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / nl_summaries_enabledRemoved value: -{
- "description": "Master switch for AI summary enrichment of workflow obligations (default true). Setting 'true' requires the plan's content_ai feature. When 'false',…",
- "enum": [
- "true",
- "false"
- ],
- "type": "string"
-}Input schema / properties / workflow_approval_native_enabledRemoved value: -{
- "description": "Tri-state gate for the native workflow-review surface. 'disabled' (default): native review off. 'mvs': single-asset, member-only, single-mode. 'extended': full…",
- "enum": [
- "disabled",
- "mvs",
- "extended"
- ],
- "type": "string"
-}Input schema / properties / workflow_trigger_aliasesRemoved value: -{
- "description": "Verb->template alias map (JSON object), e.g. {\"redact\":\"mt_x\",\"summarize\":\"mt_y\"}. A comment beginning with an alias verb (@redact) resolves through this map…",
- "type": "string"
-}Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
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.
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.
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.
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.