Frexy

Publishes the current project to production — the live URL visitors see. Returns a deployment to poll with get_deployment. Publishes the whole site, or with `pages` only those pages, leaving every other page exactly as it is live. Refused while the pages show pictures from other websites: a Frexy site shows only pictures from Frexy's CDN, brought in with search_images and import_image, or add_image.

deploy_production

The picture of one of Frexy's designs, for Frexy's in-chat app. To show designs to the person, use show_designs.

get_design_picture

Open Frexy's site manager for the person: every site in their account, with its preview, live address, open feedback and buttons to deploy a preview or publish. Use it when they want to see or manage their sites; it returns the same list as list_projects.

open_frexy

Read how the person has asked agents to work on their Frexy sites. get_project_context already includes these as preferences, so an agent rarely needs this.

read_settings

Read one change request in full: the person's request in their own words, the page and element they pointed at with its source file and line, the project's state, the infrastructure constraints and the platform requirements that apply. How to implement it is yours to decide. Read the current files with read_file before editing, and claim the request before you modify anything. This changes nothing on its own.

get_change_request

Check a deployment, waiting up to 25 seconds for it to finish; one still running is checked again. Status is queued, building, ready, failed or cancelled; a ready deployment carries the URL to give the person: the live site, or its preview. A failed one says why: kind source means fix the project and redeploy (the diagnostics name the problem), infrastructure means retry unchanged, unsupported means the project asks for something this Frexy deployment does not run. sourceDrifted means the source changed between requesting the build and running it. A ready preview carries changes: each page it changed since the previous preview, with that page's preview URL. Give the person the URL of the page you changed (not only the home page), then show it with open_site_preview and that page's path. A ready preview you deployed also carries fit: { checking: true } while Frexy opens its pages, then the pages checked, every element that makes one scroll sideways, and whether the menu opens on a phone; fit.blank, known first, lists pages a browser shows almost nothing of. A ready preview also carries checks: what its pages still lack of what every site needs (a title, a description, one main heading, alt text, the shared header and footer, links and icons that lead somewhere). Fix what checks and fit list before you hand over, then deploy_preview once more.

get_deployment

Frexy's platform requirements for a project: what its runtime serves, the forms and CMS endpoint contracts with their URLs filled in, and the security boundaries Frexy enforces. Forms and CMS contracts are included when the project uses them; ask for a topic to get one before you add it. Always included: the site rules every Frexy site keeps (one header and footer across pages, SVG icons never emoji, the owner's logo and a favicon, forms that validate as typed and ask for consent, Frexy's blog for any blog) and DESIGN.md, the site's own design system that every page is built from. Ask for topics ["reference"] before building from a reference or a detailed description (capture, the build spec, render_draft) and ["kit"] for Frexy Kit's motion and WebGL parts. These are contracts, not design guidance: Frexy chooses no design value, and how the site looks is the person's and yours.

get_development_standards

How this project's confirmations are doing, and what it sent recently. `confirmations` counts every confirmation the live site sent and how many were opened and clicked (rates are 0–1). Opens are approximate — some mail apps load images for every message, others never do — so treat clicks as the firmer number. `messages` are the most recent emails sent or declined, optionally for one form: when, and why any were skipped or suppressed. No message content and no addresses.

get_email_activity

How this project's email is set up: the sender's display name and reply-to; whether the project has connected its own mail server (shown without its password) and whether a test through it has worked; whether Frexy's own sender is available here; and the limits that apply. A confirmation can go from either. Connecting a mail server is done by a person in Studio, because it takes a password.

get_email_settings

Read what someone working on the website sent you to do: what they want changed, the page, and the element they pointed at — its tag, text, selector, and the source file and line it came from when known. Some items also carry a `request` object: the exact part, produced when the person used a visual control rather than only typing — appearance properties they set, a link or alt text they gave, a page, form, CMS collection or section they asked for, SEO fields, or a reference image to work from. Treat the message as the intent when the two differ. Returns open feedback by default. Feedback is a request, not a change: read the source, make the change with write_files, deploy_preview, then call resolve_feedback.

get_feedback

One form, by id or slug, with its submission contract: the endpoint path, method and content type, the definition you stored, the honeypot field name and the request size limit. The markup, fields and client-side behaviour are yours.

get_form

