Tools
Files and documents
Reading, writing and changing the files on your computer, making real documents, sheets and decks, and undoing any change Mori made.
What this family is for
These are the tools Mori uses to work with the files on your disk: find them, read them, write them, move them, pack them up and hand them over. They also make finished deliverables, a Word or PDF document, an Excel sheet or a PowerPoint deck, from text she writes herself.
Most real work starts here. Before she edits anything she looks at what is there, and when a job ends with "send me the file", the file came from this family.
Reading comes first
Mori reads before she changes anything, and she reads in the cheapest way that answers the question:
find_filesfinds files by name, newest first, andsearch_filesfinds the lines that hold a word or pattern.read_filereads several files in one call, which costs a fraction of reading them one by one. Long files come back in numbered chunks.read_anyis her default when you hand her a file of unknown type: it reads code, looks at pictures, pulls the text out of PDFs and Office files, previews a CSV and lists a zip.query_csvruns a real SQL query over a CSV, so a question about your data is counted, not guessed from a glance.ocr_imagereads the text inside a screenshot or a photo with your system's own text recognition, which is cheaper than looking at the picture.
Edits are surgical, and checked against the disk
For a file that already exists, Mori changes only the part that needs changing with edit_file: she names the exact text to replace and what replaces it. The tool refuses an edit to a file she has not read first, and refuses again if the file changed on disk since she read it, so she never edits from a stale copy. A Jupyter notebook gets notebook_edit, one cell at a time, so its format and outputs stay valid.
Every edit shows as a row in the turn that opens into the real before and after, worked out from the bytes on disk. After the turn, the files she wrote are checked on disk and the reply says so. See Proof, not promises.
Every change can be undone
Before Mori overwrites or deletes a file, its earlier contents are saved as a checkpoint in the app's own folder. The last ten checkpoints of each file are kept; a file over 10 MB is not copied.
rollback_filebrings one file back to how it was before her last change, and saves the current state first, so a rollback can be undone too.list_changesanswers "what did you just change?", andundo_changesrestores every file she changed in the last few minutes. A file she created is removed again. She lists the changes before undoing, and reports any file that could not be restored instead of calling it a clean undo.- Deleting a file saves a checkpoint first. Deleting a folder moves it to your Trash, and the result says so.
Real documents, sheets and decks
When you want something to send, not a text file, Mori writes the whole content and the tool lays it out:
create_documentmakes a Word file or a PDF from headings, lists, quotes and tables: reports, letters, proposals, memos.create_spreadsheetmakes an Excel file or a CSV: budgets, trackers, exports.create_slidesmakes a PowerPoint deck that opens in PowerPoint or Keynote.
For a deck you shape on screen, see Decks.
Packing up and handing over
A build usually ends with a hand over. create_zip packs a folder and remembers the zip, so the next step can say "the zip you just made" to email it or upload it. download_file saves a file from a link, to Downloads unless a place is named, and export_session writes a thread out as clean Markdown or a styled HTML page in Downloads, with live keys scrubbed out.
build the site write_file, edit_filepack it create_zip -> site.ziphand it over send_email attachment: "the zip you just made"Permissions and the rails
Listing a folder, reading a file, finding and searching always run while Agent Mode is on. Everything else here, the readers for PDFs, pictures and sheets included, follows the File Writing switch in Settings > Permissions; turn it off and Mori refuses them, at every permission level. At the Safe level only the plain reads run.
Some files are never written by a tool, and some only when your own words name them: git hooks, CI workflows, editor settings and agent instruction files wait for your words, and Mori's own settings file is never written at all. See Asking and the safety rails.
Each description below is the exact text her model reads when it decides which tool to call.
List files and folders in a directory. `path` must be a DIRECTORY and nothing else: a full path (/Users/name/Projects) or a plain folder name (Downloads, Desktop, Documents, home). Never pass a fragment of the user's sentence such as "newest few", pass `sort` and `limit` for those. Every entry comes back with its size and last-modified time.
Read one file, or SEVERAL AT ONCE with paths. Reading five files in one call instead of five costs a fifth as much, so pass paths when you know what you need. Large files come back in line-numbered chunks, pass offset to continue.
Open ANY file and understand it. Hand it a path and it auto-detects the type: code (reads the text), images (SEES them with vision), PDFs and Word/PowerPoint/Excel (extracts the text), CSVs (previews, then points you at query_csv), zips (lists what is inside), audio/video (metadata), a folder (lists it), raw binary (identifies it). Your DEFAULT when the user gives you a file or you do not know the type.
Find files BY NAME with a glob, the counterpart to search_files, which searches file CONTENT. Use it to locate code before reading it: "*.test.ts", "src/**/api*". A pattern with no "/" matches the filename at any depth. Results come back newest-first.
Search a directory tree, or one file, for a string or regex and return matching file:line results. Use this to find where code lives before editing it, and to search a saved full-output file named in a clipped result.
Get a file or folder's size, type, and modified/created times, without reading its contents.
Create a new file with optional content
Create a directory (and parent directories if needed)
Write content to a file (creates or overwrites)
Update an existing file with new content
Make a PRECISE, surgical edit to an existing file by replacing an exact snippet. STRONGLY PREFER this over write_file for a file that already exists. You MUST read_file the file first (the tool refuses otherwise, and re-refuses if the file changed on disk since your read). Pass old_string copied EXACTLY, whitespace included; it must be unique unless replace_all is true. For several changes to ONE file pass edits: [{old_string, new_string}, …] in a single call; all entries resolve against the original content.
Append text to the end of a file (creating it if needed). Use for logs, notes, or adding to an existing file without rewriting it.
Copy a file to a new location
Move or rename a file
Delete a file or directory (use with caution)
Edit ONE cell of a Jupyter notebook (.ipynb), replace its source, insert a cell, or delete one. Use this instead of edit_file on a notebook: a text edit breaks the line-array format and leaves a code cell showing output that its new code did not produce.
Extract the TEXT from a PDF file so you can read, summarize, or answer questions about it. Use for any .pdf the user mentions, reports, papers, invoices, contracts. If the PDF is scanned images (no text layer), it says so, use ocr_image on a page screenshot instead.
LOOK at an image file with your own eyes, the actual picture is attached to the conversation so you can see layouts, photos, charts, UI, colors, anything visual. Use for 'what's in this image', design reviews, checking a screenshot you took (take_screenshot returns a path, read_image it to verify your own work). For pulling text out of an image, ocr_image is cheaper.
Read the TEXT inside an image (png/jpg/screenshot) using the OS's built-in OCR, for screenshots, photos of documents, scanned pages, error dialogs. Give it a file path; get the recognized text back.
Run a real SQL SELECT over a CSV file, filter, aggregate, group, sort actual data instead of eyeballing it. The table is '?', e.g. "SELECT city, COUNT(*) AS n FROM ? GROUP BY city ORDER BY n DESC LIMIT 10". Numeric columns are auto-typed so SUM/AVG work. Use for any data question about a .csv.
Generate a polished, ready-to-send DOCUMENT (Word .docx or .pdf): reports, letters, briefs, proposals, memos. Write the FULL body yourself as rich Markdown (# / ## headings, **bold**, bullet and numbered lists, > quotes, | tables |). Saves a real file the user can open. Prefer this over write_file when they want an actual deliverable.
Generate a real SPREADSHEET (Excel .xlsx or .csv), tables, budgets, trackers, data exports. Saves a file the user can open in Excel/Numbers/Sheets.
Generate a PowerPoint DECK (.pptx), pitch decks, presentations, reports as slides. Saves a file the user can open in PowerPoint/Keynote.
Zip a folder or file into a .zip archive, use this to PACKAGE a site/app/project you built before emailing or uploading it. Pass the folder or file as source: a full path, a name, or 'the site/app you just made'. Returns the .zip path, and the zip is remembered, so right after, you can send_email it (attachmentPath: 'the zip you just made') or upload it. Typical flow: build the site (files) → create_zip the folder → send_email the zip.
Extract a .zip archive to a folder.
Download a file from a URL to disk. Defaults to the Downloads folder if no path is given.
Export a conversation transcript to a file in the user's Downloads folder, clean Markdown or a self-contained styled HTML page. Live credentials are always scrubbed; redact additionally strips injection-shaped lines. Defaults to the CURRENT conversation.
List every file Mori has changed recently in this chat, newest first: the answer to "what did you just change?". Use it BEFORE undo_changes so you can tell the user exactly what would be restored. It needs no path. Anything whose snapshot has rotated away is marked NOT restorable, so never promise that undo.
Undo EVERY file change Mori made in this chat in the last N minutes, restoring each file to the state it had before Mori's first change in that window. This is the "undo all of that" the user means after a bad edit, rollback_file only handles one path at a time and needs you to already know it. ALWAYS run list_changes first and tell the user what will be restored; this rewrites their real files. Reports restored and failed files separately, never describe a partial undo as a clean one.
List the saved checkpoints (auto-backups) for a file, newest first, so you know what rollback_file would restore.
Undo Mori's last change to a file, restores it to the state right before the most recent write/edit/delete. Mori auto-checkpoints every file before changing it, so this is a real undo. The current state is itself checkpointed first (so a rollback can be undone).