PracticPro

Check the current OAuth connection and accessible companies without switching company or disconnecting.

practicpro_connection_status

Check backend receipts for an earlier operation before retrying an uncertain action. Results distinguish completed, rejected, pending and unknown dispatches.

practicpro_operation_status

Build, edit, and reorganize PracticPro document files (estimates, proposals, contracts, change orders). Actions: render - Turn a shape spec into editor-safe markup and show it to you. Writes NOTHING, so styling costs no saves. Use it before any decorative edit. find - Search the document's TEXT for a phrase; returns which column and which block holds it. START HERE whenever the user names wording rather than a column. read_column - Read a column's FULL stored HTML as INDEXED BLOCKS + a base_token. REQUIRED before edit_column. view_page - See a PDF page as an image with x/y reference grid add_fields - Place new fillable inputs on a PDF page row add_rows - Build new doc content (text/input/items_table/empty), any mix in one call move_fields - Reposition or resize EXISTING input fields (never re-add) edit_column - Change content (blocks[] for targeted edits, or column_html to replace the body) or config (submitted_column_form) delete_rows - Bulk delete rows by id delete_column - Delete a single column by id reorder_rows - Replace the row order with the supplied sequence Required arguments by action (action is always required): render -> shapes (file_id optional, to match that document's colours) find -> file_id, query read_column -> file_id, column_id view_page -> row_id add_fields -> file_id, row_id, fields add_rows -> file_id, rows move_fields -> file_id, fields edit_column -> file_id, column_id, and EXACTLY ONE of blocks | column_html | submitted_column_form. On a TEXT column (blocks or column_html) base_token is also required - get it from read_column. submitted_column_form is for INPUT columns only and takes no base_token. delete_rows -> file_id, row_ids delete_column -> file_id, column_id reorder_rows -> file_id, row_ids Decision tree: - User named WORDING, not a column id? -> find (never guess a column id, never grep - grep reads page JS, not document text) - Need to see what a column actually says? -> read_column - Putting NEW fields on a PDF page? -> add_fields - Building NEW document content from scratch? -> add_rows - Field landed in the wrong spot? -> move_fields (NEVER add_fields again) - Changing wording in existing prose? -> read_column, then edit_column with blocks[] - Making something LOOK better / adding a callout, band, table or divider? -> render (free, writes nothing) to see the markup, then edit_column with that shape as a blocks[] entry. Do NOT hand-author decorative HTML - that is what costs 4-6 rewrites. - Asked to start a section on a NEW PAGE? -> {shape:"page_break"}. NEVER CSS page-break-before, and never a styled <div> - both are destroyed by the editor. - Styling you pass INSIDE a shape's text is still yours to get right: a styled <div> or a padded <ol> in there re-breaks it. Put decoration on the shape, wording in the text. - Rewriting/restructuring a whole section? -> read_column, then edit_column with column_html - Need to change recipient / type of an existing column? -> edit_column - Need to remove rows or columns? -> delete_rows / delete_column - Need to reorder? -> reorder_rows - Repeating a similar field many times? -> use copy_from_column_id CHANGING EXISTING TEXT - always read_column first, then pick ONE of two write shapes. 1. read_column returns the body as numbered top-level blocks, plus a base_token. 2a. FIXING WORDING (the common case) -> edit_column with blocks: blocks: [{"index": 7, "html": "<p>the corrected paragraph</p>"}] Only the blocks you list change. Everything else is preserved exactly, so you do not have to resend - or even re-read - the rest of the section. Use this for typos, a changed sentence, a swapped heading. html:"" deletes a block; one entry's html may contain several elements, which is how you insert. 2b. RESTRUCTURING THE SECTION -> edit_column with the COMPLETE column_html. That REPLACES THE WHOLE BODY: it is not a patch and there is no merge, so whatever you leave out is destroyed. Rewriting, reordering and improving the markup are all encouraged; it may end up much longer or shorter, which is fine and is not checked. Never include the [n] markers - they are labels, not content. Prefer 2a unless you are genuinely reshaping the section. Resending a whole contract to fix one word is slow, and every character you retype is a character you can get wrong. edit_column REFUSES any body write without a matching base_token, because writing prose you never read is how documents silently lose content. A stale token means someone edited underneath you (often the user's own editor auto-saving) - the error hands you the current body, re-indexed, so you can re-apply your change to it. NEVER build column_html from what a page or /preview rendered: that is flattened display text, not the stored markup, and round-tripping it strips structure and drops content. The "File layout" section on a document page shows row_ids and column_ids.

practicpro_document_editor

