Quick start
- Node.js
- Python
excludeActions everywhere (it has no action surface to narrow) — passing it is a harmless no-op.
Tool catalog
Most tools use anaction argument to select the underlying operation. Single-action tools like superdoc_search do not require action.
| Tool | Actions | What it does |
|---|---|---|
superdoc_get_content | text, markdown, html, blocks, extract, info | Read document content in different formats |
superdoc_search | (single action) | Find text or nodes and return handles or addresses for later edits |
superdoc_edit | insert, replace, delete, undo, redo | Perform text edits and history actions |
superdoc_format | inline, set_style, set_alignment, set_indentation, set_spacing, set_direction, set_flow_options | Apply inline or paragraph formatting |
superdoc_create | paragraph, heading, table | Create structural block elements |
superdoc_list | insert, create, attach, detach, delete, merge, split, indent, outdent, set_level, set_type, set_value, continue_previous | Create and manipulate lists |
superdoc_comment | create, update, delete, get, list | Manage comment threads |
superdoc_track_changes | list, decide | Review and resolve tracked changes |
superdoc_mutations | preview, apply | Execute multi-step atomic edits as a batch |
superdoc_table | delete, delete_column, delete_row, insert_column, insert_row, merge_cells, set_borders, set_cell, set_cell_text, set_column, set_layout, set_options, set_row, set_row_options, set_shading, set_style_options, unmerge_cells | Modify table structure, content, and styling (find table/row/cell nodeIds via superdoc_get_content or superdoc_search) |
Behaviors you must know
superdoc_search require values — first returns the first match (error on zero), all returns every match, any returns matches without failing on zero, exactlyOne errors unless exactly one matched (AMBIGUOUS_MATCH on several, MATCH_NOT_FOUND on none).
Refs expire on mutation. Every successful edit bumps the document revision and invalidates previously fetched refs — using a stale ref raises REVISION_MISMATCH. This is the sharpest edge of the legacy surface: pre-fetching refs for two blocks and editing them sequentially always fails on the second edit. For multi-block edits use superdoc_mutations (which resolves all targets before any step executes and applies everything in one revision bump), or re-search between edits.
get_content action:"text" returns the whole document with no pagination — in an agent loop that result lives in conversation history forever and amplifies every later turn’s token cost. Prefer scoped reads.
System prompt
getSystemPrompt() / getSystemPrompt('legacy') returns the prompt this surface was designed with: the search-before-edit workflow, targeting rules, and batching guidance. Use it as-is or extend it — and pair prompt and tools from the same preset.
Creating custom tools
The built-in intent tools cover core editing operations. For anything else, create custom tools that calldoc.* methods directly and merge them with the SDK tools.
| Step | What you do |
|---|---|
| 1. Pick operations | Browse doc.* to find the methods you need |
| 2. Define the schema | Write a function tool definition for your provider |
| 3. Write a dispatcher | Map tool actions to doc.* calls |
| 4. Merge and use | Combine with SDK tools in your agentic loop |
Step 1: Pick your operations
Everydoc.* namespace maps to a group of Document API operations:
Step 2: Define the tool schema
Group related operations under a single tool using anaction enum. This matches the pattern the built-in tools use.
- Keep descriptions short. The model reads every tool definition on each turn.
- Use
additionalProperties: falseto prevent hallucinated parameters. - Reference
superdoc_searchin descriptions so the model knows how to get targets.
Step 3: Write a dispatcher
Map each action to the correspondingdoc.* call:
Step 4: Merge and use
Combine your custom tool with the SDK tools and use your dispatcher in the agentic loop:Extending the system prompt
For custom tools, append usage instructions to the SDK system prompt so the model knows how to use them:Migrating to core
The mapping is conceptual, not mechanical — core actions absorb multi-call legacy patterns into single verbs:| Legacy pattern | Core equivalent |
|---|---|
superdoc_search → superdoc_edit (replace by ref) | replace_text (finds and edits in one call) |
superdoc_search → superdoc_mutations (multi-block batch) | one action call — each action resolves its own targets atomically |
superdoc_create + superdoc_format chains | insert_paragraphs / insert_heading / create_table with placement |
superdoc_track_changes {action:"decide"} | accept_tracked_changes / reject_tracked_changes (with author/changeType filters) |
superdoc_comment | add_comments / reply_to_comment / resolve_comments |
preset: 'core' on the toolkit) plus adopting the receipt contract — see the core preset reference.
Related
- Core preset reference — the recommended surface
- How it works — SDK ↔ CLI ↔ LLM mechanics
- Overview — providers, token budget, errors, troubleshooting

