Skip to main content
Glama

Typebar (formerly SuperDocs)

chat_async

Use instead of chat when (a) the edit is large or multi-step, (b) you need human approval on each proposed change before it applies (set approval_mode='ask_every_time'), or (c) you can't afford to block on a synchronous response. To replace the whole document with EXACT content you already hold, pass that content in document_html (a verbatim load — the AI never re-types it) or upload it via upload_document_base64; describing the content only in message makes the AI author it, which can drift from your text. Returns a job_id immediately. Poll get_job to track progress and retrieve the final document. Approve or deny pending changes via approve_change. Job state is durable and survives server restarts. Optional: model_tier (core/turbo/pro/max), thinking_depth (fast/balanced/deep), image_attachments for multimodal vision. RECOMMENDED for AI agents working with large documents (>20 pages): set response_mode='compact' so the job result skips the full HTML and surfaces only per-section diffs in chunk_diffs, saving thousands of tokens per poll. To read sections in compact mode, just send a natural-language chat request ('show me the pricing section') — the AI returns the content in the reply text. Always use natural language; the AI handles all internal section lookups. HITL workflow (approval_mode='ask_every_time'): 1) poll get_job until status=awaiting_approval, 2) read metadata.pending_changes for proposed edits, 3) call approve_change per change, 4) continue polling until status=completed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYesYour message to the AI assistant.
user_idNoUser identifier. Automatically set from authentication — typically omit this.
window_idNoOptional identifier for the client window (set by the web app) so concurrent edits from two windows of the same chat are merged rather than overwritten. Agents/API may omit.
async_modeNoMust be true for async processing. Included for backward compatibility.
model_tierNoAI model to use: 'core' (default, fast), 'turbo' (fastest), 'pro' (advanced reasoning), 'max' (most capable).
session_idYesUnique session identifier. Reuse to continue a conversation.
document_idNoTarget a specific open document by id (ids come from /v1/sessions/{session_id}/documents). Omit to target the focused document (default — unchanged single-document behaviour). When set, that document becomes the focus for this turn.
approval_modeNoChange review mode: 'approve_all' (default, auto-applies changes) or 'ask_every_time' (pauses for your review).
authorizationNo
document_htmlNoCurrent document HTML. OMIT this when the session already holds the document — the server persists it across turns, so you don't re-send it every turn; pass it only to load new content or replace the document wholesale (a verbatim load — the AI never re-types content passed here). Include data-chunk-id attributes on elements to enable targeted AI edits.
response_modeNoResponse shape control. 'full' (default) puts the complete updated document HTML in the job result — required by web app editors and recommended for small documents. 'compact' (recommended for AI agents editing large documents) suppresses the full HTML and stores only per-section diffs (chunk_diffs), saving thousands of tokens when polling get_job. To read sections in compact mode, send a natural-language request to chat ('show me the pricing section') — the AI returns the content in the reply text.full
cursor_contextNoEditor cursor context at message time, used to default the insert location for new images, diagrams, or sections when the user's prompt doesn't name a position. Shape: {chunk_id: str, pos_in_chunk?: int, text_before?: str, text_after?: str}. Omit when the user typed in chat without focusing the editor first.
thinking_depthNoReasoning depth: 'fast', 'balanced' (default), or 'deep'. Controls how much analysis the AI performs.
image_attachmentsNoInline images for vision-based analysis (base64-encoded).
touched_chunk_idsNoOptional list of chunk ids (data-chunk-id values) the user actually edited since the last sync, sent alongside document_html. When present, a chunk NOT in this list whose text is unchanged keeps its stored formatting byte-for-byte even if the client serialized it differently (protects styling from editor round-trip loss). Chunks in the list — and any chunk whose text changed — always take the submitted content. Omit for the default behavior (any differing chunk is treated as an edit).
cross_session_scopeNoOptional list of session ids to restrict cross-session SEARCH to (e.g. one end-customer's sessions). Omit to search all of this account's sessions. Only narrows within the API-key owner; ignored unless cross_session_search is on.
cross_session_memoryNoWhen true, the AI carries a private rolling memory of context across THIS account's chats (off by default). Per-request override of your saved Settings default.
cross_session_searchNoWhen true, the AI may search your PAST chats and documents on demand to reuse prior work and open a found document (off by default). Per-request override of your saved Settings default; never affects the always-on search of the open document.
deleted_part_chunk_idsNoOptional list of chunk ids (data-chunk-id values) of OUT-OF-FLOW part sections (page headers/footers, footnote/endnote bodies, comments) to delete explicitly, sent alongside document_html. Out-of-flow parts absent from document_html are always KEPT — an editor view not containing them is their normal state, never a deletion — so removing one requires naming its id here. Ids that are not stored out-of-flow parts are ignored (in-flow content keeps the default behavior). Omit when deleting nothing.
cross_session_memory_keyNoOptional per-request id of YOUR end-customer so the cross-session memory note is kept in a separate file per end-customer. Omit for one account-level note (the default / B2C).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesJob identifier. Poll GET /v1/jobs/{job_id} for status and results.
statusYesInitial job status (always 'pending').
messageNoHuman-readable status message.Chat request queued for processing
session_idYesSession identifier for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so: it discloses that the call returns a job_id immediately rather than blocking, that job state is durable across server restarts, that polling happens via get_job and approval via approve_change, and that compact mode trades full HTML for per-section chunk_diffs. The verbatim-load vs AI-authored-content distinction is a non-obvious behavioral trap it proactively warns about.

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

Conciseness4/5

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

Front-loaded with the routing decision, which is the highest-value sentence, and every later sentence covers a distinct concern (verbatim loading, polling, approval, compaction, HITL steps). It is a dense single block with no paragraph breaks, so it reads as a run-on and repeats the compact-mode explanation that also lives in the schema; a 20-parameter async tool justifies the length, but tighter structure would help.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still supplies the one thing an agent needs to act on the response — that it returns a job_id and must be polled via get_job. Combined with the approval loop, the durability guarantee, and the token-saving guidance for large documents, nothing material is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 95%, so the baseline is 3, and the description earns above that by explaining the semantic difference between passing content in document_html (verbatim load, never re-typed) versus describing it in `message` (AI authors it, can drift) — a distinction the schema does not draw. It also motivates response_mode, approval_mode, model_tier, thinking_depth, and image_attachments, though it stays silent on cross_session_*, touched_chunk_ids, deleted_part_chunk_ids and cursor_context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (async chat turn) and immediately distinguishes itself from its sibling: 'Use instead of chat when...'. The three qualifying conditions (large/multi-step edit, per-change approval, non-blocking need) let an agent route between chat and chat_async without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicit when-to-use conditions (a)(b)(c), a named alternative (chat), a recommendation keyed to document size (>20 pages → response_mode='compact'), and a numbered HITL workflow for approval_mode='ask_every_time'. This is as close to prescriptive routing as a description gets.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.