Sampled: ChatGPT · Gemini · monthlyReceipts kept · unsampled ≠ absentYou approve every change — verified live
mcp · customer-owned agents
Foliora for the agents you already run.
One Streamable HTTP server on this URL, five tools. Your agent reads what Foliora proposes for your site — every change with its exact before and after — shows it to you, and records your decision. On a site without a connected store it puts the approved wording on the page with the credentials it already holds and says so in the same call. Foliora reads the live page and verifies it.
Three lists that carry every change with its exact wording, and two calls that record your decisions. Your agent signs in with OAuth or an API key from your dashboard’s settings, and works one site at a time by its id.
list_pending_jobs
The changes Foliora has drafted for one site that are not yet approved or rejected, highest impact first, plus the site-health findings an agent can fix. Every row carries its content: `operations` are the exact before/after values to put on the page (a finding row carries an `instruction` instead), `hash` is what `approve_apply` needs, `status` is the word the customer's dashboard prints, and `nextAction` is the only thing to do with the row. `site.publisher` says who publishes an approved change: `foliora` through a connected store, or `you`. A row whose nextAction is `approve_apply` is ready to show the customer; `wait` is Foliora still drafting; `none` is a snag only the dashboard can resolve. siteId is required: the customer finds it on their dashboard's Connect your agent page.
list_approved_jobs
Approved changes and reported fixes on one site with their content, newest first: `yours` still to be put on the page (nextAction `apply` — do it, then call approve_apply with the row's id and hash), `published` on the page and awaiting Foliora's read, `verified` read live, `snag` read and not found. Every row carries its content: `operations` are the exact before/after values to put on the page (a finding row carries an `instruction` instead), `hash` is what `approve_apply` needs, `status` is the word the customer's dashboard prints, and `nextAction` is the only thing to do with the row. `site.publisher` says who publishes an approved change: `foliora` through a connected store, or `you`.
list_rejected_jobs
Changes the customer rejected and findings they chose to ignore on one site, with the content they declined, newest first. Read-only history: nothing here can be approved. Every row carries its content: `operations` are the exact before/after values to put on the page (a finding row carries an `instruction` instead), `hash` is what `approve_apply` needs, `status` is the word the customer's dashboard prints, and `nextAction` is the only thing to do with the row. `site.publisher` says who publishes an approved change: `foliora` through a connected store, or `you`.
approve_apply
One call per batch, on the customer's instruction only. For a job row: the customer approved exactly the operations shown, by the row's `hash`. On a site where `publisher` is `you`, put every operation's exact `after` value on the page first, in ordinal order, then call this — it records the approval and the receipt together and Foliora verifies the live page on its own. On a site where `publisher` is `foliora`, call it as soon as the customer approves: Foliora publishes and verifies; never edit the page yourself. Calling it again for a row that is already approved re-records that the page carries the change (after a `snag`, fix the page and call again). For a finding row: fix it on the site first, then pass its id with no hash. A stale hash is refused for that item only; the rest of the batch goes through. Requires OAuth or an API key with the approve scope.
reject_apply
One call per batch, on the customer's instruction only. A job row is rejected — its draft closes and the page stays as it is; Foliora may draft the page again later. A finding row is ignored. Pass an optional reason in the customer's words. Requires OAuth or an API key with the approve scope.
Before you have an account
Three public tools on https://www.foliora.ai/mcp/publicneed no sign-in: product facts, a preview link, and the snapshot a preview produced.
get_product
Return Foliora product facts: brand, per-site plans, canonical URLs, and product boundaries. Use when the user asks what Foliora is, how much it costs, or which URL to open. Does not crawl a site.
get_snapshot
Fetch a Foliora preview snapshot the human already started. Requires the 32-character hex token from /preview/{token}. Returns public findings and pages only. Unknown tokens are not_found. Does not start a crawl.
create_preview_link
Build a Foliora /preview URL for a public website. Does not crawl, does not take credentials, and does not change the site. Send the human to the returned previewUrl so they can start the snapshot in a browser.
Connect
Point any MCP client at https://www.foliora.ai/mcp. It signs in with OAuth or a named API key from your dashboard’s settings, and works one site at a time by the id shown there. Nothing is approved unless you say so, and an agent can never roll a change back.
Claude Code
claude mcp add --transport http foliora https://www.foliora.ai/mcp