MCP operations and limitations

See MCP connection for setup. The tables distinguish the first release from later additions. Use the connected server’s tools/list to check what is deployed. Token scopes, Room restrictions and current permissions still apply.

For Room operations, internal access requires both an internal account and MEMBER, ADMIN or OWNER membership in the target Room’s Workspace. An internal account invited as GUEST is treated as external there. Ordinary Room-member operations remain available, but internal-only Tasks and editing or deleting another person’s uploads do not. External editors can edit or delete their own uploads. File names are the file fields that MCP can change.

Later additions do not become available by granting more scopes or reconnecting. This guide will be updated when they are released. Existing AI, integration, Library and template operations are retained; their existing availability does not mean new arguments or operation stages described here have been released.

Check security status through MCP

With an all-room token carrying workspace:read, call get_my_profile with {"input":{"view":"security"}} to check your authenticator enrollment, whether MFA is required by any workspace you belong to, and your remaining recovery-code count. The requirement reflects all of your memberships, not only the token's workspace.

Current OWNER and ADMIN members of the token's workspace can call get_workspace_settings with {"view":"security"} to read the MFA and allowed-IP policy, enrollment counts, and summaries of up to 50 recent security events. Event details and credentials are not returned. canConfigureInApp describes environment readiness; it does not mean that you have completed verification or that your current IP is allowed. canEditInApp indicates OWNER permission. Actual changes still require verification in your signed-in screen.

Omitting view retains the existing profile and basic workspace-settings reads and their existing permissions. MCP does not receive authenticator secrets, verification codes, recovery codes themselves, your current browser IP, or your personal verification state.

Page content, history and visibility

Use list_pages with roomId and optional limit (20 by default, at most 100) to return an array of currently readable page headers. Pass pageId to get_page. Both require pages:read and current Workspace and Room membership. External members can read only room_visible pages; body edit permission does not restrict reading. An internal account with actual OWNER or ADMIN membership in the target Workspace can also use these basic readers through the ordinary preview access without joining the Room. In public Rooms, managers who have not joined still receive only externally visible pages. This exception does not apply to history, Word export, comments or changes.

Returned JSON is limited to 2 MiB in total. Oversized content is rejected without truncation; view it in the app. If content, visibility, membership or token access changes during the read, the result is withheld. Check access and fetch again.

Changes require pages:write, current membership in the token’s Workspace, and Room owner or editor access. External members can update content, title, icon and pin or restore history only on currently visible room_visible pages with all_members edit permission. Edit-permission and visibility settings retain internal-member restrictions. Use an all-Room token or one containing the target Room. Read the page's updatedAt with get_page, which also requires pages:read, and pass it as expectedUpdatedAt. Timestamps with Z or an explicit offset are compared as the same UTC instant.

• Content, title, icon and pin: update_page retains flat pageId, title and content arguments and requires expectedUpdatedAt and a YYYY-MM-DD:UUID idempotencyKey. Supply at least one of title (including an empty string), content, an emoji icon, or isPinned. isPinned is the desired state, not a toggle. Icons must be emoji within 32 UTF8 bytes. Content is a block array or an object with _v: 2 and blocks. Each commentMarks range needs integer from and to values (0 ≤ from < to) and a nonempty threadId. Content updates use the existing history, block and mention processing.
• Editing permission: Pass roomId, pageId, expectedUpdatedAt, editPermission (internal_only or all_members) and a dated idempotencyKey to prepare_update_page. Review the current and target permissions. Send the same pageId, expectedUpdatedAt, editPermission, key and returned four-field confirmation as flat arguments to update_page. Omit roomId on execution; the server resolves it. Confirmation expires after ten minutes. Permission changes cannot be combined with other fields.
• Restore content: Pass roomId, pageId, historyId, expectedUpdatedAt and idempotencyKey to prepare_restore_page_history. After reviewing the preview, pass the same values and a confirmation containing the returned operationId, payloadHash, approverUserId and expiresAt to restore_page_history. Only content is restored; the current title, hierarchy and visibility are preserved.
• Visibility: Pass roomId, pageId, targetVisibility, expectedUpdatedAt and idempotencyKey to prepare_set_page_subtree_visibility, then the same values and confirmation to set_page_subtree_visibility. internal_only also narrows descendants. room_visible publishes only the selected root and does not republish its descendants.

Restore and visibility confirmations expire after ten minutes and are confirmed by the token's creator. If history or descendant pages change after preparation, read the current state and prepare with a new operation key.

Input JSON for Page changes is limited to 256 KiB. During preparation for a change, stored pages and selected history snapshots have a 2 MiB limit per item. Hierarchy and visibility operations inspect the Room and reject more than 1,000 pages or 8 MiB in total. For uncertain results, inspect get_mcp_operation, the current page and its history instead of automatically resending. Operation receipts remain available after Page deletion, but do not establish the page's current content.

History and Word export

export_page_docx accepts input.roomId and pageId. Current Room members, including external viewers, can use it with pages:read for pages they can currently view. Internal-only pages keep their visibility restrictions, and external accounts need the Room to allow downloads. It reuses native Word export and returns base64 for up to 500 blocks, 1MiB of input and 2MiB of output.

For history, pass input.roomId and pageId to list_page_history. It returns summaries without content, 20 at a time by default and up to 100. Pass the returned nextCursor as input.cursor for the next batch. To read a selected version, call get_page_history with the same Room and Page plus historyId, starting at offset: 0. Join the 4000-character fragments until nextOffset is null, then parse them as JSON. Current Room membership, Page visibility and pages:read apply, including for external viewers. Deleted history cannot be retrieved.

Page comment operations

Use pages:read for inspection and pages:write for changes. Current membership in the token’s Workspace and target Room is required, including internal and external members, subject to current page visibility. Comment permissions are independent of page body edit permission. Posting, replying, editing, resolving and deleting require Room owner or editor access. Changing reactions also requires editing access. Viewers can only read.

Lists and ordinary changes use input; changes also require a YYYY-MM-DD:UUID idempotencyKey outside it. Every input includes roomId and pageId.

• list_page_comment_threads: default 20, maximum 50. Returns thread IDs, state, observed timestamps, first active comment and reply count. Reply count excludes the initial post. Metadata over 128KiB becomes null with metadataTruncated: true.
• list_page_comment_thread_comments: add threadId; read content in pages of 20 by default, up to 50.
• list_page_comment_reactions: add threadId and commentId; default and maximum 100. General user profiles are not returned.
• Every list returns { items, nextCursor }. Pass nextCursor as cursor with the same parent fields. Reads over 2MiB per row or batch fail; reduce limit for a large batch, or use the app for a single oversized row.
• create_page_comment_thread: supply JSON-array body and optional metadata. reply_to_page_comment_thread also needs threadId and expectedThreadUpdatedAt. Body and metadata JSON together are limited to 50KiB in UTF8. New posts and replies use mention notifications.
• update_page_comment: supply threadId, commentId, expectedCommentUpdatedAt and body. Only the author can edit, with Room editing access. Edits do not send a new mention notification.
• set_page_comment_thread_resolved: supply threadId, expectedThreadUpdatedAt and explicit resolved. true resolves, false reopens, and the same target is a no-op.
• set_my_page_comment_reaction: supply threadId, commentId, expectedCommentUpdatedAt, emoji and added. Set added: true to add or false to remove. Existing emoji validation and a 32-byte UTF8 limit apply. This operation affects only your own reaction.

Read the observed version from each list’s updatedAt. Timestamps are compared as UTC instants. A new thread requires no existing version.

Deletion uses flat arguments. Pass roomId, pageId, threadId, commentId, expectedCommentUpdatedAt and idempotencyKey to prepare_delete_page_comment, then the same values plus returned confirmation to delete_page_comment. For a thread, use prepare_delete_page_comment_thread and delete_page_comment_thread, replacing commentId and expectedCommentUpdatedAt with expectedThreadUpdatedAt.

Confirmation lasts 10 minutes. Authors and Room owners may delete comments; Room owners or the author of the currently first non-deleted comment may delete a thread. Both require Room editing access. If content, replies, parents or permissions change after preparation, prepare again with a new key. Use the app for threads over 1,000 comments or 2MiB of confirmation headers, or stored rows exceeding the mutation-response budget. Reconcile uncertain outcomes with get_mcp_operation and current lists instead of automatically resending. See Page comments.

Available operations

MCP additions not included in the first release: get_file_analysis_statuses, get_gallery_template_preview, list_workspace_room_templates. These additions are planned for a later release. Existing screen operations remain available.

A settings tool does not cover every setting in the app. Workspace updates cover the name and logo URL. Member invitation and removal operate on Room membership.

Later MCP additions (not included in the first release)

get_workspace_logo_viewer_url returns a viewer URL for the current Workspace’s uploaded logo. A signed_url is valid for 300 seconds and can be opened by anyone holding it until expiry. Development app_session_required URLs need an app login and have no guaranteed expiry. External URLs and legacy noncanonical storage keys are not supported.

list_files returns an array of files, with 20 per request by default and a maximum of 100. Results use creation time descending, then ID descending for ties. Pass the last file ID as cursor to continue; an empty array ends the list. tag filters by an exact match. get_file accepts a file ID. Both recheck your current Room membership and file availability. fieldsTruncated means some strings were shortened. hasInvalidPageBinding means the related page is inconsistent, so pageId is null.

get_file_analysis_statuses returns the current analysis status of up to 200 requested files in a Room. Unavailable IDs are listed in unavailableFileIds. It does not start or retry analysis, or return extracted page labels or text.

list_workspace_room_templates returns up to 100 templates in your current workspace. Continue with meta.cursor; fieldsTruncated marks shortened display values. To inspect an individual public template, pass the Room ID from its browser preview URL to get_gallery_template_preview.

These three own-support operations require a valid existing MCP token and your current membership in its Workspace. Both internal and external account types are supported. Use an all-Room token with workspace:read for reads and workspace:write for read-marker changes. This does not grant token issuance rights to every external user. Your own issues remain account-wide across Workspaces.

list_my_support_issues returns your issue summaries, latest replies and unread counts, up to 50 per page. get_my_support_issue returns the description and up to 50 latest replies; use meta.cursor for older history. Replies within each page are in chronological order. These tools read your personal account across workspaces without marking messages as read. They do not return internal notes, staff IDs or deleted message text.

To mark replies as read, call mark_my_support_issue_read with the observed lastSeenMessageId and a dated idempotencyKey. It advances to the actual message time without moving an existing marker backwards. An unavailable reply returns read:false without changing the marker. It does not send a reply or notification. For an unknown outcome, do not resubmit. Inspect get_mcp_operation with workspace:read; it returns only your issue ID and current read time. Current state is not proof that this operation succeeded.

Later analytics MCP additions (not included in the first release)

Upload a file

Active Room owners and editors who can upload from the Files screen can use this flow, including external members. Initiation and confirmation require files:write; status inspection requires files:read. Only your own root Room uploads are supported; page targets are not accepted.

1. Call upload_file with roomId, filename, contentType, the exact byte count in size, and a dated idempotencyKey. The screen limit is 100MiB; existing plan and safety limits also apply.
2. Have your client PUT the selected local file to uploadUrl, using the declared Content-Type and exact byte count. If the URL is null, upload from your own Room Files screen.
3. Call confirm_file_upload with roomId, fileId, the returned fileVersion as expectedFileVersion, and a dated idempotencyKey. Another person cannot confirm your upload.
4. Call get_file_upload_status with roomId and fileId to inspect your ingestion, scan and source-capture status. SAFE is still preparing until sourceRevisionCaptureStatus is READY.

URL issuance, PUT, confirmation, safety checks and completed ingestion are separate stages. An issued PUT URL grants upload capability until its existing expiry of 15 minutes; revoking the MCP token does not immediately invalidate that URL. Do not share it.

Reusing an upload key neither reissues a URL nor creates another File. After an unknown outcome, inspect get_mcp_operation without automatic replay. A confirmed File row alone does not prove the whole operation, including accounting, succeeded. If a scan wake notification fails after confirmation, the existing durable scan request remains; do not reconfirm. New library uploads use upload_library_asset and remain subject to format, size and scanning limits.

Room links and file links

create_shared_link grants access to a Room. It does not create selected-file share links or material-set links.

Operations that still require the app

Start audio capture, update Smart Intake, and change plans or payment methods in their app screens. The new recording-session MCP flow is planned for a later release. Currently, create the session in the meeting screen, choose the audio source and start capture there yourself.

Microphone and screen-sharing permissions, OAuth consent and payment confirmation require the relevant person to use those screens.

Check your actions and tasks across Rooms through MCP

list_my_actions groups your assigned, incomplete top-level tasks into overdue, today, tomorrow, the next seven days, and no due date, using your saved time zone. Set input.kind to unassigned_owned to inspect unassigned tasks in Rooms you own, including all due dates. Page these two lists separately.

list_my_cross_room_tasks returns incomplete top-level tasks in Rooms you currently belong to, newest first. Both tools are limited to the connected Workspace and require tasks:read with an all-Room token. A token restricted to specific Rooms cannot use these Workspace-wide lists.

Start with {"input":{"limit":20}}. The maximum is 100. When hasMore is true, pass nextCursor as input.cursor with the same filters. Assigned tasks due outside the seven-day horizon count toward excludedLaterCount, so empty buckets can still have another page. Use hasMore to decide when to stop. If data, access, or the cursor changes, restart without a cursor.

These lists omit descriptions and assignee profiles. Titles and Room names are limited to 500 characters and priority to 100; check the truncation flags. Use the returned Room and task IDs with get_task for details. See Task management for the screen workflow.

A tool is missing or access is denied

Ask an administrator to check required scopes, Room restrictions, expiration and revocation. After permission changes, refresh the connected AI tool’s tool list or reconnect. Losing Room membership or edit permission can cause previously available operations to be rejected.

Reading Tasks, categories, labels, dependencies and comments through MCP requires active membership in that Room. Invited or requested membership does not grant access.

Check before changing data

For update_task and assign_user_to_task, pass the observed Task updatedAt as expectedTaskUpdatedAt. Active editors and owners, including external members, can change Tasks visible to them. Use null to clear descriptions, priorities, start dates or due dates. Changing a parent requires both parentTaskId and expectedParentTaskUpdatedAt; use parentTaskId: null to detach it. Only one subtask level is supported. Assignees must be active Room members; an empty array clears all assignees. Internal-only Tasks can only be assigned to internal members.

An edit containing visibility requires prepare_update_task, followed by update_task with the same changes and returned confirmation. Include simultaneous title or other edits in that confirmation. Only the caller can approve it, within 10 minutes; changed versions or payloads require new preparation. Delete through prepare_delete_task, then delete_task. Deleting a parent also deletes its subtasks. Remove existing dependencies first.

To create a dependency, provide both endpoint versions as expectedPredecessorUpdatedAt and expectedSuccessorUpdatedAt. Both Tasks must be visible to you and belong to the same Room. Duplicate and cyclic dependencies are rejected. MCP creation stops when the Room has more than 1,000 dependencies. Use a dated idempotencyKey for these changes. If an outcome is uncertain, inspect get_mcp_operation and current Task or dependency state before any further action; do not replay the request.

Operations beginning with prepare_ return the target and time-limited confirmation data. Review them and pass the confirmation to the matching execution tool. Changes to the target or your permissions can require a fresh confirmation.

Label updates require the values observed in the directory. Pass the observed categoryVersion as expectedCategoryVersion for category updates and reordering, and taskUpdatedAt as expectedTaskUpdatedAt when replacing task labels. An empty label array removes all labels from that task. reorder_room_task_categories only reorders the categories supplied; include every category to change the full Room order. delete_task_label also deletes labels in use, matching the screen. Assignments to that label are removed in sequence, preserving other labels and assignees, before the label is deleted.

Check each tool schema and meta for page limits and continuation. fieldsTruncated marks shortened display values. list_task_categories and list_task_labels are compatibility views of the first 200 entries. Use the cursors in list_room_task_categories and list_room_task_labels to continue through all entries.

Invoice inspection returns the latest 12 invoices. Your language preference is shared across your account; use the language switcher to change the display language in your current browser.

