Skip to main content
Glama

Alcoven

by co.alcoven
OverviewDiscussionsAdmin

Change who sees what

set_access
Destructive

Changes who can see a top folder of the project, like finance/, to hide it from some people or the client, or make it visible to everyone (path, with sees: everyone on the project, or only these people, each reading or writing), or which top folders one person or agent sees (person, with folders), as this person, in their rights: managers change anything; the people a closed folder names who write change its people; anyone who writes may close a new, empty top folder, naming themselves. Managers always see everything. Everything inside a top folder follows it, so a deeper folder or a file is refused, with how to move it into a top folder instead. The answer first says what the change opens or closes, and to whom; the person confirms it in this AI tool before anything changes, and clients that cannot show that confirmation get that line and a proposal id instead. For when the person asks to change who sees what.

Input Schema

NameRequiredDescriptionDefault
pathNoA top folder, like finance/: whose setting to change.
seesNoWith path: "everyone" on the project, or only these people besides the managers, each writing unless reads is true.
personNoOr: the person or agent whose own top folders to set, by member id or name.
foldersNoWith person: "everything" open to them, or only these top folders.
projectNoThe project's slug, from open_project, like acme. Not needed when a § address names the project, or when the person is on one project.

Output Schema

NameRequiredDescriptionDefault
changeNo
appliedYes
previewNo
proposalNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • removedInput schema / properties / changers
      Removed value: -{
-  "anyOf": [
-    {
-      "const": "everyone",
-      "type": "string"
-    },
-    {
-      "items": {
-        "maxLength": 120,
-        "minLength": 1,
-        "type": "string"
-      },
-      "maxItems": 100,
-      "type": "array"
-    }
-  ],
-  "description": "With path: \"everyone\" who sees it and writes, or only these people besides the managers. Leave it out to keep who changes it."
-}
    • changedInput schema / properties / folders / anyOf
      Previous value: -[
-  {
-    "const": "everything",
-    "type": "string"
-  },
-  {
-    "items": {
-      "properties": {
-        "path": {
-          "maxLength": 1100,
-          "minLength": 1,
-          "type": "string"
-        },
-        "reads": {
-          "description": "true: they read it and do not write.",
-          "type": "boolean"
-        }
-      },
-      "required": [
-        "path"
-      ],
-      "type": "object"
-    },
-    "maxItems": 100,
-    "type": "array"
-  }
-]New value: +[
+  {
+    "const": "everything",
+    "type": "string"
+  },
+  {
+    "items": {
+      "properties": {
+        "path": {
+          "description": "A top folder, like design/.",
+          "maxLength": 1100,
+          "minLength": 1,
+          "type": "string"
+        },
+        "reads": {
+          "description": "true: they read it and do not write.",
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "path"
+      ],
+      "type": "object"
+    },
+    "maxItems": 100,
+    "type": "array"
+  }
+]
    • changedInput schema / properties / folders / description
      Previous value: -"With person: \"everything\" open to them, or only these folders and files."New value: +"With person: \"everything\" open to them, or only these top folders."
    • changedInput schema / properties / path / description
      Previous value: -"A folder (ending in /) or a file, like finance/ or contracts/sow.md: whose setting to change."New value: +"A top folder, like finance/: whose setting to change."
    • changedInput schema / properties / person / description
      Previous value: -"Or: the person or agent whose own folders to set, by member id or name."New value: +"Or: the person or agent whose own top folders to set, by member id or name."
    • changedInput schema / properties / sees / description
      Previous value: -"With path: \"everyone\" on the project, or only these people besides the managers. Leave it out to keep who sees it."New value: +"With path: \"everyone\" on the project, or only these people besides the managers, each writing unless reads is true."
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: the person must confirm in the AI tool before anything changes, clients without confirmation get a proposal id, deeper folders/files are refused with guidance, and managers always see everything. It also explains the rights model for who may change which settings.

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 core purpose is front-loaded, but the description is a long, run-on paragraph with dense comma-spliced rules that are hard to parse. Most information is relevant, but the structure could be much clearer.

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 a destructive access-control tool with an output schema and rich annotations, the description covers the important behavioral pieces: permissions, confirmation, proposal ids, refusal for non-top folders, and manager visibility. Nothing essential for correct invocation appears missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents path, sees, person, folders, and project in detail. The description adds modest mode-level clarification but largely repeats what the schema already provides, so the baseline 3 is appropriate.

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

Purpose4/5

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

States a specific verb and resource: changing visibility of a top folder or setting which top folders a person/agent sees. The two modes (path/sees vs person/folders) are clear, but it does not explicitly distinguish itself from siblings such as apply_access, who_sees, or set_role.

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?

Gives a clear trigger: 'For when the person asks to change who sees what,' with concrete conditions for folder-level vs person-level changes. It does not name alternatives or state when another sibling tool should be used instead.

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

All Alcoven toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources