Skip to main content
Glama

Typebar (formerly SuperDocs)

chat

Synchronous AI chat that can rewrite specific paragraphs, add or remove table rows, restructure sections, generate new content from templates, or transform an entire document. Pass document_html only to load or replace the document; once a session holds a document the server persists it across turns, so omit it on follow-up turns. 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 AI response text plus structural document changes (HTML edits, additions, deletions) with chunk IDs. One billable operation per document-modifying turn; very large multi-section edits bill one operation per 25 sections changed. For long-running edits or human-in-the-loop approval, use chat_async. 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' to skip the full HTML in the response (the AI returns only per-section diffs in chunk_diffs) and save thousands of tokens per turn. To read sections in compact mode, just send a natural-language request like 'show me the force majeure section' — the AI returns the content in the reply text. Always use natural language to describe what you want; the AI handles all internal section lookups.

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.
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) returns the complete updated document HTML — required by web app editors and recommended for small documents (<20 pages). 'compact' (recommended for AI agents editing large documents) suppresses the full HTML and returns only per-section diffs (chunk_diffs) for changed sections, saving thousands of tokens per turn. To read sections in compact mode, just send a natural-language request like 'show me the force majeure section' — the AI returns the content in the chat 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
hintNoAdvisory guidance for API callers (additive; absent on most responses). Currently: prefer_chat_async_for_large_generations — this turn ran long enough that the same work submitted via POST /v1/chat/async would be safer (no gateway timeout risk) and reports progress.
usageNoOperation usage data. Present for authenticated users with usage tracking.
responseYesAI assistant's response text.
session_idYesSession identifier for this conversation.
document_changesNoDocument modifications made by the AI. Present only when the document was changed.

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?

With no annotations, the description carries the full behavioral burden and does so: it discloses cross-turn document persistence, the drift risk of describing content in `message`, billing granularity (one operation per modifying turn, per 25 sections for large edits), the response payload shape (reply text plus structural changes with chunk IDs), and the compact-mode token trade-off.

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?

Dense but front-loaded: capability statement, then document_html handling, then billing, then alternatives, then optional params. Nearly every sentence adds operational value, though the compact-mode guidance is partly restated from the schema and the prose runs long for a single tool.

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 19-parameter mutation tool with an output schema, the description covers what an agent needs: session/document handling, billing, async alternative, response shape, and optional tuning parameters. Nothing material to correct invocation is missing.

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 schema already documents most parameters and the baseline is 3. The description adds real semantic value on top: when document_html must be sent versus omitted, the verbatim-vs-authored distinction, and why response_mode='compact' is recommended for agents — beyond what the enum and field docs state.

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?

Opens with a specific verb+resource ('Synchronous AI chat') and enumerates concrete capabilities (rewrite paragraphs, add/remove table rows, restructure sections, generate content, transform document). It also explicitly distinguishes itself from the sibling chat_async, so an agent can route 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?

Gives explicit when-to-use rules: pass document_html only to load/replace and omit it on follow-ups, use upload_document_base64 or verbatim document_html for exact content, use chat_async for long-running or human-in-the-loop edits, and set response_mode='compact' for large documents. Alternatives and exclusions are both named.

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.