Prepare category deletion with prepare_delete_task_category, then pass its confirmation to delete_task_category. Tasks move to the first remaining category in the same Room, matching the screen. Keep another category before deleting this one; no destination input is needed. Tasks move sequentially, so a stopped operation may have moved only some tasks. Inspect get_mcp_operation and list_tasks filtered by the source and destination categories before preparing another operation; do not replay the interrupted request.

create_task_comment is available to active Room members, including viewers. Supply taskId, content and idempotencyKey. Content is limited to 5,000 UTF-16 code units before trimming; many emoji use two units. Whitespace-only comments are rejected. Duplicate requests return operation status without adding a comment. Reconcile uncertain results with get_mcp_operation and list_task_comments.

To delete a comment, inspect the target and the first 500 text characters with prepare_delete_task_comment, then pass the same commentId and idempotencyKey plus the returned confirmation to delete_task_comment. Confirmation lasts 10 minutes. You can only delete your own comments, including when you are a viewer. If the text, target or permissions change after preparation, prepare again with a new key.

list_task_comments returns an array ordered by creation time and ID ascending. The default is 50 comments, up to 200. Pass the last comment ID as cursor to continue; an empty array ends the list. Oversized legacy text is marked with contentTruncated; unavailable authors are marked with hasUnavailableAuthor. Email addresses are not returned. If the response exceeds the size limit, request fewer comments with a smaller limit.

To delete a dependency, inspect its two Task IDs with prepare_delete_task_dependency, then pass the same dependencyId and idempotencyKey plus the returned confirmation to delete_task_dependency. Confirmation lasts 10 minutes and requires active Room editor or owner membership. Changes to either endpoint or its version require preparation with a new key. Repeated requests after deletion or an uncertain outcome do not repeat the delete.

list_task_dependencies returns an array of dependencies whose Tasks are both in the same Room. It defaults to 100 entries, up to 200, ordered by ID ascending. Pass the last dependency ID as cursor to continue; an empty array ends the list.

Pass a parent Task ID as parentTaskId to list_tasks to list its direct children in the same Room. An unavailable parent is rejected even if no children match. The default is 20 Tasks, with a maximum of 100; continue with the returned meta.cursor.

list_tasks returns summaries and counts. get_task includes the first 8,000 text characters and the first 100 assignees and labels. When truncation flags are set, continue with get_task_text for text or titles, list_task_assignees for assignees, and list_task_labels_for_task for labels. Text offset and nextOffset count Unicode codepoints. Pass the updatedAt observed in get_task as expectedTaskUpdatedAt to keep text chunks on the same Task version.

An outcome is uncertain

MCP additions not included in the first release: disable_workspace_wide_channel_link, dismiss_deal_health_alert, get_content_analytics_config, get_deal_health_config, get_deal_health_summary, get_file_content_score, get_my_workspace_crm_connections, get_workspace_crm_sync_settings, list_content_rankings, list_deal_health_alerts, list_file_page_analytics, list_workspace_channel_connections, list_workspace_wide_channel_links, prepare_disable_workspace_wide_channel_link, prepare_dismiss_deal_health_alert, prepare_reset_content_analytics_config, prepare_reset_deal_health_config, prepare_resolve_content_analytics_config, prepare_resolve_deal_health_config, prepare_update_content_analytics_config, prepare_update_deal_health_config, prepare_update_workspace_channel_settings, prepare_update_workspace_crm_sync_settings, reset_content_analytics_config, reset_deal_health_config, resolve_content_analytics_config, resolve_deal_health_config, update_content_analytics_config, update_deal_health_config, update_workspace_channel_settings, update_workspace_crm_sync_settings. These additions are planned for a later release. Existing screen operations remain available.

For writes whose published schema supports it, supply an idempotencyKey. Use YYYY-MM-DD:UUID, with today’s UTC date or a UTC date less than 90 days old. Do not reuse one operation’s key with different content. Use get_mcp_operation and the returned operation identity to reconcile its state.

Do not blindly resend a write after a lost response, an in-progress result or outcome_unknown. Check whether it completed before proceeding. Reconciliation does not make every existing write safe to retry.

Deleting a label in use is limited to 1,000 tasks; 100 labels and attachments per task; 20,000 assignees, labels and attachments each in total; and a 2 MiB data budget. Some assignments may already be removed if the operation stops. For outcome_unknown, do not automatically resend. Check get_mcp_operation and the current task and label lists.

list_workspace_api_keys requires current Workspace owner or admin membership. list_workspace_mcp_tokens also requires current Workspace owner or admin membership. Both require an MCP token covering all Rooms. Pages default to 20 items, up to 100; pass meta.cursor as the next input.cursor. Secret keys and hashes are never returned. Check truncation and invalid-value flags. A token’s displayed isActive value does not grant execution authority. Fetch again if access or the records change during the read.

get_workspace_crm_sync_settings takes provider: hubspot, salesforce, or kintone. It returns the current Workspace’s enabled synchronization events, mode, and interval. Current internal membership and a token covering all Rooms are required. If no settings are saved, it returns defaults without saving or running a synchronization. Fetch again if settings or access change during the read.

Current Workspace owners or admins can change allowed domains with a token covering all Rooms. Inspect the target with prepare_add_workspace_allowed_domain or prepare_remove_workspace_allowed_domain, then pass the same target and idempotencyKey with the returned confirmation to the matching add_workspace_allowed_domain or remove_workspace_allowed_domain. Confirmation lasts 10 minutes. For an uncertain outcome, reconcile with get_mcp_operation and list_workspace_allowed_domains; do not automatically resend. These operations do not invite members or change memberships.

get_my_workspace_crm_connections returns the current Workspace and your personal connection metadata for HubSpot, Salesforce, and Kintone. Current internal membership and a token covering all Rooms are required. Personal connections are shared across your own account. connected means a connection record is saved; it does not guarantee that the provider is usable. Check fieldsTruncated and hasInvalidConnectedBy. The operation does not retrieve or decrypt credentials or contact providers.

Current Workspace owners or admins can update CRM synchronization settings with an all-Room token carrying workspace:write. Pass provider, the fields to change, and idempotencyKey to prepare_update_workspace_crm_sync_settings and review the current and proposed settings. Save with update_workspace_crm_sync_settings using the same content and the returned confirmation, valid for 10 minutes. Omitted fields keep their values; enabledEvents: [] clears the enabled events. Intervals range from 15 to 1,440 minutes. Saving does not run an immediate synchronization. Prepare again if settings or access change. For an uncertain outcome, reconcile with get_mcp_operation and get_workspace_crm_sync_settings; do not automatically resend.

list_workspace_channel_connections returns up to two Slack and LINE connection records for the current Workspace. Current internal membership and an all-Room token carrying workspace:read are required. It does not retrieve or decrypt credentials or contact providers. Check fieldsTruncated for shortened display values. A default Room ID appears only when you can currently access that Room; an unavailable target is shown as defaultRoomId: null with hasUnavailableDefaultRoom: true. The saved status is not a provider health check. Fetch again if settings or access change during the read.

get_workspace_branding returns the current branding metadata. Check fieldsTruncated for shortened display values. An oversized external logo URL is omitted rather than cut into a broken link: logoUrl is null and hasUnavailableLogoUrl is true. A /api/v1/workspaces/.../logo URL requires an app session. Use get_workspace_logo_viewer_url to inspect the viewer URL, delivery requirements, and expiry. Signed URLs last 300 seconds; local delivery requires an app session. Fetch again if settings or access change during the read.

list_workspace_wide_channel_links lists channels configured to accept questions for all Rooms. It requires the current Workspace OWNER or ADMIN and a workspace:read token covering all Rooms; membership of the primary Room is not required. Like the existing app view, it includes both Slack and LINE. The default page size is 20 and the maximum is 100. Pass the object in meta.nextCursor as the next input.cursor. Identify a channel by the combination of channelType, externalTeamId and externalChannelId. An unavailable primary Room is represented by roomId: null and hasUnavailableRoom: true. This operation does not check provider health or change settings. Restart from the first page if settings or permissions change during retrieval, or the cursor becomes unavailable.

