User guide

Approvals and permissions

A page tool runs in your browser, in your session, as you. So before one runs, XataWorks asks. This is what that question means and what each answer commits you to.

A page tool runs in your browser, in your session, as you. So before one runs, XataWorks asks. This article is what that question means.

Read only, Mutating, Destructive

Every page tool falls into one of three classes, and the class is what decides how hard you are asked.

Class	What it means
Read only	The operation only looks things up. Reached only when the site positively says so.
Mutating	It changes something, and the site has said the change is additive — a create, an append, a status set.
Destructive	It may make changes that cannot be undone — or the site never said what it does.

That last clause is the one to absorb. An operation that declares nothing about itself is treated as destructive, not as harmless. So is one whose declaration XataWorks could not read. The burden is on the website to say its action is safe; silence is never taken as reassurance.

The Available tools dialog listing a fictional helpdesk's six operations. Two are badged Read only, two are badged Mutating, and one — Close a Larkspur ticket — is badged Destructive and off-site. — The classes, as XataWorks worked them out. On the site in this capture, *Close a Larkspur ticket* declares nothing about itself at all — which is why it is badged destructive, beside two that said they only read and two that said their changes are additive.

A class is not a safety rating. It decides what you are asked, not what the operation does and not what you should allow. A read-only operation on a system holding sensitive data is still reading sensitive data. The class tells you how confident the site was; the decision stays yours.

The question itself

The request names the operation, marks its class, and shows the arguments it is about to be called with — with everything else that site publishes one click away, so you can see the shape of what you are deciding about. Then it offers:

Allow this call only — this call, these arguments, nothing remembered.
Always allow this operation here — this one operation runs unasked from now on, in the place named: this page, this chat, or this site, depending on what is being decided.
Allow a whole class — a rung rather than an operation. See below.
Deny — nothing runs. The agent is told you declined, which is different from being told the operation failed.

The dialog leads with the narrowest answer and keeps the broader grants behind an arrow beside it. That is deliberate: the safe answer is the easy one, and widening a grant takes an extra motion rather than being the thing your hand does first.

An approval card at the top of the chat, marked APPROVAL. Its heading repeats the request, “Close Larkspur ticket LK-4371. The requester says it is sort…”. Below it a line reads “Close a Larkspur ticket [Destructive]”, then an expandable row reading “1 argument” showing ticket_number LK-4371, then a collapsed row reading “What this site publishes”. Two buttons: “Allow this call only”, with an arrow beside it for the broader grants, and “Deny”. Beneath the card the transcript shows the request, a run reading “Calling Larkspur Get Ticket via WebMCP” which returned NOT_FOUND, and a second run reading “Calling Larkspur Search Tickets via WebMCP” which found the ticket. — What you are asked before an operation that changes the site runs. The operation the site publishes for closing a ticket declares nothing about itself, so it is shown as **Destructive** and confirmed — while the read-only lookups below it ran without a question. Note which button leads: the narrow answer, with the broader grants behind the arrow beside it. This is a real turn, including the assistant’s first lookup coming back empty and its going on to search instead.

How far a grant reaches

The class rungs are cumulative, and each one is a statement about everything a site publishes rather than about one operation.

The three rungs. Only the widest waives the question entirely, and it is reachable only by your choosing it explicitly — nothing XataWorks does will land you there on its own.

A grant is also bounded in place. This page, in this chat and on this site are three different promises, and the dialog says which one it is offering. On some systems the boundary is narrower still: where a site keeps separate customers or properties in its URL, a grant covers the one you are looking at and the next one is asked about separately.

Grants are taken back from the permission shield in the browser toolbar, for the site in the current tab. See The browser panel.

Approving a set in one act

When the agent needs several things at once, you are asked once, for the set, with everything it covers listed — rather than being walked through five dialogs in a row. You are agreeing to what is on the list, and the list is complete.

Wherever the dialog summarises, it can be expanded: the arguments an operation will be called with, the full list a set covers, the scope a grant will apply to. All of it is visible before you answer. If something is summarised and you want the detail, expand it — the detail is the thing you are actually agreeing to.

When nobody is there

If an operation needs approval and there is no window to ask in — a scheduled prompt, a background run — nothing is allowed. The agent is told there was nobody to ask, which it can act on sensibly. It is not a refusal, and it is never a silent yes.

The chat header carries a badge while that is happening, with a Resume button. See Work that continues.

Checking afterwards

Everything above is about deciding before. The call log is how you check after. Open it from the chat header’s ⋮ menu, under Log.

The WebMCP call log. Along the top: a search box, a Scope selector reading This chat, a Domain selector reading All domains, a Group by selector reading None, a Show selector reading All, and a Refresh button. Below, four entries, each a timestamp, an operation name and an outcome of ok: larkspur_find_invoice twice and larkspur_get_ticket twice. Clear log and Close sit at the bottom. — The call log, after a single turn. Each entry records when, which operation was called and how it went — here, four calls across the helpdesk and its billing page. It is the one place the underlying name for page tools appears on screen — WebMCP, the protocol a website uses to publish them.

Three questions it answers that nothing else does:

Did that actually run? — when a result looks too good, or too fast.
What has this site been asked to do? — after you have granted a broad rung and want to see what it has been used for.
What happened while I was not watching? — after a scheduled prompt or a long unattended run.

You can clear the log for one site or for every site; both ask for confirmation first, naming what will go. Logging itself can be turned down or off in the WebMCP Log section of Preferences.

If you open the log and find it empty, check there before concluding nothing has happened — a log that was switched off says so rather than pretending the history is empty. An empty log with logging on means exactly what it says.

Back to all user-guide articles.