Read or edit the line items (and adjustments) on a proposal/estimate/contract file OR a client invoice. Users call these "line items", "items", "the items table", "prices", or interchangeably "the invoice" - this tool handles both cases. Pick target by the record being edited: a /files/id/N dynamicfile -> target={file_id:N}; a /job/X/invoice/Y client invoice -> target={job_id:X, invoice_id:Y}. When the amount or any field on an existing line item is wrong (wrong amount, missing decimal, off by a factor), use update with that row's index and only the keys you're changing - e.g. changes:{price: 1000}. Other fields on the row are preserved automatically. Five actions: list (read, no change), add (append item or items), update (modify one row at index, merging only the fields in changes), remove (delete one row at index), replace_all (wipe everything and set the whole list - pass items:[] to clear). scope defaults to "items"; pass scope="adjustments" to edit discounts/fees/surcharges instead. To let the client CHOOSE a line on a file ("make the skylight optional"), update that row with changes {optional: true, optional_default_on: true|false} - never add a separate checkbox field; list returns optional, optional_default_on and optional_uid, and every later save keeps them. Always prefer this tool over raw POSTs to lineitems_update or /invoice/.../update - those are full-replace foot-guns that wipe everything you forget to include.

practicpro_line_items

Fetch specialized PracticPro knowledge on a specific topic. Not a preface: do not call it on every turn, and never to pad an answer you already have. But DO call it before answering any question about how PracticPro works or how to do something in it. Answering that kind of question from memory is how the agent tells users things that are not true, and one call is cheaper than a wrong answer. This description used to cite a 2026-08-26 measurement claiming the runs that called this tool answered "I have finalized an agreement but still have areas to fill in" correctly. That claim was removed on 2026-09-01: the help content did not contain the real remedy (Take Action -> Reverse File) at the time, so calling the tool could not have produced a correct answer, and a sweep of real chats found the runs that DID read the pack inventing a way out that does not exist. The content has since been fixed. Do not restore a measurement to this description without a rerun behind it. Available topics: scenarios, entity_model, custom_fields, create, billing, client_portal, files, templates, custom_pages, scheduling, assignment, phone, permissions, email, lifecycle, glossary, websites. Call with no topic to see the list and what each covers. A word the user used (notifications, invoices, calendar) finds its topic too.

practicpro_get_help

Inspect the current page. Requires a prior practicpro_navigate call in the same session (reads from the last navigated page). Three modes: 1. Page sections: pass "forms", "actions", "navigation", "uploads", or "ui_actions" to see that section from the current page. 2. Full content: pass "full_content" to read the complete page body text without truncation. Use when practicpro_navigate says "(body truncated)". Pass offset to read from a specific character position. 3. JS code: pass a button label (e.g. "Save Invoice") or function name to see the code it triggers. Use when you need details beyond the navigate summary.

practicpro_inspect

Open or act on a PracticPro route. Returns page content and can perform requested changes, deletions or sends; migrated action routes are dispatched as POST. Use practicpro_read for guaranteed read-only access. To find an entity by name, use /search?search=<term>.

practicpro_navigate