To turn off a Workspace-wide channel setting, call prepare_disable_workspace_wide_channel_link with channelType, externalTeamId, externalChannelId and idempotencyKey. It requires the current Workspace OWNER or ADMIN and a workspace:write token covering all Rooms; membership of the primary Room is not required. Review the target, then pass the same identifiers and key with the returned confirmation to disable_workspace_wide_channel_link within 10 minutes. Only the Workspace-wide flag is turned off: explicit Room links, the primary and default Rooms, and the external channel remain. An unavailable primary Room is shown as primaryRoomId: null and hasUnavailableRoom: true. For an uncertain outcome, avoid automatic retries and reconcile through get_mcp_operation and list_workspace_wide_channel_links. Absence from the list alone cannot distinguish a disabled setting from a deleted setting.

To change connection settings, call prepare_update_workspace_channel_settings with connectionId and the settings to change. Review the target, then pass the same content and idempotencyKey, plus the returned confirmation within 10 minutes, to update_workspace_channel_settings. The current Workspace OWNER or ADMIN and a workspace:write token covering all Rooms are required. autoRegisterExternalUsers applies to Slack and LINE; welcomeMessage and defaultRoomId apply to LINE. Distinguish false, an empty string, null (clear), and omission (preserve). Welcome text is limited to 5,000 UTF-16 units; emoji can consume multiple units. A newly selected default Room must be readable in the same Workspace; Room membership is not required. An existing unavailable default is shown as null with hasUnavailableDefaultRoom. Credentials are not returned, and this operation does not contact the provider to check health or send messages. Reconcile uncertain outcomes through get_mcp_operation and list_workspace_channel_connections without automatic retries.

For allowed-domain additions and removals, CRM sync settings, disabling workspace-wide channel links, and channel connection settings, a token with only workspace:write can use get_mcp_operation to inspect its own action status. This requires a current Workspace owner or admin and an all-Room token. Status inspection does not read settings or repeat the action. The suggested directory and settings tools separately require workspace:read. An action record can remain available after its connection is deleted; the record alone does not establish current settings or prove the mutation succeeded.

To cancel an invitation, pass invitationId and idempotencyKey to prepare_cancel_workspace_invitation and check the email address, role and expiry. Submit the same details with its confirmation to cancel_workspace_invitation within 10 minutes. This requires a current Workspace owner or admin and an all-Room token with workspace:write. Only a saved PENDING invitation changes to EXPIRED; no invitation email or notification is sent. An elapsed expiry does not prevent cancellation while the saved status remains PENDING. Concurrent acceptance preserves the first committed state, and stale acceptance cannot add a member after cancellation. For an unknown outcome, do not resend: check get_mcp_operation and, with workspace:read, inspect list_workspace_invitations.

To revoke an API key, pass apiKeyId and idempotencyKey to prepare_revoke_workspace_api_key, review the target, and send the same values with the returned confirmation to revoke_workspace_api_key within 10 minutes. You must be a current Workspace owner or administrator using a workspace:write token covering all Rooms. An unrevoked API key becomes REVOKED, including a key past its expiry date or with saved status EXPIRED. This operation does not revoke MCP tokens. It never returns the key or its hash. An invalid saved prefix is shown as keyPrefix: null with hasInvalidPrefix: true. If the outcome is unknown, do not resend: inspect your operation with get_mcp_operation, and use list_workspace_api_keys for reconciliation if you also have workspace:read.

To revoke an MCP token, pass targetTokenId and idempotencyKey to prepare_revoke_workspace_mcp_token, review the target, then send the same values with the returned confirmation to revoke_workspace_mcp_token within 10 minutes. You must be a current Workspace owner or administrator using a workspace:write token covering all Rooms. Unrevoked tokens remain eligible after expiry. This does not permanently delete tokens. The preview never returns the token, its hash or its Room IDs; it shows only the Room count. Invalid prefixes appear as null with hasInvalidPrefix: true. When isCallerToken: true, you are revoking the token making this request. After saving, normal authorization rejects further access: the outcome is reported as unknown, and that token can no longer operate or read its receipt. Do not resend; verify revocation in the signed-in settings screen. Another token cannot read this token-bound receipt. For an unknown outcome when revoking a different target, inspect your own receipt with get_mcp_operation, and reconcile using list_workspace_mcp_tokens if you also have workspace:read.

To permanently delete a revoked or expired MCP token, pass targetTokenId and idempotencyKey to prepare_delete_workspace_mcp_token and review the target and affected history counts. Send the same values and the returned confirmation to delete_workspace_mcp_token within 10 minutes. You must be a current Workspace owner or administrator using a workspace:write token covering all Rooms. Active tokens cannot be deleted, and the operation does not revoke them automatically. Permanent deletion also removes the target token’s audit logs and operation receipts and cannot be undone. Review auditEntryCount and operationReceiptCount: either count above 1000, or inconsistent Workspace ownership in those histories, causes rejection before saving. History content, token material, hashes and Room IDs are never returned. This deletion’s own receipt belongs to the separate token making the request and remains available through get_mcp_operation after target deletion. If the outcome is unknown, do not resend: inspect your receipt and reconcile with list_workspace_mcp_tokens if you also have workspace:read. Absence from the list alone does not prove that this operation succeeded.

To update branding, send the changed settings and idempotencyKey to prepare_update_workspace_branding, review the current and proposed values, then send the same settings with the returned confirmation to update_workspace_branding within 10 minutes. You must be a current Workspace owner or administrator using a workspace:write token covering all Rooms. Supported settings are accentColor, paletteId, sidebarColor, brandSecondaryColor, brandFontFamily, and slideThemePreset. Omitted settings stay unchanged. Use null to clear colors, the palette, or the slide theme; sidebarColor: "" also clears the sidebar color. Choose one of the four fonts shown in the app: Noto Sans JP, BIZ UDPGothic, Helvetica Neue, or Arial. Change the logo with the separate upload_workspace_logo and delete_workspace_logo operations. A viewer with logoRequiresApplicationSession: true requires an app session. Previews and results reflect the existing settings process, including lowercase sidebar colors. Prepare again if settings or access change. If the outcome is unknown, do not resend: inspect your operation with get_mcp_operation, and use get_workspace_branding to reconcile current settings if you also have workspace:read.

For Workspace general, recording, and language settings, send the changes and idempotencyKey to prepare_update_workspace_policy_settings, review the current and proposed values, then send the same changes with the returned confirmation to update_workspace_policy_settings within 10 minutes. You must be a current owner or administrator using a workspace:write token covering all Rooms. The 10 settings cover name, country, organization name, recording enabled, consent required, transcript retention days, audio retry buffer hours, monthly recording minute limit, default language, and time zone. Omitted fields stay unchanged. Use null to clear country, organization name, transcript retention, or monthly limit. Set the language to ja or en and the time zone to a valid IANA name such as Asia/Tokyo; these two fields do not accept null. Retention days and monthly minutes accept 1–36500; audio retry buffer accepts 1–720 hours. Name and audio retry buffer do not accept null. Brand colors, logos, and allowed domains use separate operations. If the outcome is unknown, do not resend: use get_mcp_operation, and reconcile current settings with get_workspace_policy_settings if you also have workspace:read.

list_workspace_audit_logs is available to current Workspace owners and administrators on a plan that includes audit logs, using a workspace:read token covering all Rooms. Filter by action, resourceType, actorId, from, and to. limit defaults to 20 and allows up to 100; continue with the same filters and meta.cursor. Timestamp ties use a stable ID order. This returns customer business audit history, not development execution traces. Metadata that may contain content or secrets is not fetched: hasMetadata and metadataOmitted: true indicate omission. Noncanonical IDs, unknown labels, and invalid IP addresses are omitted with flags. Use the app's audit log screen for detailed metadata. Fetch again if history, plan, or access changes during the read.

get_content_analytics_config reads the current Workspace’s content analytics settings for a current internal Workspace owner or administrator with an all-Room workspace:read token. Saved settings return configured: true with their ID and timestamps. If settings have not been saved, it returns the existing defaults with configured: false and null ID and timestamps. Reading does not create, update or reset settings. Fetch again if settings or access change during the request.

Initializing, updating or resetting content analytics settings requires the current Workspace owner or administrator and an all-Room workspace:write token. Use prepare_resolve_content_analytics_config then resolve_content_analytics_config to initialize, prepare_update_content_analytics_config then update_content_analytics_config for partial updates, or prepare_reset_content_analytics_config then reset_content_analytics_config to restore defaults. Preparation does not save settings: review the current and proposed values, then execute with the same settings, idempotencyKey and confirmation within ten minutes. Initialization saves defaults only if settings are absent; existing settings stay unchanged. Updates preserve omitted fields, and the five scoring weights must total 100. Reset restores all nine defaults. Existing IDs and creation timestamps stay unchanged. Prepare again if settings or access change. For an unknown outcome, do not resend: inspect your operation with get_mcp_operation and, with workspace:read, compare current settings using get_content_analytics_config.

get_deal_health_config reads deal health weights, thresholds and notification settings. It requires a current internal Workspace owner or administrator and an all-Room workspace:read token. Saved settings return configured: true with their ID and timestamps; absent settings return the existing defaults with configured: false and null ID and timestamps. Reading does not save or reset settings, send notifications or calculate scores. Up to 100 saved recipient IDs in UUID format can be read. Oversized or invalid settings are rejected without automatic repair. Fetch again if settings or access change during the request.

Use prepare_resolve_deal_health_config then resolve_deal_health_config to initialize deal health settings, prepare_update_deal_health_config then update_deal_health_config for partial updates, or prepare_reset_deal_health_config then reset_deal_health_config to restore defaults. The current Workspace owner or administrator and an all-Room workspace:write token are required. Preparation does not save: review the current and proposed settings, then execute with the same settings, idempotencyKey and confirmation within ten minutes. Initialization saves defaults only when absent; existing settings stay unchanged. Updates preserve omitted fields. The five weights must total 100, with atRiskThreshold < onTrackThreshold < healthyThreshold. Up to 100 recipient UUIDs may be supplied, each identifying a current active internal member of this Workspace. Duplicates are preserved. Updates retaining departed recipients are rejected; clear or replace those recipients first. Reset restores all sixteen defaults and clears recipients. Existing IDs and creation timestamps remain unchanged. These operations do not send notifications or calculate scores. For an unknown outcome, do not resend: inspect your own history with get_mcp_operation and, with workspace:read, compare settings using get_deal_health_config.

The existing get_workspace_settings tool keeps its original {} arguments for reading basic settings. It requires a current internal Workspace member and an all-Room workspace:read token. Long names, icons, country and brand values are bounded, with truncation reported in fieldsTruncated. Stored logo keys are not returned. A URL marked logoRequiresApplicationSession: true requires an application login to display. An oversized external logo URL returns null with hasUnavailableLogoUrl: true. Fetch again if settings or access change during the request.

get_deal_health_summary returns the latest saved health score distribution and non-dismissed alert count for Rooms you can currently read. It requires a current internal Workspace member and an all-Room workspace:read token. Workspace owners and administrators can read without joining each Room; other members need active or invited Room membership. Rooms without a saved score are excluded from the distribution, but their alerts still count. Readable archived Rooms and templates are included. This does not calculate scores or send notifications. Fetch again if access or counts change during the request.

list_deal_health_alerts reads alerts in Rooms you can currently access, with 20 items by default and at most 100 per page. It requires an all-Room workspace:read token and current internal Workspace membership. Filter by roomId, severity or isDismissed, then pass meta.cursor to continue. meta.hasMore: false identifies the last page, which may still have a cursor. Remove the cursor when changing filters. Unreadable Rooms and unavailable cursors are rejected. Contact IDs are redacted, unread file IDs become a count, and internal evidence is not returned. Invalid dates or numeric evidence and oversized records are rejected. Lower limit if the overall page exceeds its budget. Fetch again if content or access changes during the request. Reading does not dismiss alerts, propose actions or send notifications.

To dismiss one alert, pass its alertId and a dated idempotencyKey to prepare_dismiss_deal_health_alert. Review the proposed change, then send the same input and key with the returned confirmation to dismiss_deal_health_alert within ten minutes. Current internal Workspace membership, an all-Room workspace:write token, access to the target Room and a plan that includes deal health are required. Already-dismissed records retain their original actor and time. After an unknown outcome, inspect with get_mcp_operation using the same token instead of automatically resending. Operation lookup also accepts a write-only token; reading the alert directory separately requires workspace:read.

get_file_content_score takes fileId and returns the latest stored content score, or score: null when none exists. list_file_page_analytics returns the same file’s historical page analytics. Both require current internal Workspace membership, an all-Room workspace:read token and access to the file’s Room. For page analytics, limit defaults to 20 and is at most 100. If more records remain, pass meta.cursor with the same file in the next request; meta.hasMore: false and cursor: null mark the end. Multiple records for one page can represent different calculation times. Page analytics can exist without a stored score. Invalid or oversized records and unavailable cursors are rejected. If content or access changes during retrieval, restart without a cursor. These reads do not recalculate, save or send notifications.

list_content_rankings ranks files in Rooms you can currently read using each file’s latest stored score within the Workspace. Files without a score are omitted. Results also include actual views by external users. You need current internal Workspace membership, an all-Room workspace:read token and access to the target Rooms. limit defaults to 20 and is at most 100. Continue with meta.cursor and stop when meta.hasMore is false; the final page can still have a cursor. Cursors for older scores or files you can no longer read are rejected. If content, view counts or access changes, restart without a cursor. Lower limit if the complete page exceeds the output budget. This operation does not recalculate, save or send notifications.

Create and reorder tasks with MCP

Public create_task keeps existing fields such as roomId and title at the top level. A dated idempotencyKey (YYYY-MM-DD:UUID) is now required. To create a subtask, supply a parent in the same Room using parentTaskId together with its previously read updatedAt as expectedParentTaskUpdatedAt. Subtasks are limited to one level. If you omit the category, creation uses the parent's category, then the first Room category, or creates “未分類” if the Room has none.

For reorder_room_tasks, pass roomId, categoryId, and orderedTasks inside input, with a dated idempotencyKey at the top level. Each ordered entry contains taskId and expectedTaskUpdatedAt. Select 1–1000 unique tasks. Only selected tasks receive zero-based positions in the supplied order; unselected positions remain unchanged. Include every task to reorder the whole category. Stale versions and requests exceeding the aggregate budget are rejected before dispatch.

Both operations require tasks:write, current internal Workspace membership, and Room owner or editor access. Use an all-Room token or a token containing the target Room. Creation accepts up to 255 title characters and 10000 description characters; the entire request must fit within 256 KiB. Reordering also requires tasks and related data to fit within a 2 MiB aggregate budget. For outcome_unknown or dispatched, inspect get_mcp_operation and the task list or detail before taking further action. Do not automatically retry or create a replacement with a new key. A write-only token can inspect operation status, while task lists and details separately require tasks:read.

Activity suggestions through MCP

MCP additions not included in the first release: get_activity_suggested_actions, link_activity_suggested_action_task. These additions are planned for a later release. Existing screen operations remain available.

To associate a suggestion with an existing task, call get_activity_suggested_actions with input.roomId and activityId. Pass the returned index as input.actionIndex and metadataVersion as expectedActivityVersion to link_activity_suggested_action_task. Also supply a taskId from the same Room and its updatedAt from get_task as expectedTaskUpdatedAt, with a dated idempotencyKey at the top level. Linking does not create a task. Use create_task first when you need a new task, and confirm its result. Version timestamps expressed with Z or an explicit offset are compared by the same UTC instant.

The action reader supports up to 101 indexed suggestions, including entries beyond the first five-item preview. It returns up to 500 text characters with a truncation flag, a valid same-Room linked task ID, creation time, and the version. Bodies and other metadata are omitted. Source metadata over 256 KiB, malformed collections, and stale versions are rejected. Reads require tasks:read; creation and linking require tasks:write. Include both scopes when combining these operations. Current internal Workspace and Room members can read, while writes require Room owner or editor access. Use an all-Room token or one containing the target Room. Both tools place their arguments inside input, with mutation idempotencyKey at the top level.

Register, delete, and request previews for library assets through MCP

MCP additions not included in the first release: delete_library_asset, get_library_asset_presentation_preview, prepare_delete_library_asset, register_room_file_in_library, request_library_presentation_preview. These additions are planned for a later release. Existing screen operations remain available.

