Skip to main content
Glama

agentleFS

by com.agentlefs
OverviewDiscussionsAdmin

Grant or ask for access

access_grant
Destructive

Give access, ask for it, or decide on it. A grant changes who can read the content and cannot be unread, so every action here is treated as consequential. A request goes to the lowest common ancestor of you and the data's owner and climbs until it reaches someone who can grant it. Actions — share: grant members of this organization, by email, viewer or editor (or manager) on a folder or document; two calls, the first previews who would be granted and returns a confirm_token, and an address that is no member is refused. The second is all or nothing: if it fails partway, nobody was granted. request: ask for a role on something (location or node, role, reason); wait=true with a deadline registers a wait for the decision. approve: approve a request routed to you (request_id, note). decline: decline a request routed to you (request_id, note). declassify: release what your session has read so your next write is not labeled with it (sources), or one label on a document (location or node, source). hold: place a legal hold so nothing under it can be erased or purged (location or node, or identity; reason). share_out: offer a folder or document to a person in another organization by email (location or node, to, role); an agent below a person's own client proposes instead, and that person decides in the console. An address with no account is invited. The answer says whether they were emailed and carries recipient_link. accept_share: accept an offer made to you, a person (share_id), into the organization this connection is in; the answer names it. organization, if given, must be that one: a person in several picks another in the console. It lands under its own name at the top level, or inside location: a folder only you can see (refused, with the reasons, anywhere else). Only you and your agents read it. decline_share: decline an offer made to you (share_id). decide_share: a person decides a proposal (share_id, approve); refused to every AI client. set_settings: set whether editors may share a folder or document (location or node, editors_can_share: true, false, or null to inherit); owner or manager only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoshare_out: the recipient's email
nodeNorequest, declassify, hold, share_out, set_settings: the document or folder, by id instead of location. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.
noteNoapprove, decline: a note to the requester
roleNoshare: viewer opens it; editor also edits; manager can also approve access requests for it, share it and grant within it. Sharing needs manager on this folder or one above it, or editor there to share as viewer or editor, unless its owner turned editor sharing off (access_grant action=set_settings). reader, writer and approver are deprecated aliases for viewer, editor and manager · request, share_out: default viewer. editor can also edit; manager (request only) can also share it, grant within it and decide requests for it. An approved request gives the role to everyone you work under who lacks it, too. Asking for a role you already hold, or one below it (manager implies editor, editor implies viewer), is refused. reader, writer and approver are deprecated aliases for viewer, editor and manager
waitNorequest: also register a wait for the decision
actionYeswhat to do; each action takes the arguments its line names
emailsNoshare: email addresses to share with (at most 20 per call)
reasonNorequest, hold, share_out: why you are doing this, in one line (at most 200 characters); recorded with the event and exported with the log
sourceNodeclassify: the label's source, a path or node id. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.
approveNodecide_share: true to offer it, false to decline
sourcesNodeclassify: which read sources to release (paths or node ids); default all. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.
deadlineNorequest: with wait: when to stop waiting (ISO)
identityNohold: an identity id, to hold its drafts
locationNoshare: full path from the workspace root, e.g. "handbook/vendor/acme.md" (as printed by browse action=documents or search) · request, declassify, hold, share_out, accept_share, set_settings: the document or folder, by path; accept_share: the folder to put it in, only you can see (default the top level)
share_idNoaccept_share, decline_share, decide_share: the share's id, from access_read action=offers, shared or proposals
request_idNoapprove, decline: the request's id, from access_read action=requests or my_requests
scope_typeNoshare: default folder
continuationNorequest: with wait: a note to your future self for when it resolves
organizationNoaccept_share: the organization to put an accepted share in, by id or name: only the one this connection is in; omit for that one
confirm_tokenNoshare: from the first call. Calling without it PREVIEWS: nothing is shared.
idempotency_keyNoAny unique string you choose for this write, e.g. a UUID. If you retry the call with the same key and the same arguments, the first answer is returned and nothing is done twice. Reusing a key for a different request is refused. Keys are kept 24 hours.
editors_can_shareNoset_settings: true lets editors share here, false stops them, null clears this node's own setting so it inherits

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
holdNo
textNothe answer as prose, for an action that answers in prose
waitNo
acrossNo
actionYesthe action that answered
canSeeNo
labelsNo
emailedNoshare_out when offered or invited: whether the recipient is emailed; when false, send them recipient_link
refusedNo
requestNo
requestsNo
settingsNo
invitationNo
declassifiedNo
organizationNoaccept_share: the organization it went into
recipient_linkNoshare_out: when offered, the recipient's inbox for this offer; when invited, the invitation's preview, names only. Absolute; absent when the console's public URL is not configured. It grants no access
not_emailed_reasonNoshare_out when invited: why the recipient is not emailed, when emailed is false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / location / description
      Previous value: -"share: full path from the workspace root, e.g. \"handbook/vendor/acme.md\" (as printed by browse action=documents or search) · request, declassify, hold, share_out, set_settings: the document or folder, by path"New value: +"share: full path from the workspace root, e.g. \"handbook/vendor/acme.md\" (as printed by browse action=documents or search) · request, declassify, hold, share_out, accept_share, set_settings: the document or folder, by path; accept_share: the folder to put it in, only you can see (default the top level)"
  2. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations already declare destructive=true and readOnly=false, and the description adds substantial context beyond them: grants are irreversible ('cannot be unread'), share is all-or-nothing on partial failure, the first call only previews via confirm_token, requests propagate up the ownership tree, and decide_share is blocked for agents. That is exactly the kind of consequence/auth context annotations cannot convey.

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 opening sentence is well front-loaded, but the body is one dense run-on paragraph of semicolon-chained clauses that is hard to scan for an eleven-action tool; a per-action line structure would earn its size. Considerable content also duplicates the schema's per-parameter action tags.

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

Completeness4/5

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

For a 22-parameter, 11-action mutation tool with an output schema and full annotation coverage, the description covers the consequential behaviors, refusal conditions and one notable response detail (emailed flag + recipient_link). Remaining return-value detail is legitimately delegated to the output schema, so nothing critical is 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% and each parameter already documents its actions and constraints, so the baseline is 3. The description mostly paraphrases those same per-action argument lists rather than adding new meaning, though the preview/confirm_token workflow is genuinely useful context.

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?

Opens with a precise verb+resource framing ('Give access, ask for it, or decide on it') and then enumerates all eleven actions with their concrete effects, so an agent can tell exactly what each action does. It stops short of naming the obvious siblings (access_read, access_revoke), which it only references in the schema text, so it does not fully differentiate against them.

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 real when-to-use context: grants are consequential and cannot be unread, share is a two-call preview-then-confirm flow, requests climb to the lowest common ancestor, and decide_share is refused to AI clients. It never states when to use this versus access_read/access_revoke, so exclusions are present but sibling routing is missing.

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

All agentleFS toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources