Tool loop
message is only a summary. The text the model edits is in context.html, so
send both. The definitions come from the same source as Revise’s production
agent, with the same descriptions and constraints.
Results
This API and@reviseio/editor/server return the same result type, so the same handling
code works in the browser and in Node:
context.html. This HTML keeps block IDs, inline
formatting, tables, and notes. Mutation tools target those block IDs. Mutations
in suggesting mode list the tracked changes they created in suggestionIds.
Pass them to review.acceptSuggestions().
Working with blocks
The model reads part of the document, then edits by block ID:context_notes is how a model carries what it learned from one read into the
next, and the schemas require it. When your own code calls a tool through
execute() or call(), you can leave it out; it defaults to "N/A". Calls
through executeDynamic() are passed on exactly as the model sent them.
Edit every match
Searching the active document returns asearch_result_id for the full match
set, across all pages. Pass it to replace, replace_block, style_blocks,
or remove_blocks instead of an id. The edit applies to each matched block
separately, in one call:
Routing to a document
Every tool schema has an optionaldocument_id. Omit it to target the active
document, or pass the ID of any ready document in the same editor:
Suggestions or direct edits
Tool mutations are tracked changes by default, whatever mode the editor is in for typing. PassdirectMode to apply them directly:
What is not a tool
Review navigation, comment panel state, focus, viewport, zoom, and canvas rendering belong to the host. They are not tools in this catalog. The agent makes document edits, and your UI presents them. A delegated Revise agent can inspect the rendered canvas with its internalrender_document_pages tool. See
architecture and delegation.
The full catalog is in the tool reference.
Server-side editing
@reviseio/editor/server binds the same tool definitions and executor to a Y.Doc that
you own. No model or React mount is involved. The backend
reference covers conversion, room lifecycle, and the
full session API.
A session:
- is bound to one document, so its schemas have no
document_id - keeps search result IDs across calls
- runs every call in arrival order
- must be disposed. Disposing removes Revise’s observers and leaves your
Y.Docintact.
call() in
application code: it returns the response and throws ReviseToolError when the
tool rejects the call. Use execute() for a result object instead, or
executeDynamic() for tool names and JSON from a model.
Switch modes with document.setSuggestingMode() and
document.setEditingMode(). Each call uses the mode that was set when it was
submitted, so switching is safe with calls still queued.
Revise semantic HTML
Read and search tools returnresponse.context.html in Revise semantic
HTML: document markup with stable block IDs for paragraphs, formatted runs,
tables, comments, and notes where supported. Typed metadata is in
response.data. A short summary for the model is in response.message.
Structural insertion and whole-block replacement accept the same HTML. Use it
instead of building DocRoot or OOXML. It is not general browser HTML and CSS,
and it does not represent Word layout that Revise does not support. The
Yjs-backed Revise model is the source of truth, and DOCX is the import and
export format. Running a tool does not reparse unchanged content through HTML.
Do not mutate DocRoot directly. Some conversion calls still return that type
for compatibility. The supported server mutation API is
(await createServerDocumentSession(ydoc, ...)).tools.