Use list_library_assets to obtain each existing asset's id, version, and fileVersion. version describes the library asset; fileVersion describes its file. Pass these as expectedAssetVersion and expectedFileVersion for deletion or preview requests. Read the current values again after a change instead of guessing a version.

Writes require files:write, an all-Room token, and current active internal Workspace membership. Copying also requires current membership in the source Room; viewers may copy. Use YYYY-MM-DD:UUID for idempotencyKey.

• Register from a Room: pass input: { roomId, fileId, expectedFileVersion, tags, folderId } and the operation key to register_room_file_in_library. Read the source file's versionNo from list_files. Optional tags allows up to 20 tags of 50 characters each. Omit folderId or set it to null for the top level. The source must be downloadable and ready. Copies are limited to 32MiB, or a lower plan limit. Wait for the new copy's scan after registration. If folderApplied is false, the asset remains at the top level: inspect its location instead of registering it again.
• Delete: pass assetId, both observed versions, and the operation key as flat fields to prepare_delete_library_asset. Put the returned operationId, payloadHash, approverUserId, and expiresAt into confirmation, then pass it with the same fields to delete_library_asset. Confirmation lasts ten minutes. If the target or permissions change, prepare again with a new operation key. deleted: true with purgeStatus: requested means metadata was deleted and object removal was requested; it does not confirm storage purge completion. Copies already placed in other Rooms remain.
• Request presentation conversion: pass input: { assetId, expectedAssetVersion, expectedFileVersion } and the operation key to request_library_presentation_preview. Conversion must be enabled and the asset must meet the existing format, size, and readiness requirements. Requests share the screen's limit of ten per user per minute. queued means accepted, not converted. Check the current conversion state with get_library_asset_presentation_preview.

Never automatically resend an operation with an unknown outcome. Use get_mcp_operation with the same token and files:read to inspect destination IDs and current state. Also inspect the existing preview state after an uncertain conversion request. Oversized asset information or a changed source is rejected rather than returned as an empty success.

See Library and Adding files for more details.

Work with Room files through MCP

MCP additions not included in the first release: generate_file_insight, get_library_asset_presentation_preview, get_library_asset_viewer_url, start_file_analysis. These additions are planned for a later release. Existing screen operations remain available.

Use versionNo from get_file or list_files as expectedFileVersion for changes, analysis starts, conversion requests and explicit downloads. Renaming a file does not increment its native version. A changed source or permission can still invalidate a prepared confirmation.

Current Workspace and Room members, including external members, can use list_files, get_file and the viewing, media, thumbnail and explicit download modes of get_file_download_url. External downloads require both the Room and file download permissions. Renaming requires files:write and Room owner/editor access; external editors can rename only their own uploads. HTML and presentation reads and initial conversion requests also allow current Room members. Only internal owners and editors can retry failed conversion. Analysis, link previews and insights retain internal Workspace and Room membership requirements. Reads require files:read; analysis starts require files:write and Room owner/editor access. Initial conversion requests and link preview fetches allow Room viewers with files:write; retrying failed conversion requires internal owner/editor access. Insight generation requires both files:read and agents:write and retains the existing AI credit rules.

HTML and presentation read arguments are under input. For analysis, use existing get_file_extracted_text with top-level fileId and view: "analysis". For existing get_file_download_url, keep roomId, fileId and purpose at the top level. view: "analysis" returns status and page labels, never full extracted text, with default 20 and maximum 100 items. Pass the native page number in nextCursor as cursor; stop when hasMore is false. For extracted text, use the same get_file_extracted_text with view omitted or set to "text". limit and cursor apply only to analysis. get_file_download_url with purpose: "thumbnail" returns an image thumbnail; the same tool with purpose: "media" returns an authenticated media URL and Range endpoint. Neither records a view or proves playback.

get_file_html_preview returns viewerPath for a signed-in browser. It does not return raw HTML through MCP. The host retains the original sandbox and authorization. SAFE HTML may embed while durable source capture is pending; ordinary artifact URLs/downloads still require complete readiness. Use the host's Retry action if loading fails. Never append a token or secret to the URL.

Use get_file_presentation_preview to inspect conversion. Existing format and feature availability applies. A queued result from request_file_presentation_preview confirms admission, not completed conversion. Requests share the original ten-per-user-per-minute limit with the normal screen. Ready viewing URLs also require current MCP authentication. Inspect again if the source version or access changes. Changes to the original or required retry authority while waiting can stop subsequent dispatch. Inspect current status after an unknown outcome; do not automatically replay the request.

Prepare metadata changes with prepare_update_file_metadata, review the before/after fields, then send the same target, native version, fields, dated idempotencyKey and returned confirmation to update_file_metadata within ten minutes. Inspect the final filename and publication status. Download permission is preserved and cannot be supplied as an input.

To delete a file, pass top-level fileId, its observed expectedFileVersion and a dated idempotencyKey to prepare_delete_file. Review the target name, then send the same fields and the returned confirmation to delete_file within ten minutes. The server resolves the Room. Current Room owners and editors may delete files; external editors can delete only their own uploads. The existing FileV1 pipeline makes the source unavailable and requests purge. deleted: true and purgeStatus: requested do not prove that physical storage purge has finished. Do not automatically resend an uncertain operation with a new key. Inspect get_mcp_operation; an absent file alone does not prove deletion succeeded.

start_file_analysis uses the existing lease, credit admission and runner. Queued, in progress, reconciliation pending and service unavailable are distinct; admission does not prove completion. generate_file_insight derives real aggregates and labels for the current File on the server, accepts no caller-supplied analytics or labels, and rejects excessive input explicitly. The existing insight template produces Japanese text. Losing a generated answer does not cause automatic regeneration or another credit charge.

Existing get_file_download_url retains flat top-level roomId/fileId. Omitted purpose or view returns the viewing URL without recording a view. purpose: download also requires an observed version and dated idempotencyKey, and records the same explicit download request as the ordinary screen. URL issuance and a request event do not prove completed transfer or actual reading.

Room-file viewing, thumbnails, media, explicit downloads and ready previews, plus get_library_asset_viewer_url and get_library_asset_presentation_preview, use the authenticated MCP content route. The existing field name signedUrl does not mean the link can be shared as a standalone signed capability. When requiresMcpAuthorization: true, the connected client must send its current MCP Bearer authentication in the Authorization header. Never paste a token into a URL or chat. Clients that cannot fetch with this header should open the file in the person’s signed-in Room or Library screen. Token, IP policy and current access are checked before retrieval, after the storage response and at the existing interval while streaming. Revocation is not instantaneous; access or source-version changes stop retrieval. Fetching a link does not prove reading or transfer completion, and a content GET does not record another download request. The separate Library Room-material viewer and logo viewer retain their own existing backend URL conditions.

fetch_room_link_preview uses input.roomId/url and a dated idempotencyKey. URLs must be http/https and at most 2048 characters. Existing destination safety and redirect restrictions remain. A known no-preview null differs from an authorization or budget rejection.

Do not automatically replay an unknown mutation. Inspect get_mcp_operation and the current File/analysis/preview state. Reusing a confirmed key does not regenerate a lost URL or AI answer; decide whether a genuinely new request is needed from current state.

Template preview, cloning and material-set deletion

MCP additions not included in the first release: delete_material_set, get_gallery_template_preview, prepare_delete_material_set. These additions are planned for a later release. Existing screen operations remain available.

Existing ordinary template creation through create_room_from_template is retained. The new clone and reconciliation flow using source, include, dated idempotencyKey and operation.operationId, including gallery cloning, is not included in the first release. It is a later addition. See templates.

To delete a material set, review prepare_delete_material_set, then pass the same input and key with its confirmation fields to delete_material_set within ten minutes. The files are preserved. See Manage Room material sets for top-level arguments and the confirmation object.

Inspect file shares, preview a draft, and copy a share URL

These reads require files:read, current active internal editing access to the Room, and enabled file sharing. Use the existing read-tool envelope: {"input": {...}}.

Later MCP additions (not included in the first release)

Listing is bounded to 100 files per link and 100 recipients and domains each. Oversized legacy data produces an explicit app-handover error rather than silently omitted records. Draft responses are limited to 1 MiB. Read again if access or source files change. pathAvailable: false means the app path is unavailable. A handover does not mean a share URL was revealed or the clipboard was updated. See Share selected files externally.

