Skip to main content
Glama
Sign In

Cloche

by dev.cloche
OverviewDiscussionsAdmin

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. With an email grant, invite_to_organization true, or omitted if the sharer can add members to a named organization, also invites them to it as a User, who must accept. organization_name lets an Owner name an unnamed one. False shares only the app. Existing members keep their role and pending invitations are reused. Role user is the ordinary invite; editor lets them change the app, and a guest is only a User. 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 asks for a Cloche sign-in with that address, and lets someone new in when they sign up with it. 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

NameRequiredDescriptionDefault
roleNofor a grant, user or editor; for a link, omit or user -- a link cannot be editor
accessYes
app_idYesthe app to change sharing on
expiresNofor link or set-link-expiry; omit on link means never
link_idNowhich link to stop or retime, as set_access returned it or get_access lists it; required for revoke-link and set-link-expiry
languageNofor signup, the join page's language; omit keeps the current
subject_nameNogrant only: 1-200 characters; complete consecutive name words, ignoring case and repeated whitespace, or their handle before the @
subject_or_emailNoemail address, or an account id as get_access lists it; a handle goes in subject_name
organization_nameNowith invite_to_organization: Owner-only name for an unnamed organization
invite_to_organizationNoemail grant only: false shares only the app

Output Schema

NameRequiredDescriptionDefault
roleNorole applied to the resolved account
accessYesthe mode this call applied, not the app's state; get_access reports the state
link_idNothis link's id; stopping the link later needs it, and the URL will not do
share_urlNothe link people open for anyone-with-the-link access; the app's own URL stays private
account_idNoresolved account for a name grant, an internal id
expires_atNowhen the minted or updated link stops working, RFC3339; omit or null means it does not expire on its own
stopped_linksNohow 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.

  1. Changed2 schema fields changed
    • changedInput schema / properties / invite_to_organization / description
      Previous value: -"email grant only: also invite organization membership as User"New value: +"email grant only: false shares only the app"
    • changedInput schema / properties / invite_to_organization / type
      Previous value: -"boolean"New value: +[
+  "null",
+  "boolean"
+]
  2. Changed2 schema fields changed
    • addedInput schema / properties / invite_to_organization
      Added value: +{
+  "description": "email grant only: also invite organization membership as User",
+  "type": "boolean"
+}
    • addedInput schema / properties / organization_name
      Added value: +{
+  "description": "with invite_to_organization: Owner-only name for an unnamed organization",
+  "type": "string"
+}
  3. Changed2 schema fields changed
    • 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"
+}
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations flag destructive/openWorld/non-idempotent, but the description adds the operationally critical detail the annotations cannot: links are non-idempotent (calling twice yields two live links), an already-stopped link reports 'not live' rather than failing, revocations persist even when the app is public or link-shared, email grants send mail while id/name grants do not, and email invites require a Cloche sign-in. That is exactly the beyond-annotation context an agent needs before calling a destructive 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?

Length is justified by 10 parameters and 8 access modes, and each claim largely earns its place, but it is delivered as one undifferentiated paragraph with notable repetition (revoke-link and its already-stopped case are explained twice). A structured breakdown by access mode would let an agent find the relevant clause far faster.

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?

Covers the full burden of a complex multi-mode mutation: permissions and role semantics, invite/org behavior, link lifecycle and expiry, revocation permanence, idempotency caveats for link creation and revocation, and where to source ids from get_access. With an output schema present, no return-value explanation is owed.

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 90% (baseline 3), yet the description still layers meaning: role 'user' is the ordinary invite vs editor's wider power, a link can never be editor, expires determines self-termination, organization_name is Owner-only and only with invite_to_organization, and name grants defer to stronger existing access. The only gap is it doesn't consolidate these into a parameter-by-parameter mapping.

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?

Opens with a concrete verb+resource and scope: 'Changes who can reach an app.' The sibling set is answerable from this alone — get_access is the read counterpart the description repeatedly routes to, while this tool mutates sharing state. An agent can distinguish it from get_access, publish, or delete_app without opening a schema.

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

Usage Guidelines4/5

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

Explicit trigger context ('For when the person asks to share, invite, or take that back') plus a mode-by-mode account of when each access value applies, and repeated pointers to get_access for discovery (links, grants, link_id). It stops short of cleanly separating when to use this tool versus get_access or checkpoint_app in one place, but the guidance is strong and concrete.

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

All Cloche toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources