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

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.
html_document_idNoOptional: the open document (id from /v1/sessions/{session_id}/documents) that `document_html` is the editor state of. The html is applied to that document only, and a turn that names no `document_id` works on that document by default (it is the one on screen); it does not pin the turn (use `document_id` for that). Set by the web app; omit to mean the focused document.
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

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.

No schema history has been recorded yet.

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: immediate job_id return, durable job state surviving restarts, the drift risk when only describing content in `message` versus a verbatim `document_html` load, and the token cost tradeoff of `response_mode='compact'`. The four-step HITL protocol and the `awaiting_approval` status are exactly the kind of non-obvious behavior an agent needs.

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?

It is long and dense, but front-loads the decision criteria (a/b/c) before the mechanics, and each block (document_html semantics, compact mode, HITL flow) addresses a distinct pitfall. Some clauses restate schema descriptions, keeping it short of a 5.

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

Completeness5/5

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

For a 21-parameter, output-schema-bearing async tool, the description supplies everything the agent needs: when to choose it, how to hand off content without AI re-authoring, how to poll, how to approve changes, and how to economize tokens. Return-value details are correctly left to the output schema.

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, but the description adds genuine selection guidance beyond the schema: `approval_mode='ask_every_time'` for per-change review, `response_mode='compact'` recommended for large documents with a rationale (chunk_diffs, token savings), and how to read sections in compact mode via natural language. It does not cover the cursor/session-scope parameters, which the schema already documents.

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

Purpose4/5

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

The description makes clear this is an asynchronous, job-returning variant of chat that edits documents, and explicitly separates it from the synchronous `chat` sibling. It does not open with a crisp verb+resource statement, relying instead on a routing sentence ('Use instead of chat when...') plus 'Returns a job_id immediately' to convey the purpose, but an agent can still identify what the tool does.

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

Usage Guidelines5/5

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

Enumerates three explicit conditions that select this over `chat` (large multi-step edit, per-change human approval, non-blocking), names the alternatives to call for polling (`get_job`) and approval (`approve_change`), and spells out the HITL sequence step by step. It also tells the agent when to prefer `document_html` over describing content in `message`.

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.