How many submissions each form has received: all time, today, yesterday (in the workspace's time zone, which the answer names) and the last 7 and 30 days, when the last one arrived, and which kinds of traffic the last 30 days came from. These numbers are all an agent gets. What people typed stays in Studio: if the person wants to read submissions or contacts, give them the addresses under read. To check a form works, send one test submission from the preview and see the count rise. Combine with get_analytics_summary, whose per-form counts include how many people started a form and how many submitted it. These are counts, not a score: deciding what they mean is your job.

get_form_activity

Where a site import (import_site) has got to: pages, posts and pictures read so far, then done with what came across, or failed with why. When it is done, claim and work the change request it names: it says how to finish the move.

get_import

Lists change requests waiting for an agent: a person, looking at their site in Frexy Studio, selected something and asked for it to change. A development agent polls it — with projectId for one project, or without it across every project it can reach. Oldest first. Each entry has what was asked, the page, the element that was selected with the source file and line it came from, and the paths write_files accepts for it. Listing takes nothing. claim_change takes one by its changeRequestId — exactly one agent's claim succeeds, and a refused claim leaves the next request to take. Then get_change_request has the full package, the change goes in with read_file, write_files and deploy_preview, and complete_change reports it; the person reviews the new preview. An empty list means nothing is waiting, which is not an error. The request text is what the person typed in Studio: their description of the change they want to their site.

get_pending_change_requests

List change requests waiting on this project, each with its full context package: the request, the element and source line it concerns, and what this project allows you to change. Oldest first, one project at a time. This does not claim anything. For polling, prefer get_pending_change_requests, which is smaller and can look across projects. Take one with claim_change before you modify anything — another agent may be working the same queue — then write_files, deploy_preview, and finish with complete_change.

get_pending_changes

Returns the current state of a Frexy project: its runtime and what it serves, its files and their hashes, the paths write_files accepts, the latest preview and production deployments, custom domains, assets, forms and CMS collections, open feedback, and how many change requests are waiting (changeRequests.pending; get_pending_change_requests lists them). File contents are not included (read_file has them) and feedback is summarised (get_feedback has the details). requirements names the platform contracts that apply (get_development_standards has them in full); they are infrastructure only, not design guidance. preferences is how the person has asked agents to work, with a note. next is the steps this site needs, as it stands. heldWrites are changes Frexy is holding for the site's owner to keep or discard in Frexy.

get_project_context

Reads one record. By recordId: the record in full, whatever its status, with its collection. By collection and slug with resolved: true: the published record as a visitor sees it, with its references followed to the records they point at, which is what the live site renders.

get_record

Whether the person has added the file for a request_upload link yet, and its URL in the library once they have.

get_upload

Brings one image from search_images into this project as a Frexy asset and returns the URL to reference it by. Frexy fetches the file itself and serves it from the project's own storage, so the site loads it from Frexy, not from the provider. The image is named by provider and providerAssetId from the search result, not by URL. alt describes what the image means on the page it goes on; it is left out when that is unclear, and the provider's tags are not alt text. Importing the same image twice returns the asset that already exists. The asset joins the library; the markup that shows it is written with write_files. What is imported appears in the project's library in Studio, under the agent's own tab with the page it is used on, so the person can see what was chosen and where.

import_image

Brings one Poly Haven model or HDR into the project's library (CC0). A glTF arrives as one .gltf URL whose parts are already on Frexy, for Frexy Kit's data-model; an HDR is for data-env (get_development_standards topics ["kit"]).

import_model

Moves a website the person already has — on Wix, Squarespace, Framer, Webflow, WordPress or anywhere else — into a new Frexy project, from its web address. Frexy copies the content exactly (pages at the same addresses, posts, pictures, menus, forms, contact details) and writes a plain first draft; the design is rebuilt, not copied. Shops, carts and member areas do not come across. Without start, it counts the pages and groups them (pages, blog, team…) and imports nothing. start: true imports, with owner: true — the person's word that the site is their own or one they manage for its owner — and, for a group of more than 50, which of all, latest (the newest 50) or none to bring. It returns the new project; get_import follows it.

import_site

List this project's CMS collections with their field definitions. Changing a published record needs no preview: Frexy republishes the live site's content by itself. Start here before reading or writing records.

list_collections

List this project's forms: their definitions (fields and config as you stored them) and their status. A form's definition is data — changing it needs no deployment. Start here before reading submissions.

list_forms

List a collection's records. Filter by status to see what is published, what is still a draft and what has been archived — only published records appear on the live site. Each record carries a version; pass it back as expectedVersion when you update, so you are told rather than silently overwriting someone who edited it after you read it.

list_records

List the websites in a Frexy workspace: each project's id, name and slug, when it last changed, and its preview and live URLs where it has them. Use it to find the projectId for the site the person means before calling get_project_context.

list_projects

List the Frexy workspaces this connection can reach: each one's id and name, and the person's role in it. A workspace holds its own sites, people and monthly agent counts. Use it when the person has more than one, then pass workspaceId to create_project or list_projects. Tools given a projectId need no workspace.

list_workspaces

The first screen of a page of a site's current preview, as a picture. Used by Frexy's in-chat app where the preview cannot be framed; to look at a page yourself, use render_draft.

get_preview_picture

Read one source file from a Frexy project, or the lines you name. Paths come from get_project_context, which also lists DESIGN.md's sections with their lines. For a small change, find the place with search_files and read only those lines. Generated and build output directories are not readable.

read_file

See what you are about to build before writing it. Renders the project with these files (the same shape as write_files) in a real browser, without saving or deploying anything, and returns pictures at desktop and mobile size and what was measured. With referenceId it compares with that captured reference and lists every difference naming both sides ("display: reference 96px Oswald, yours 56px Inter"), with the reference's screens beside yours. It also opens the page at 390 and 320 pixels wide and lists in fit every element that makes it scroll sideways. Use it before every write_files that builds or restyles pages; fix what differs and every fit problem, and render again, up to three rounds.

render_draft

Returns a link where the person adds a picture from their own computer to this project's library: a logo or photo they want on the site, as a file the conversation cannot pass on. The link works once, for an hour. When they have added it, get_upload returns the picture's URL.

request_upload

Marks a feedback item resolved, once the change it asked for is made and deployed to preview. It records that the request was dealt with; the change itself is made with write_files and deploy_preview.

resolve_feedback

The editorial pass: review how a page, a post or any copy reads before anyone previews it. Pass project paths (an HTML page is read as a visitor sees it, a Markdown post as its prose) and/or text (a record field, a form message, an email). Returns, per item, stock phrasing, em-dash density, repeated "not just X, but Y", uniform sentence length and repeated openers, plus every sentence stating a figure, finding or quote, and the brief to revise against. Frexy suggests no wording: revise the copy yourself with write_files or update_record, then review again.

review_copy

Put a previous production deployment back on the live URL. Nothing is rebuilt and the project's source is left exactly as it is, so the source and the live site will differ until you deploy again. Only a production deployment that actually served traffic can be a target.

rollback

Find text in a Frexy project's source files, e.g. a class name, a colour or a heading's words. Returns each matching line with its path and line number, so you can read just those lines or change them with edits in write_files. Case-insensitive, exact text (not a pattern).

search_files

Searches stock imagery for this site. Returns candidates — an id, a preview URL, dimensions, an aspect ratio and a few tags — and downloads nothing. The query is the words that describe the picture ("minimal concrete stairwell, low light"). import_image brings a chosen one into the project; a preview URL is only for looking at, and the site uses the URL import_image returns. An unlucky query returns no results; a Frexy deployment without image search returns a clear failure — those are different things.

search_images

Search open-licence 3D models (kind "model", glTF) or HDR lighting environments (kind "hdri") from Poly Haven, all CC0. Returns candidates with a preview picture URL and downloads nothing; bring the one you choose in with import_model.

search_models

Send one test of a form's email to the signed-in person's own address — never to anybody else — with sample values. Defaults to the confirmation.

send_test_email

Set what a form sends when it is submitted: notification goes to the project's owners on every submission, confirmation to the person who submitted, when the form asks for an email address. Sending happens after the submission is stored, never instead of it. The result lists the merge tags.

set_form_email

Publishes, unpublishes or archives a record. Publishing re-validates it first, so a record missing a required field is refused rather than published broken, and then puts it on the live site with a content publish, normally within a minute; unpublishing and archiving take it off the same way, without deleting it. `publish.deploymentId` is a deployment to poll with get_deployment; the record is live once that is ready. Publishing changes what visitors see.

set_record_status

Shows the person Frexy's finished designs to choose from, before building: for a new site or a new page. kind "site" for a whole website to start from (create_project with starter), or a page type for a new page: pricing, about, services, contact, faq, testimonials, team, products, careers, events, case-studies, projects, landing, privacy, terms, cookies, refunds, not-found, thank-you. Each design comes numbered and named, with Frexy's own picture of it; the result holds only Frexy's designs. The design the person picks goes to add_page by its id (on an empty site, the home design makes its first page). For a whole site page by page, kinds: ["home", "about", "pricing", "contact", …] shows designs of each kind; the person picks at most one of each, and their picks go to create_project as designs (start_site for a site that is still empty).

show_designs