Cloche

Set access

set_access

Destructive

Changes who can reach an app. For when the person asks to share, invite, or take that back. Apps start private. Modes: public or private, signup, anyone-with-the-link, revoke-link, grant by exactly one name, id, or email, or revoke-grant by id or email. Access "signup" opens the app to anyone who signs up, for when the person asked for that. A stranger sees only its join page, and whoever joins enters as user. A link can open and save, never change it -- letting someone change it takes an invite by name or address. Role user is the ordinary invite; editor lets them change the app. A name grant keeps stronger access the account already has. A new email invite sends mail; an account id or name grant does not. A missing or ambiguous name is refused without naming or guessing accounts. A link takes expires: never, 24h, or 7d, so it stops working on its own; access "set-link-expiry" with the link_id from get_access changes that later. Making a link returns a link_id with the URL; stopping that link later needs the id, and the URL will not do. Stopping a link (access "revoke-link") ends that one link for everyone holding it. It does not make the app private or touch other links; get_access lists which links exist. Stopping a link that was already stopped answers that it isn't one of this app's live links -- the first call having worked, so the link is already off rather than stopping it having failed. Making a link twice yields two live links, so a call that timed out may have made one; get_access shows it. An email invitation needs a Cloche sign-in with that address: an account opens it now, a new one after early-access approval. The platform owns their way in, so the app needs no login or code-entry screen. Taking access back is "revoke-grant" with the subject_or_email from get_access, which lists everyone under grants. A revoked account stays refused on this app, even when public or by link, until invited again.

Input Schema

TableJSON Schema

Name	Required	Description
`role`	No	for a grant, user or editor; for a link, omit or user -- a link cannot be editor
`access`	Yes
`app_id`	Yes	the app to change sharing on
`expires`	No	for link or set-link-expiry; omit on link means never
`link_id`	No	which link to stop or retime, as set_access returned it or get_access lists it; required for revoke-link and set-link-expiry
`language`	No	for signup, the join page's language; omit keeps the current
`subject_name`	No	grant only: 1-200 characters; complete consecutive name words, ignoring case and repeated whitespace, or their handle before the @
`subject_or_email`	No	email address, or an account id as get_access lists it; a handle goes in subject_name

Output Schema

TableJSON Schema

Name	Required	Description
`role`	No	role applied to the resolved account
`access`	Yes	the mode this call applied, not the app's state; get_access reports the state
`link_id`	No	this link's id; stopping the link later needs it, and the URL will not do
`share_url`	No	the link people open for anyone-with-the-link access; the app's own URL stays private
`account_id`	No	resolved account for a name grant, an internal id
`expires_at`	No	when the minted or updated link stops working, RFC3339; omit or null means it does not expire on its own
`stopped_links`	No	how many share links making the app private just stopped; those links no longer open the app for anyone holding one

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 10, 2026

changedInput schema / properties / access / enum

Previous value: -[
-  "public",
-  "private",
-  "link",
-  "revoke-link",
-  "grant",
-  "revoke-grant",
-  "set-link-expiry"
-]New value: +[
+  "public",
+  "private",
+  "signup",
+  "link",
+  "revoke-link",
+  "grant",
+  "revoke-grant",
+  "set-link-expiry"
+]

addedInput schema / properties / language

Added value: +{
+  "description": "for signup, the join page's language; omit keeps the current",
+  "enum": [
+    "en",
+    "he"
+  ],
+  "type": "string"
+}

First observedOct 6, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructive=true and idempotent=false, and the description goes well beyond them: it explains that calling link twice yields two live links (a timed-out call may have made one), that revoking an already-revoked link returns a benign 'not a live link' answer rather than an error, that revoke-link does not make the app private or touch other links, and that email invites require a Cloche sign-in with that address. This is exactly the operational context an agent needs for a multi-mode mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and every paragraph is on-topic, but the text is a ~350-word prose wall with no structure and visible redundancy ('access "signup" opens the app to anyone who signs up, for when the person asked for that' restates the earlier mode list). An agent can use it, but a mode-keyed list would deliver the same content in half the space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter, 8-mode mutation tool with an output schema available, the description covers the remaining gaps: mode selection, prerequisite flows to get_access, error-call semantics, and revocation persistence ('A revoked account stays refused on this app... until invited again'). Nothing essential to correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 88%, so the baseline is 3; the description adds real meaning on top, clarifying that a link can never be editor, that a name grant preserves stronger access the account already holds, that link_id from set_access/get_access is required downstream, and that expires governs when a link stops working on its own. It stops short of full per-field coverage (e.g. language and subject_name constraints live only in the schema).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Changes who can reach an app') and then enumerates all eight access modes, so an agent knows exactly what surface this tool controls. It is clearly distinguished from the read-side sibling get_access, which it repeatedly names as the listing counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('For when the person asks to share, invite, or take that back') and repeatedly routes the agent to alternatives: get_access to list links or grants, set-link-expiry to retime a link, revoke-link vs revoke-grant for the two different removal cases. When-not conditions are also covered, e.g. 'A link can open and save, never change it -- letting someone change it takes an invite'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Cloche tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.