Issue, update, stop, and analyze file shares

MCP additions not included in the first release: get_file_share_viewer_analytics, list_file_shares, reveal_file_share_url. These additions are planned for a later release. Existing screen operations remain available.

File-share writes require files:write, enabled file sharing, and current active internal editing access to the Room. They use {"input": {...}, "idempotencyKey": "YYYY-MM-DD:UUID"}. The key date is UTC. First call the corresponding prepare_... tool, review its preview, then call the final tool with the same input and key, plus confirmation containing the returned operationId, payloadHash, approverUserId, and expiresAt. Confirmation lasts ten minutes. A changed version, source, protection setting, or PIN requires a new preparation and key.

Later MCP additions (not included in the first release)

Audience choices match the current creation screen: anyone_with_link or invited_emails_only. Identified sharing also requires its existing feature availability. Supply recipientEmails for invited email access. Invalid combinations, unsupported or unsafe files, past issuance expiry, and unavailable features are rejected by the original application rules. A PIN is checked again against the prepared protection; the raw PIN is not retained in the receipt hash or returned.

Issuance returns the new link ID, safe conditions, and an authenticated Files-page handover. It does not return the secret URL or update your clipboard. Open sharing for the returned target file IDs and personally copy the existing link. If pathAvailable is false, navigate to the Room’s Files page yourself. This human step also applies to reveal_file_share_url.

For analysis, call get_file_share_viewer_analytics with {"input":{"roomId":"...","shareId":"...","limit":25}} and files:read. Optional cursor continues the viewer list; limit is at most 50. Native identified/anonymous classifications and page-duration sums are preserved. The response is bounded to 500 page aggregation groups across the returned viewers and 1 MiB; exceeding either produces an explicit error, never a partial duration total. Reduce the viewer limit or use the normal screen when necessary.

For an in-progress or unknown write, inspect get_mcp_operation and current list_file_shares state with files:read and current management access. Current state is not proof that an uncertain operation performed a change. Do not automatically replay an unknown result. Reusing a confirmed key observes the receipt; it does not issue another link, regenerate a secret URL, or repeat an audit.

Inspect and stop Room invitation links

MCP additions not included in the first release: deactivate_shared_link, list_shared_links, prepare_deactivate_shared_link. These additions are planned for a later release. Existing screen operations remain available.

Room invitation links differ from file-share links. list_shared_links uses {"input":{"roomId":"...","limit":25}}, optional cursor, and rooms:read; the maximum limit is 50. Current active internal Room owner/editor access or target-Workspace management access is required. The result contains IDs, creation/expiry, use limits/counts, approval/PIN requirements, and active state. Invitation tokens, PIN hashes, and credential URLs are omitted.

To stop an invitation, call prepare_deactivate_shared_link with {"input":{"roomId":"...","linkId":"...","expectedUseCount":2},"idempotencyKey":"YYYY-MM-DD:UUID"}, then deactivate_shared_link with the same input/key and four-field confirmation within ten minutes. This requires rooms:write and current target-Workspace OWNER/ADMIN or active Room owner authority. A global account role does not replace target-Workspace membership. A changed usage count or source requires preparing again; stopping never restores an earlier usage count. To observe its receipt, retain rooms:read and the current stopping authority, including rooms:write. Unknown outcomes are observation-only, without automatic retry. See Share a Room.

List, create, and link meetings

MCP additions not included in the first release: create_room_meeting, link_meeting_to_room, list_my_meetings, list_room_meetings, prepare_create_room_meeting, prepare_link_meeting_to_room. These additions are planned for a later release. Existing screen operations remain available.

Meeting reads use rooms:read with {"input": {...}}. list_my_meetings requires ISO-date input.from/to with a positive range of at most 31 days. list_room_meetings takes input.roomId and optional from/to. limit defaults to 25 and is at most 50; cursor is at most 2048 characters. Native current visibility and Room scope apply. Specific-Room tokens do not return unlinked personal meetings.

External members can also use list_my_meetings. Their results omit Room suggestions and return suggestionsStatus: not_requested. This does not add internal Room meeting lists, transcript status, minutes pages or connection details.

For creation, use rooms:write and call prepare_create_room_meeting then create_room_meeting. For linking, call prepare_link_meeting_to_room then link_meeting_to_room. Use {"input": {...}, "idempotencyKey": "YYYY-MM-DD:UUID"} and add the four-field confirmation to identical input/key for the final call, within ten minutes. See Manage meetings for title/date/participant limits, recording consent, link permissions, and unlinking. Preparation does not contact providers; review the planned Zoom creation and Calendar invitations in its preview.

Calendar may have an unknown outcome after Zoom creation succeeds. get_mcp_operation uses rooms:read and current visibility to inspect safe meeting metadata; it does not prove external dispatch. current: null for invisible or deleted meetings does not prove failure. Check the external service when needed. Reusing an in-progress, unknown, or confirmed key does not automatically create another meeting. Follow the authenticated app steps for OAuth consent, microphone permission, and starting capture.

Create a recording session

These operations require files:write, current internal Workspace membership, and the original recording feature’s Room editing or management authority. A specific-Room token must include the target Room. MCP creation creates an unstarted session; its creator permits audio capture in the authenticated browser. See live transcription.

Later MCP additions (not included in the first release)

Room and session IDs are UUIDs; pageId accepts an existing native Page ID up to 255 characters. Use {"input": {...}, "idempotencyKey": "YYYY-MM-DD:UUID"}. Preparation inspects current state without changing recordings, speech, or minutes. Within ten minutes, execute with identical input/key and confirmation containing the returned operationId/payloadHash/approverUserId/expiresAt. Do not provide an observed timestamp or internal state: the server observes them and rejects a changed source.

The returned appPath opens the same session in its creator’s authenticated browser. MCP receives no recorder credential. Handover is limited to the creator’s unclaimed session within four hours of creation; reopening does not extend expiry. English MCP creation requires the existing English mode to be on; qa users create through the browser. Handover rechecks current permissions, recording policy, usage limits, and language availability.

Creation rejects a referenced Page whose source exceeds 2 MiB. Inspect that Page in the normal screen.

Inspect get_mcp_operation with the same files:write and current native recording authority. current: null does not prove the operation never ran. Unknown outcomes are observation-only: do not automatically resend under a new key. Reusing a confirmed key does not recreate a recording. Analysis and minutes synchronization progress separately, so inspect their current states as well.

Personal calendar sync and Zoom imports

Later MCP additions (not included in the first release)

authorization.appPath points to an existing Terasu entry. Sign in with the same account that created the MCP token, consent on Google or Zoom's screen, then inspect the connection again. Returning the entry does not mean connecting or consent is complete.

Calendar's five-minute interval and last sync time are shared across all your workspaces. A skip or zero count does not prove the destination is up to date. Events already saved can remain if a later step fails. For Zoom, select from at most 50 candidates in a normalized 30-day range, and distinguish acceptance, pending analysis, and an existing meeting-minutes Page.

Confirm both operations with identical prepared input, the same dated key, and the returned confirmation. Reconcile unknown outcomes with get_mcp_operation without resending. Calendar lookup accepts rooms:write; Zoom import lookup accepts files:write. A missing Page in an observation does not prove the original operation never ran.

Your workspace context

Use get_my_workspace_context with an all-Room token and workspace:read. It targets only the token workspace for a currently active member. Internal members receive basic Workspace information; external members receive currentWorkspace: null, matching the existing screen. It does not load every organization, workspace or Room, or return external avatar/logo URLs. Use list_rooms with rooms:read for Rooms.

This read does not refresh browser sessions or change token grants. Use the existing browser Workspace selection. The first release does not return entries to unpublished additional-creation or internal-use onboarding screens.

Workspace member roles and removal

Internal and external users need the current administrative permission above. Both require an all-Room token with workspace:write. Role input is {"input":{"memberId":"UUID","newRole":"ADMIN"},"idempotencyKey":"YYYY-MM-DD:UUID"}. Removal uses {"memberId":"UUID"} as input. The member must belong to the token workspace; another workspace or actor cannot be supplied. An admin can change a current Member to Admin or Member; only owners can promote someone to Owner. Self-changes and the last owner are protected.