Operate a website the user's own company hosts with PracticPro: WordPress content, WP-CLI, the site database, files under that site's web root, and its logs. Scope is the websites on this company's account - website_id is checked against them on every call - plus read-only server health. Changes are real and visitors see them immediately, so work the way you would on any live site: read the current state before you change it, and get the user's approval before anything destructive. Credentials are out of scope: the three change_*_password server actions are refused, since reaching them would mean a secret travelling through this conversation. If the user needs one rotated, tell them to do it in the hosting control panel. Never ask for one, and never invent one for them. You can BUILD a site with this. Pages, posts, menus, plugins, themes, options, theme files, redirects, DNS, SSL. Never tell the user to go do it in WordPress themselves, and never hand them a to-do list of things to click in wp-admin - you have the same reach they do, and more. WORK IN THIS ORDER, every time: 1. LOOK FIRST. action:'info' for what the site is (WP version, PHP, plugin counts, disk, DB size). action:'wp_cli' with "plugin list --format=json" / "theme list --format=json" / "post list --post_type=page --format=json" to see what is actually there. Never assume a theme, plugin or page builder is installed - check. 2. CHANGE. Prefer the highest-level tool that does the job: 'wp_cli' or 'wp_rest' for anything WordPress models (pages, posts, menus, options, plugins). Drop to 'write_file' only for theme/template files WordPress has no command for, and to 'sql' only when neither can express it. 3. VERIFY - this is not optional and you do not get to skip it. "Saved" and "working" are different claims and you must prove the second one: a. Re-read the object: 'wp_rest' GET the page id, or 'wp_cli' "post list --post_type=page --format=json". b. action:'fetch_page' on the real URL. This is the only check that proves a visitor sees the page - a page can exist in the database and still 404 on stale rewrite rules, white-screen from a theme fatal, or be served stale from cache, and every other check says success through all three. Read the verdict line it returns FIRST. c. action:'error_log' for PHP errors your change introduced. A change you have not fetched back is a change you cannot claim. Say what you verified and how. If fetch_page comes back BROKEN, fix it or roll back - never report success. Actions: - info: site facts. Cheap, start here. - fetch_page: GET one of this site's own public URLs and see exactly what a visitor gets - status code, redirects, and the HTML, plus a verdict flagging 404s, PHP fatals, DB errors and maintenance mode. Use it after every change, and before one when you need a baseline. - wp_rest: WordPress REST API. {endpoint:'/wp/v2/pages', method:'POST', data:{title, content, status}}. Best for creating/updating content with real HTML bodies. - wp_cli: WP-CLI over SSH, run as the site's own user. PAGE AND POST BODIES GO IN content, NOT in command: put "-" where the body argument belongs and pass the HTML in content. Prose in the command breaks on the first apostrophe, and there is no length limit worth fighting - content is a separate channel for exactly this reason. Judge the RESULT, not the absence of an error: a command that returns empty data or carries "warnings" did not do what you asked, even when the call itself came back fine. {command:'plugin install classic-editor --activate'}. Allowed top-level: post, page, media, plugin, theme, option, menu, widget, search-replace, user, core, site, comment, term, taxonomy, rewrite, cache, transient, cron, sidebar. Blocked: eval, shell, config get/set, db drop, user create/delete/role. No shell metacharacters (; && || | ` $( ) - one command, no pipes. Add --format=json when you want parseable output. - sql: MySQL on the site DB. Read-only unless you pass allow_write:true. DROP/TRUNCATE/GRANT/INFORMATION_SCHEMA are blocked outright. Use wp_cli first - it keeps caches and hooks correct where raw SQL does not. - read_file / write_file / list_dir / search_files: files under the site's public_html. Paths are RELATIVE to public_html (e.g. "wp-content/themes/twentytwentyfour/style.css"), never absolute, no "..". write_file replaces the whole file and caps at 500KB - read it first, edit, write it back complete. wp-config.php, .htaccess, wp-admin/, wp-includes/ and the drop-ins are protected and will refuse. - error_log / access_log: the site's real logs. Check error_log after any file, plugin or theme change - this is how you find out you broke something before the user does. - server_action: anything else HestiaCP exposes - DNS records, backups, SSL, cron, permissions, redirects. {hestia_action:'list_dns_records', params:{}}. Consequential actions require approval of their exact payload through the connected client. A user_confirmed argument grants no authority. Executable files, freeform SQL and credential administration require the secure website interface. If the site is not hosted on our servers, wp_cli/sql/files are unavailable and will say so - wp_rest may still work if the WordPress API is connected.

practicpro_website

Read the resolved recipients, content and attachments for an email send or retry without sending. Review the result and pass its revision as expected_action_revision to the subsequent navigate/submit action. Scheduled campaigns require the PracticPro interface.

practicpro_preview_action

Run a filtered list query on PracticPro. Use this for every "show me ...", "list all ...", "how many ...", "what is due/overdue/pending ..." question - replaces manual /cp_filters URL construction. The tool validates your entity_type and filter shape against the live company schema BEFORE the query runs and returns clear errors with valid options on any mismatch. Available entity_types and filter_blocks are discovered at runtime from GET /filters/schema; you do NOT need to know them in advance, just pick the obvious entity_type for the user noun (e.g. "invoices" -> job_invoice, "photos" -> uploaded_media) and the tool will tell you if it is wrong. filters is a dict of filter_blocks; one or many can be stacked in the same call (invoices_filter + jobs_filter scopes invoices to a specific project type). Inner keys of each filter_block must match GET /filters/schema?filter_category=<category>. action="view" (default) navigates to the rendered /cp_filters page, whose header states the TOTAL as "Filtered Results (N)"; action="data" calls /cp_filters/load_data and returns the rows themselves. FOR A "HOW MANY" QUESTION USE action="view" AND READ THAT TOTAL - do NOT count rows by hand. Measured 2026-08-22: asked to count 25 overdue invoices from a data response, the agent answered 24 on one run and 21 on the next, from the same unfiltered-by-nothing result set. The rows were all there; counting them was the unreliable step. Use action="data" when you need the rows (to name them, open one, or read a field), not when you need their number.

practicpro_query