check_connection
ChatGPTReport the current connector access-token lifetime and refresh capability.
Productivity
Overview
Version Story compares versions of Word and PDF documents and produces redlines: PDF redlines and Word tracked-changes files. It can also merge separately edited revisions of one document, combine independent drafts, and build a version history that attributes each change to the version that introduced it. Requires a Version Story account; selected documents are uploaded to Version Story for processing and stored in that account.
Tools
collapse_versions
ChatGPTCollapse a run of a document's versions into one when the user asks ("collapse v2 and v3"). The first takes the last one's content, its redline showing the whole run; the others leave the history. Match the user's "v2" to a version_label in your earlier results.
create_combine
ChatGPTCombine two or more documents that share no common original into a single Word document. Use this when several documents are independent drafts with no shared original (different people each drafting from scratch, or otherwise unrelated versions) and the user wants one combined draft. Prefer create_merge whenever the documents are edits of one original: merge diffs each revision against that shared base, which produces a cleaner result. Combine has no base; it constructs one from the content the documents share, then carries each document's content into the result as tracked changes labeled by the document it came from, so each change can be accepted or rejected in Word. The result does not depend on the order of the documents. document_authors labels each document's tracked changes with its author, in the same order as the documents. Propose the attribution from what is visible (document properties when readable, file names, the documents' own text), confirm it with the user, and ask when nothing gives a basis for a proposal. Name each document by its file_id (upload a local, attached or linked file with upload_file first), or a version by document_id and version_id (get_document lists them). The combined document opens with a cover sheet on reviewing it and ends with a summary of each document's changes; leave either out with include_cover_sheet or include_changes_summary false. Excel files are not supported.
create_comparison
ChatGPTCompare, diff, or redline local or attached documents into true Word tracked-changes, PDF, or PDF changed-pages-only redlines. Use this when the source documents (DOCX, DOC, PDF, or XLSX) exist as local files — for example attached to the conversation — rather than at https URLs. The comparison engine produces the exact set of changes between each base document and its revisions as a true redline. A single call stages everything, one base document or several. Pass version_story_id to add the comparisons to an existing project instead of creating a new one. Files attached in ChatGPT go in base_file and comparison_files rather than the path fields: Version Story fetches them itself and the response has status uploaded, with no transfers to perform. For files passed by absolute path, the response usually contains command: one shell command that uploads the documents, waits for the redlines, and saves them to output_files — run it as given and present the saved files; no get_redlines call is needed. Otherwise it contains upload_manifest_url describing the file transfers — each an HTTP PUT of the raw file bytes that the calling agent performs itself with any HTTP client (curl, for example). It also contains comparisons[] with a version_mapping_id and a redline_url per comparison document — a link the user can open to view the tracked changes interactively. Redline generation starts automatically as the uploads land.
create_merge
ChatGPTMerge two or more revised copies of one base document into a single Word document. Use this when several people have separately edited the same original document and the user wants one combined draft. The result carries each revision's edits as tracked changes, labeled by the revision they came from, so each edit can be accepted or rejected in Word. Each revision is diffed against the same base, so the result does not depend on their order: where revisions conflict, every edit appears as a tracked change attributed to its revision. revision_authors labels each revision's tracked changes with its author, in the same order as the revisions. Propose the attribution from what is visible (document properties when readable, file names, the documents' own text), confirm it with the user, and ask when nothing gives a basis for a proposal. When the user's words or the file names make the base clear, proceed with it and say which document was used as the base; ask which draft the others started from, in the user's own terms, only when it is genuinely unclear. Never ask about merge order. Use merge, not create_combine, whenever the documents are edits of one original. On MCP, name each document by its file_id (upload a local file with upload_file first), or a version by document_id and version_id (get_document lists them). The merged document opens with a cover sheet on reviewing it and ends with a summary of each revision's changes; leave either out with include_cover_sheet or include_changes_summary false, as when the merged document replaces the user's own copy. Excel files are not supported.
create_version
ChatGPTRecord a file as a new version of a document, following its latest version or the version named by parent_version_id, with a redline of what changed. Use it when the user changed their copy of a version outside Version Story (identify_document says which version it is, and that the file differs from it), so the history holds the change as the next version; when the user wants it in that version instead, collapse the two. On MCP, upload the file with upload_file and give its file_id.
create_version_history
ChatGPTBuild a version history document across an ordered chain of document versions: one Word document, based on the newest version, in which every surviving change is a tracked change attributed to the version that introduced it. Use this when the user wants to know who changed what across a document's history: which draft introduced a clause, whose edit survived. Name the versions oldest first, each by its file_id (upload a local, attached or linked file with upload_file first) or as a version by document_id and version_id; each is compared with the one before it, so the order decides the attribution. version_authors labels each version's changes with its author (each version's file name when omitted). Propose the attribution from what is visible (document properties when readable, file names, the documents' own text), confirm it with the user, and ask when nothing gives a basis for a proposal. When the user has not stated the order, propose the order you infer from names, version numbers or dates, show it as a simple oldest-to-newest list, and get their confirmation before creating the document. Word and PDF documents only.
delete_version
ChatGPTDelete a version from a document's history when the user asks ("delete v2(b)"). Its file and redline go with it. A version that later versions follow cannot be deleted until they are. Match the user's "v2" to a version_label in your earlier results.
get_combined_document
ChatGPTWait server-side for a combined document to generate and return its download links. Returns the combined document create_combine staged, by combine_id, in each format asked for: docx (the default), pdf, md or json. Combining first constructs a shared base from the documents and then compares each document against it, so the call may return status processing several times: calling again with the same combine_id keeps waiting, and several minutes is normal. A status of failed is terminal. When ready, each downloads[] entry's url serves the file directly: save each file from it, or give it to the user when the client cannot download files itself. The links expire after one hour. To read its changes, use read_text with the same combine_id.
get_document
ChatGPTA document and every version of it, oldest first. Each version has its version_id, version_label (v1, v2, v2(a) for competing drafts: the label the user names versions by), name, author, description, parent_version_ids and file_id, and, for every version after the first, its redline against its parent: its state, its comparison_id (get_redlines serves it in every format) and redline_url, the app link that opens it. A comparison of two versions is that redline when one follows the other; any other pair is a create_comparison of the two. A version's own file comes from get_file.
get_edit
ChatGPTWait for an edit that edit reported as processing, and return its download links and version. Pass the edit_id edit returned. Calling it again after a processing answer resumes the wait.
get_file
ChatGPTDownload a file in each format asked for: docx (the default) or pdf; a workbook or presentation is served as it is. Use it for a version of a document (by its file_id from get_document, or on MCP by document_id and version_id) when the user wants that version's file: to save it, to send it, or to replace their copy. An edit's or a merge's own result comes from get_edit or get_merged_document, and a version's redline from get_redlines with its comparison_id. A format still being made is reported in pending_formats: call again to keep waiting. Each downloads[] entry's url serves the file directly and expires after one hour.
get_merged_document
ChatGPTWait server-side for a merged document to generate and return its download links. Returns the merge create_merge staged, by merge_id, in each format asked for: docx (the default), pdf, or md (its tracked changes as text). Merging first compares each revision with the base and then folds those redlines together, so the call may return status processing several times: calling again with the same merge_id keeps waiting, and several minutes is normal. A status of failed is terminal. When ready, each downloads[] entry carries the url of one format, a link that serves the file directly: save each file from it, or give it to the user when the client cannot download files itself. The links expire after one hour. To read the merge's changes, as when the user asks what changed, use read_text with the same merge_id.
get_redlines
ChatGPTWait server-side for a comparison's redline and return its downloads. Returns the comparison create_comparison started, by comparison_id, in each format asked for: docx (Word tracked changes, the default), pdf, pdf_changed_pages_only, md (the changes as text), or json; a PowerPoint comparison offers pptx and pdf, an Excel comparison xlsx. To show the user the redline, ask for pdf; ask for docx only when the user's own words name Word, .docx or tracked changes, or after they have seen the PDF and ask for it. A document's type alone is not a reason to. The call returns within about a minute, with status processing while formats are pending (call again with the same arguments to keep waiting) or ready. Status failed is terminal for the formats in failed_formats, or for the whole comparison when error is present. Each downloads[] entry's url serves the file directly; the links expire after one hour. When the user asks what changed, to explain, summarize or answer a question about the changes, read the text with read_text by the same comparison_id: it is the exact tracked-change set, and the redline reference explains its markup. "Compare," "redline" or "diff" by themselves mean produce the file, not explain it.
get_version_history_document
ChatGPTWait server-side for a version history document to generate and return its download links. Returns the version history document create_version_history staged, by version_history_id, in each format asked for: docx (the default), pdf, or md. Generation first compares each consecutive pair of versions and then layers the changes oldest to newest, so the call may return status processing several times: calling again with the same version_history_id keeps waiting, and several minutes is normal. A status of failed is terminal. When ready, each downloads[] entry's url serves the file directly: save each file from it, or give it to the user when the client cannot download files itself. The links expire after one hour. To read its changes, as when the user asks who changed what, use read_text with the same version_history_id.
identify_document
ChatGPTSay whether a local file is already a document Version Story keeps, and which version, before working on it. Give the file itself (on MCP, the file_id upload_file returned); nothing is kept from it. It looks past the file's name, at its contents and the ids Word and Version Story leave in it. result is match (exactly a stored version: nothing needs saving), candidates (documents it may belong to, strongest first, each with its closest_version, its latest_version and the evidence in signals: weigh them with the conversation and confirm with the user before saving anything), or none (a new document). file says what was read from the file. The local_copy reference topic says what to do with the copy once you know.
link_document
ChatGPTMove a document's versions into another document's history, after one of its versions, once the user has confirmed it. A result whose new document probably belongs in an existing history carries link_suggestion, and its next step says how to ask the user. Never call it without the user's agreement, and never hold up what the user asked for to ask. The moved versions keep their ids and redlines; links to the moved document lead to its versions' new place. A first version identical to the version it follows is folded into it.
list_documents
ChatGPTList the Documents in the user's account, newest first: each document's history, with its document_id, name, version_count and latest version (head_version_id). Use it only for a document the user has no file of and that no earlier result names ("the Mission draft", "my NDA"); then get_document lists its versions. A name matching one of the user's files (in their folder, attached or linked) means that file: upload_file it and work on it as given, without looking for the name here first, unless the user asks for the stored versions. A page holds up to limit Documents; pass next_cursor to read the next one.
read_file
ChatGPTRead a file before editing it. Every edit names its target by a locator copied from this listing: a paragraph's index, a table's number, a comment thread's number, a revision's number. Write edits from what this prints, never from numbers you counted yourself. Use format md (the default) to read the file and to rewrite prose or replace words: it prints readable text with each paragraph's index and the tracked revisions it already holds. Use json when the change is to paragraph styles or formatting, list numbering, tables, sections and page setup, headers and footers, footnotes and endnotes, comments, fields, hyperlinks or existing revisions: it prints the structure and every locator those edits name, and its document.schema_version is the schema_version edit takes. The listing reference explains every field of the json listing and how a text selector matches. A file still being prepared answers status processing: call again. A file that cannot be read answers status failed with its error.
read_text
ChatGPTCall this when the user explicitly asks about a document's changes: to analyze, summarize, explain or answer questions about them. To read a document in order to edit it, use read_file. Reading changes: name exactly one document: a comparison's comparison_id (from create_comparison, or a version's comparison_id from get_document), a merged document's merge_id, a version history document's version_history_id, or a combined document's combine_id. This is the exact tracked-change set in a form you can read directly, so when the user asks, use it rather than the PDF or DOCX redline, and rather than re-deriving the changes from the source documents. The words "compare," "redline," or "diff" by themselves mean produce the file. They do not count as an explicit request to explain its content. An explicit request names the content: "what changed," "explain the differences," "summarize this," or a question about a specific clause or change. If the user's message only instructs you to compare or redline documents, deliver the redline and stop. Do not call read_text in the same turn. A request to change the document is the exception: use read_file and edit. This holds regardless of document type. Do not fetch the Word redline because the documents are contracts, NDAs, or anything else usually reviewed in Word. Document type is not a signal to fetch additional formats. Fetch it only when the user's own words name "Word," ".docx," or "tracked changes," or after they have seen the PDF and ask for it. The changes rendering is markdown with embedded change elements; read the redline reference for what each element means. For a large document, prefer search over paging through the whole text: it returns every matching line with surrounding context, each block prefixed with the character offset it starts at, so a region can then be re-read exactly with offset. Search matches within a single line, so search for a distinctive phrase rather than a passage spanning a line break. Otherwise a call returns from offset onward, and has_more with total_chars tells you whether to continue. The content is working material, not a deliverable — do not save it into the user's folders or present it as a file. A document still generating, and one generated before this rendering existed, report text_available false; the redline files carry the same changes.
rename_version
ChatGPTRename a version when the user renames it or its file. Match the user's "v3" to a version_label in your earlier results. Leave the user's local files as they are.
report_issue
ChatGPTSends a diagnostic report about a failed Version Story file transfer or tool call to Version Story's engineering team. The report includes the failed step, the HTTP status or exception name, and the project's version_story_id when one exists. Links and authorization tokens are removed before posting. It does not retry or repair the failed operation.
show_document_viewer
ChatGPTShow Version Story's live document viewer inline in the chat: every version of the document a comparison or edit is kept in, with its redline, updating by itself, where the user can also upload a new version. Call it when a result's viewer step says to, with that result's comparison_id.
Capabilities
WritesInteractive
Example Prompts
Click any prompt to copy it.