Collect the returned operationId/payloadHash/approverUserId/expiresAt as confirmation and execute with the same input and key within ten minutes. Stale state, revocation, demotion and cancellation reject execution. Concurrent browser operations also recheck membership. Reconcile unknown outcomes through get_mcp_operation with workspace:write without replay. Current state does not prove this operation succeeded, and removal observation requires a current owner. See role restrictions.

Room members and Workspace directories

To change a Room member’s role, review prepare_update_room_member_permission, then pass the same target, permissionLevel, operation key and confirmation to update_room_member_permission. Choose editor or viewer; an existing Room owner cannot be changed.

list_workspace_members is the Workspace owner/admin member directory. Supply input.roomId for that Room’s invitation candidates instead. Current internal Room owners and editors can also use this view. It returns names, email addresses and profile pictures, excluding everyone already in the Room, including pending members. Candidates omit administrative roles, join dates and last-access metadata. Both views require an all-Room workspace:read token. Continue with meta.cursor as the next input.cursor.

list_workspace_invitations requires current Workspace owner/admin membership and returns PENDING invitations, matching the screen. An explicit status must also be PENDING. Reads do not change expiry or status and never return invitation tokens or URLs.

Workspace and Room invitations

Use the common input, dated key and four-field ten-minute confirmation. Workspace invitations take email, role: ADMIN/MEMBER, optional message (500 characters) and locale: ja/en. Room email invitations take roomId/email; approvals take the roomId/memberId verified in the member list. Emails are limited to 254 characters; Room and member IDs are UUIDs. Room operations also require current active internal Workspace and Room membership and the original invitation or approval conditions. A token limited to the target Room can be used.

Preparation creates no email, invitation or member. Execution retains the original seat, membership, expiry and reissue conditions. A source row exceeding 64 KiB, or a Room approval exceeding 500 members or 1 MiB of member rows, is refused; inspect it in the normal application.

Email delivery is not proven. An unknown outcome or current: null does not prove that nothing was sent. Reconcile with get_mcp_operation using the same required permission; resending under another key can duplicate an invitation or email.

For an invitation you received, pass invitationId to get_my_workspace_invitation_entry with an all-Room workspace:read token. This returns a same-account browser entry without reading or changing the target invitation or completing acceptance. Sign in as the same person, review the email, Workspace and role, then explicitly join. Joining another Workspace does not expand the existing MCP token's scope. New decline controls are not included in the first release. ### Profile images and Workspace logos

For your own image use prepare_upload_my_avatar / upload_my_avatar and prepare_delete_my_avatar / delete_my_avatar. For Workspace logos use prepare_upload_workspace_logo / upload_workspace_logo and prepare_delete_workspace_logo / delete_workspace_logo. All require workspace:write, an all-Room token, and current active membership, including external members. Logo operations additionally require current OWNER or ADMIN membership. The server determines the person, Workspace, and storage destination; arbitrary targets or URL forwarding are not accepted.

Uploads take contentBase64, a canonical Base64 encoding of an image up to 10MiB, and its MIME contentType. The encoded text is larger than the original file. Image content and MIME are checked before converting to WebP: 256×256 for profile images, within 800×800 for logos. Profile images accept JPEG/PNG/GIF/WebP; logos accept JPEG/PNG/WebP. Review preparation, then execute with the same input, operation key, and confirmation within ten minutes. Preparation does not save the image.

For an unknown outcome, inspect the current state with get_mcp_operation without repeating the write. Whether an image is displayed and whether storage can be inspected are separate facts. Current state does not prove this operation succeeded, and removal does not guarantee physical erasure. Display URLs require the existing application login; signed URLs and storage keys are not returned through MCP. See profile settings and Workspace settings for the regular screens.

Workspace AI balance, summary, and progression settings

MCP additions not included in the first release: get_workspace_ai_summary_prompt. These additions are planned for a later release. Existing screen operations remain available.

Later MCP additions (not included in the first release)

Balance reads take empty arguments and perform no write. Uninitialized balances return balance:null; initialization or period changes require requiresResolution:true. Balance synchronization takes empty input. AI summary changes require aiSummaryPrompt (up to 10,000 characters; null or an empty string restores the standard setting) only. The current model setting is preserved; model inputs are not accepted. Progression changes take the complete configuration, with JSON limited to 32 KiB in UTF-8 and the whole request to 256 KiB.

get_workspace_deal_progression is included in the first release. get_workspace_ai_summary_prompt is a later MCP addition. The three mutations do not write during preparation. Confirm within ten minutes with identical input, a YYYY-MM-DD:UUID idempotencyKey, and the returned four-field confirmation. Changed source, revocation, demotion, another Workspace, and cancellation reject execution. Caller-supplied versions, actors, or Workspaces cannot replace the server-bound values.

Reconcile unknown results through get_mcp_operation with workspace:write, observing safe current state without replay. Matching text, settings, or balance does not prove that operation succeeded. Synchronization does not purchase, charge, or consume credits; payment confirmation takes place in your own screen. See AI Summary, Project Progression, and AI credits.

Your notifications by Workspace or Room

The existing list_my_room_notifications and get_my_room_unread_notification_count read within the token’s Workspace when input.roomId is omitted (requires an all-Room token with workspace:read). With a Room, they read only that Room; internal and external Viewers are supported. List collapseTaskNotifications defaults to false; true groups task notifications. The count is the unread total before grouping. mark_my_room_notification_read accepts input.roomId plus either input.notificationId or input.threadId, acknowledging only your own notifications (workspace:write, current Room membership, internal and external Viewers supported). Use idempotencyKey; for an unknown outcome, do not resubmit: inspect get_mcp_operation. These reads are scoped differently from your email preferences across all Workspaces. See Notification settings for steps and pagination.

Your support requests, replies, contact inquiries and article feedback

These operations require an all-Room token with workspace:write and current Workspace membership. They act as the token owner. You cannot override the actor, Workspace, reply sender type, IP or send time. Replies are limited to your own requests. Support lists and details belong to your account, so they can include your requests created in another Workspace.

Prepare with input and a YYYY-MM-DD:UUID idempotencyKey. Review the returned content, then include operationId, payloadHash, approverUserId and expiresAt in confirmation. Send the same input and key within ten minutes. A bug or improvement preview also shows the name and email appended to the report. Preparation sends nothing and consumes no rate allowance.

For a support request, category is bug or enhancement, title allows 100 characters, description allows 5,000, and locale is ja or en. A reply takes issueId and a message of up to 5,000 characters. The screen and MCP share the same limits: five new requests per user per hour and twenty replies per user per hour.

A contact input takes name, email, category, message and optional company, using the screen's limits. Categories are general, sales, partnership, security, feedback, terasu-signal and zoom-integration. Contact inquiries share the screen's five-per-IP hourly limit. The IP and article feedback User-Agent come from the actual MCP HTTP request.

For article feedback, set articlePath to a published article's category/slug, such as getting-started/quick-start. When sentiment is positive, reason must be null. For negative, use outdated, unclear, not-relevant, missing-info, or null to skip the reason.

Reusing a key does not send again. If the outcome is unknown, keep the key and inspect get_mcp_operation with workspace:read. You can also inspect your support list or request details, but current values alone do not prove this send succeeded. Contact inquiries and article feedback have no personal history screen; an unconfirmed outcome needs manual reconciliation. A contact result's stored and externalDeliveryConfirmed report storage and external notification separately. If external support creation succeeded but local storage is uncertain, it is not automatically repeated.

Eligibility for your personal settings

get_my_profile, update_my_profile, get_my_locale_preference, update_my_locale_preference and your email notification settings are available to an active person who currently belongs to the token’s Workspace. Both internal and external members are supported. Use an all-Room token with workspace:read for reads and workspace:write for updates. Permission to use an existing token does not grant permission to issue one.

As in the settings screen, internal members can edit eight email events; external members can edit only new-message notifications. Direct mentions remain locked on and must be omitted from update inputs. Profile, language and email settings apply to your account across Workspaces without changing token scope or membership.

Category and label deletion implicitly affect all tasks belonging to that category or label, matching the screen. Confirmations and results do not return hidden Task IDs or counts. Direct Task reads, parent selection, and reordering are restricted to shared tasks for external members, with current Room membership, editing permission for writes, and token scope enforced.