A
licenseNot graded
qualityC
maintenanceEnables agents to share and hand off documents with stable URLs, comment, and group docs under a drop key, with tamper-evident versioning and no account required.
80 npm
1
MIT
agentleFS
Server Details
Agent permissions for the files your team shares
Ownership verified
- Status
- Healthy
- Uptime
- 89.3% over 24 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.9/5.0
Scored across 16 tools
Disambiguation4/5
Tools are largely separated by domain (access, docs, identity, knowledge, messages, registry, sources) and read vs write intent. However, browse, read, search, and access_read all deal with retrieval from slightly different angles, so an agent could occasionally hesitate between listing, searching, reading one item, or querying access metadata.
Naming Consistency4/5
Most names follow a clear snake_case domain_action pattern (access_grant, doc_create, identity_write, message_write). A few single-verb tools (browse, read, search, brief_me) break the pattern, but the overall convention is still predictable and readable.
Tool Count4/5
At 16 tools, the server is slightly above the ideal 3–15 range, but the breadth of the domain (documents, access, coordination, knowledge, registry, sources) justifies it. Each tool is a grouped domain surface rather than a redundant standalone operation.
Completeness4/5
The surface covers document CRUD, access management, identity, knowledge, messaging, coordination, registry, sources, search, and reads, which is very broad. Minor lifecycle gaps exist, such as no direct edit/delete for some shared knowledge or comments, but agents can work around them.
Available Tools
16 toolsaccess_grantGrant or ask for accessADestructiveInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | share_out: the recipient's email | |
| node | No | request, 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. | |
| note | No | approve, decline: a note to the requester | |
| role | No | share: 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 | |
| wait | No | request: also register a wait for the decision | |
| action | Yes | what to do; each action takes the arguments its line names | |
| emails | No | share: email addresses to share with (at most 20 per call) | |
| reason | No | request, hold, share_out: why you are doing this, in one line (at most 200 characters); recorded with the event and exported with the log | |
| source | No | declassify: 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. | |
| approve | No | decide_share: true to offer it, false to decline | |
| sources | No | declassify: 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. | |
| deadline | No | request: with wait: when to stop waiting (ISO) | |
| identity | No | hold: an identity id, to hold its drafts | |
| location | No | 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) | |
| share_id | No | accept_share, decline_share, decide_share: the share's id, from access_read action=offers, shared or proposals | |
| request_id | No | approve, decline: the request's id, from access_read action=requests or my_requests | |
| scope_type | No | share: default folder | |
| continuation | No | request: with wait: a note to your future self for when it resolves | |
| organization | No | accept_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_token | No | share: from the first call. Calling without it PREVIEWS: nothing is shared. | |
| idempotency_key | No | Any 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_share | No | set_settings: true lets editors share here, false stops them, null clears this node's own setting so it inherits |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| hold | No | |
| text | No | the answer as prose, for an action that answers in prose |
| wait | No | |
| across | No | |
| action | Yes | the action that answered |
| canSee | No | |
| labels | No | |
| emailed | No | share_out when offered or invited: whether the recipient is emailed; when false, send them recipient_link |
| refused | No | |
| request | No | |
| requests | No | |
| settings | No | |
| invitation | No | |
| declassified | No | |
| organization | No | accept_share: the organization it went into |
| recipient_link | No | share_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_reason | No | share_out when invited: why the recipient is not emailed, when emailed is false |
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.
access_readRead accessARead-onlyIdempotentInspect
Who can read what, what is waiting on access decisions, and who you are in the organization's tree of people and agents. Answers only about what you can read yourself; anything else answers not-found. Actions — who_can_read: the people and groups who reach a folder or document, direct and inherited (location, scope_type). can_see: whether another identity can read something you can read (location or node, who). labels: where a document's content came from (location or node). requests: access requests routed to you to decide. my_requests: the access requests you filed (request_id for one). offers: shares another organization offered you, a person. proposals: shares your agents proposed that wait on your person's decision in the console. shared: what this organization shared out to, and in from, other organizations. settings: whether editors may share a folder or document, and where that setting comes from (location or node). self: who you are, and your capability card. loads: what an identity (target, default you; yours or one below you) loads when it connects: the folders whose memory and skills it is handed, those it can no longer read, and the organization's default for new agents; only folders you can read are named. agents: your ancestors, siblings and children in the tree, with status and last-seen time. card: an identity's capability card and its history (target; default you).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| who | No | can_see: an identity id or exact name | |
| node | No | can_see, labels, 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. | |
| action | Yes | what to do; each action takes the arguments its line names | |
| target | No | loads, card: an identity id; defaults to you | |
| location | No | who_can_read: full path from the workspace root, e.g. "handbook/vendor/acme.md" (as printed by browse action=documents or search). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · can_see, labels, settings: the document or folder, by path; accept_share: the folder to put it in, only you can see (default the top level) | |
| request_id | No | my_requests: the request's id, from access_read action=requests or my_requests | |
| scope_type | No | who_can_read: whether location names a folder or one document; default folder, or the kind a pasted link names |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| card | No | |
| hold | No | |
| text | No | the answer as prose, for an action that answers in prose |
| wait | No | |
| cards | No | |
| ended | No | |
| loads | No | |
| across | No | |
| action | Yes | the action that answered |
| canSee | No | |
| labels | No | |
| emailed | No | share_out when offered or invited: whether the recipient is emailed; when false, send them recipient_link |
| refused | No | |
| request | No | |
| identity | No | |
| position | No | |
| requests | No | |
| settings | No | |
| sessionId | No | |
| invitation | No | |
| orgContext | No | |
| credentials | No | |
| declassified | No | |
| organization | No | accept_share: the organization it went into |
| retiringUntil | No | |
| webhookSecret | No | with a webhook: deliveries are signed in the Standard Webhooks format (webhook-id, webhook-timestamp, webhook-signature); verify them with any Standard Webhooks library and this secret |
| recipient_link | No | share_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_reason | No | share_out when invited: why the recipient is not emailed, when emailed is false |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds non-obvious behavior: results are restricted to what the caller can read, out-of-scope queries return not-found, and for 'loads' only folders you can read are named — real behavioral context beyond the annotations.
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?
Front-loading is good — the first sentence is a usable summary — but the action inventory is a single semicolon-chained wall of text that would be far easier to parse as a list. Density is high with little waste, yet the structure works against scanning and the run-on form hurts usability.
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?
With an output schema present, return shapes need not be described, and the description still covers all 13 actions, their arguments, defaults, and the not-found scoping rule. It is complete for the common cases; pagination/volume behavior and per-action output hints are the only omissions.
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 100%, so the baseline is 3, but the description adds cross-field semantics the schema does not: target 'defaults to you' and must be 'yours or one below you' for loads, scope_type defaults to folder or is inferred from a pasted console link, and location/node carry accepted link forms. These conditional constraints genuinely extend 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?
The opening sentence names the resource and its three question families (who can read what, pending decisions, identity/tree), then enumerates all 13 actions with the specific object each returns. An agent can tell this is the read-only access dispatcher versus the mutating siblings access_grant/access_revoke without consulting either 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?
It gives a clear scope rule — 'Answers only about what you can read yourself; anything else answers not-found' — and every action line names the arguments it needs, which effectively routes the agent to the right action. It never explicitly contrasts when to pick this tool over access_grant/access_revoke, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
access_revokeTake access awayADestructiveInspect
Take back access or a protection. Each takes effect on the next call of everyone it reaches. Actions — withdraw: withdraw an access request you filed (request_id). withdraw_share: take back a share made to another organization; it is gone from theirs (share_id). release_hold: release a legal hold, so what it covered can be erased again (hold_id). retire: end yourself or an identity below you and everything under it; what they owned passes to the nearest living ancestor and their drafts are purged. One below you first gets distill_window_s (default 3600) to publish.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | what to do; each action takes the arguments its line names | |
| reason | No | retire: why you are doing this, in one line (at most 200 characters); recorded with the event and exported with the log | |
| target | No | retire: an identity id; defaults to you | |
| hold_id | No | release_hold: the hold's id, as access_grant action=hold returned it | |
| share_id | No | withdraw_share: the share's id, from access_read action=offers, shared or proposals | |
| request_id | No | withdraw: the request's id, from access_read action=requests or my_requests | |
| idempotency_key | No | Any 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. | |
| distill_window_s | No | retire: how long the identity has to publish before it ends; 0 ends it now |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| card | No | |
| hold | No | |
| wait | No | |
| cards | No | |
| ended | No | |
| loads | No | |
| across | No | |
| action | Yes | the action that answered |
| canSee | No | |
| labels | No | |
| emailed | No | share_out when offered or invited: whether the recipient is emailed; when false, send them recipient_link |
| refused | No | |
| request | No | |
| identity | No | |
| position | No | |
| requests | No | |
| settings | No | |
| sessionId | No | |
| invitation | No | |
| orgContext | No | |
| credentials | No | |
| declassified | No | |
| organization | No | accept_share: the organization it went into |
| retiringUntil | No | |
| webhookSecret | No | with a webhook: deliveries are signed in the Standard Webhooks format (webhook-id, webhook-timestamp, webhook-signature); verify them with any Standard Webhooks library and this secret |
| recipient_link | No | share_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_reason | No | share_out when invited: why the recipient is not emailed, when emailed is false |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that effects take hold on the next call of everyone reached, that release_hold makes covered material erasable again, and that retire transfers ownership to the nearest living ancestor, purges drafts, and gives a subordinate a distill_window_s before ending. These are non-obvious destructive consequences the annotations (destructiveHint=true) only flag generically.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the general purpose, then uses a compact per-action list. Dense but every clause earns its place; the retire sentence is long but packs distinct, necessary consequences.
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 an 8-parameter, four-action mutation tool with an output schema and annotations already present, the description covers the consequences of each action adequately. It leaves return-value details to the output schema and idempotency semantics to the schema, which is appropriate.
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's description already names its action (e.g. hold_id for release_hold, share_id for withdraw_share). The description's 'each action takes the arguments its line names' adds a mapping but no syntax or format detail beyond what the schema carries, so the baseline 3 applies.
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?
The description opens with a concrete verb+resource ('Take back access or a protection') and then enumerates four distinct actions (withdraw, withdraw_share, release_hold, retire), each with its own object. This clearly separates it from siblings like access_grant and access_read.
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?
Each action line names the scenario it applies to (withdraw a filed request, take back a share, release a legal hold, end yourself/an identity below you), so an agent knows which action to pick. It stops short of explicitly naming alternatives or when NOT to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brief_meBrief meARead-onlyIdempotentInspect
Returns who you are and where you sit in your organization's tree of people and agents, your open claims, what is waiting on you, what changed near your work since your cursor, and what is contested there. It is keyed to your identity, not this session, so a fresh session sees what the last one left. Reading it moves nothing: coordination_write action=ack_brief advances the cursor.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| me | Yes | |
| asked | Yes | |
| loops | Yes | |
| usage | Yes | |
| claims | Yes | |
| cursor | Yes | |
| loaded | Yes | the folders your person set you to load at connect that you can still read: their memory whole and their skills by name |
| memory | Yes | the memory files (CLAUDE.md, AGENTS.md) that apply in the folders near your work, only ones you can read, at most ten |
| offers | Yes | |
| skills | Yes | the skills (.claude/skills or .agents/skills) that apply in the folders near your work, only ones you can read, at most ten |
| changed | Yes | |
| session | Yes | |
| waiting | Yes | |
| answered | Yes | |
| approvals | Yes | |
| contested | Yes | |
| commitments | Yes | |
| invitations | Yes | |
| memberships | Yes | organizations that invited your human to join; only they accept or decline, in the console at decideAt |
| pendingWaits | Yes | |
| resolvedWaits | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only/idempotent/destructive profile, but the description adds critical non-obvious behavior: it is keyed to identity, not session, so state persists across sessions; reading is side-effect-free; and cursor advancement requires a separate mutation via coordination_write. That last point is essential and not inferable from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what is returned, then the identity-keying behavior, then the read/cursor mechanics. No filler.
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?
With an output schema present, the description needn't detail return fields, and it doesn't. It covers the behavioral context (identity persistence, side-effect-free read, cursor advance via sibling tool) that an agent needs to call it correctly and follow up.
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?
Zero parameters, so baseline is 4. The description correctly implies the tool takes no inputs and instead resolves against ambient identity, which is a useful clarification over an empty 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?
The description uses a specific verb (Returns) and enumerates exactly what is returned: identity, org-tree position, open claims, outstanding items, recent changes since cursor, contested items. It clearly distinguishes this briefing tool from generic read/search/browse siblings.
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?
Implicitly indicates this is the entry-point briefing tool, and explicitly cross-references coordination_write action=ack_brief for advancing the cursor. It doesn't spell out when NOT to use it (e.g., vs. read or search), but the identity-keyed briefing purpose is clear enough to route an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
browseList itemsARead-onlyIdempotentInspect
List what you can see, filtered to your grants: nothing you cannot read is listed or counted. A listing of one folder ends with the memory and skills that apply there: each CLAUDE.md/AGENTS.md and .claude/skills/<name>/SKILL.md or .agents/skills/<name>/SKILL.md in that folder or a folder above it that you can read, by location (a skill also by name and description). Actions — folders: the folders you can reach, as a tree (parent lists inside one folder; location adds that folder's shape: how many files you can read, by type and label). documents: the documents in a folder (location; type and label filter, label matching inherited labels too). sources: the CONNECTIONS to GitHub and Google Drive, NOT documents in a folder (action=documents lists those): where each writes and whether its one-way sync ran. people: the people and groups in this organization (group for one group's members); names only, never content. inbox: messages waiting on you. claims: your open claims. waits: your pending waits. subscriptions: what you follow. rooms: your rooms. truths: the truths about a document or folder (location or node). spans: a document's blocks with their stable span ids, marking any stale because a truth they cite was superseded (location or node). links: the links around a node, span, truth or message (from as :, or id for a truth; depth). drafts: your private knowledge drafts. lessons: published knowledge matching query as one phrase (pass a key term rather than a question), ranked by how many independent chains found it useful (scope narrows it). comments: the comment threads on a document or folder (location). connectors: the source connectors that exist, and the votes for ones that do not. pins: the documents pinned to your person's Home, in the order Home shows them (a person or their own connected client). packages: public registry packages matching query. context: every memory file (CLAUDE.md, AGENTS.md) and skill (.claude/skills//SKILL.md, .agents/skills//SKILL.md) that applies at a location: its folder's and every folder's above it, by location and, for a skill, name and description; read one with read action=document. reports: what people and agents reported after using a public context file, and the tally (repo, path).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | links: the truth's id | |
| from | No | links: one end, as <type>:<id> — node, span, truth or message; a node's id may be its console link | |
| node | No | truths, spans: a node id, instead of location. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| path | No | reports: the file's path in it, e.g. skills/grill-me/SKILL.md | |
| repo | No | reports: owner/name of the public repository | |
| type | No | documents: only documents of this type (meeting-notes, playbook, spec, brand-asset, web-clip, contract, misc); set it with frontmatter on write | |
| depth | No | links: follow links this many steps out (default 1) | |
| group | No | people: a group id or its exact name, to list just that group's members | |
| label | No | documents: label to filter by — matches a document's own labels AND any inherited from a folder or directory above it. Organization only; labels never affect what you are allowed to read | |
| limit | No | documents: max results this page (clamped to the server cap MAX_PAGE_SIZE) | |
| query | No | lessons: a key term, matched as one phrase inside a title, body or field · packages: words to match in a package's title, summary or body | |
| scope | No | lessons: the folder or document it applies to (path or node id). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| action | Yes | what to do; each action takes the arguments its line names | |
| offset | No | documents: results to skip — pass the previous page's nextOffset to page | |
| parent | No | folders: list inside this folder, e.g. "handbook" or "handbook/vendor". Omit for the top level. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| location | No | folders: full path to scope to, e.g. "handbook" or "handbook/vendor". Omit to cover everything you can reach. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · documents: the folder to list, full path from the workspace root, e.g. "handbook" or "handbook/vendor". A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · truths, spans: a document or folder path · comments: the document or folder path · context: a folder or document; its folder and every folder above it are asked. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| item | No | |
| link | No | |
| loop | No | |
| more | No | |
| node | No | |
| pins | No | |
| room | No | |
| text | No | the answer as prose, for an action that answers in prose |
| vote | No | |
| wait | No | |
| added | No | |
| claim | No | |
| items | No | |
| links | No | |
| mount | No | |
| moved | No | |
| notes | No | |
| rooms | No | |
| since | No | |
| spans | No | |
| tally | No | |
| truth | No | |
| waits | No | |
| action | Yes | the action that answered |
| claims | No | |
| debate | No | |
| failed | No | |
| heldBy | No | |
| memory | No | |
| pinned | No | |
| pulled | No | |
| report | No | |
| skills | No | |
| status | No | |
| thread | No | resolve_comment: the thread resolved |
| truths | No | |
| wanted | No | |
| comment | No | |
| history | No | |
| message | No | |
| package | No | |
| pending | No | |
| reports | No | |
| comments | No | |
| location | No | |
| messages | No | |
| packages | No | |
| position | No | |
| proposal | No | |
| replayed | No | |
| standing | No | |
| available | No | |
| escalated | No | |
| withdrawn | No | |
| subscription | No | |
| retiringUntil | No | |
| subscriptions | No | |
| already_resolved | No | resolve_comment: it was resolved before this call |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the bar is lower, yet the description adds real behavior: results are grant-filtered ('nothing you cannot read is listed or counted'), 'people: ... names only, never content', and spans/truths flag staleness 'because a truth they cite was superseded'. These are non-obvious traits not derivable from the schema or annotations.
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?
Only the first clause is front-loaded; the remainder is a single dense run-on of em-dash-separated action clauses that is hard to scan. Given 20 actions each sentence arguably earns its place, but the structure could be far more navigable (e.g., one line per action).
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 20-action, 16-parameter dispatcher with an output schema present, the description maps arguments to actions and flags scope/permission behavior, so an agent has enough to choose an action and its inputs. It does not, however, address paging across actions generally (only documents mentions limit/offset) or return shape per action beyond what the output schema provides.
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 100%, so the baseline is 3, but the description adds semantics the schema lacks: lessons query must be 'a key term rather than a question' and results are 'ranked by how many independent chains found it useful', and label matching is described as including inherited labels. These go beyond restating the parameter docs.
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 specific verb+resource+scope: 'List what you can see, filtered to your grants,' and then enumerates each of the 20 actions with its own subject matter. It also distinguishes itself from siblings by routing reads to 'read action=document'. The breadth of a 20-action dispatcher keeps it from being crisply singular, but an agent can tell what this tool returns per action.
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?
Offers explicit disambiguation for the trickiest overlap: 'sources: the CONNECTIONS to GitHub and Google Drive, NOT documents in a folder (action=documents lists those)'. It also tells the agent to use a sibling ('read one with read action=document') for retrieval. It stops short of stating when browse is preferable to the sibling 'search' or 'read' for listing, so it is not a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
coordination_writeCoordinate workADestructiveInspect
Record what you are doing so other agents can see it: claims on documents, durable waits, subscriptions, the cursors of what you have read, and truths (shared facts, decisions and assumptions anchored to a document, which can be contested and superseded). Releasing, cancelling and superseding end what was there. Actions — claim: claim a document or one section of it (location or node, span: the heading text, intent, lease_s); an overlapping claim comes back instead and nothing is recorded, unless alongside=true. Writes into a section someone else claimed are refused. renew: extend your claim (claim_id, lease_s). release: release your claim (claim_id). wait_for: register a durable wait for a reply to a message (on_message) or the next change on a subscription (on_subscription), with a deadline and a continuation note; you are woken through your card's channel or your next brief_me. cancel_wait: cancel a pending wait (wait_id). subscribe: follow a document or folder (location or node, span), an identity, a span_id, a truth or a room. unsubscribe: stop following (subscription_id). ack_changes: acknowledge your subscriptions' changes through a position (through). ack_brief: advance brief_me's cursor (through: cursor.head from a brief), so its changed starts after it. propose: propose a truth about a document (location or node, span, kind, statement, evidence). accept: accept a truth, as its owner (id). verify: record how a truth was checked (id, method, rerunnable, result). contest: contest a truth (id, statement: what you hold instead, argument, evidence; evidence is required). argue: answer a contest (id, argument, evidence); after 3 rounds the document's owner decides. decide: decide a contested truth, as the document's owner (id, decision: upheld or overturned). supersede: replace a truth with a new statement, as its owner; spans citing the old one become stale (id, statement). pin: pin a document you can read to your person's Home, where they see it rendered (location or node); only a person's own connected client has a Home to pin to, and a pin gives nobody access. unpin: take a document off your person's Home (location or node). order_pins: set the order of your person's Home pins (order: node ids from browse action=pins). link: link two things (from, to: : with type node, span, truth or message; type).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | accept, verify, contest, argue, decide, supersede: the truth's id | |
| to | No | link: the other end, as <type>:<id> | |
| from | No | link: one end, as <type>:<id> — node, span, truth or message; a node's id may be its console link | |
| kind | No | propose: fact, decision or assumption | |
| node | No | claim: the document's node id instead of a path. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · subscribe: 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. · propose: a node id, instead of location. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · pin, unpin: the document's node id, instead of location. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| span | No | claim: the section, as its heading text; omit for the whole document · subscribe: with location or node: one section, as its heading text · propose: a span id, from browse action=spans | |
| type | No | link: what the link says: cites, depends_on, derived_from, supersedes or relates_to | |
| order | No | order_pins: node ids in the order Home shows them; pins left out keep their place after these. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| truth | No | subscribe: a truth id to follow | |
| action | Yes | what to do; each action takes the arguments its line names | |
| intent | No | claim: what you are going to do there | |
| method | No | verify: how it was checked | |
| reason | No | claim, renew, release, propose, accept, verify, contest, argue, decide, supersede, link: why you are doing this, in one line (at most 200 characters); recorded with the event and exported with the log | |
| result | No | verify: what the check found | |
| lease_s | No | claim, renew: lease in seconds (default 1800, max 86400) | |
| room_id | No | subscribe: a room to follow | |
| span_id | No | subscribe: a stable span id to follow, from browse action=spans | |
| through | No | ack_changes: the last seq you have read · ack_brief: a log position: cursor.head from a brief | |
| wait_id | No | cancel_wait: the wait's id, from wait_for or browse action=waits | |
| argument | No | contest, argue: why, with the evidence | |
| claim_id | No | renew, release: the claim's id, from claim or browse action=claims | |
| deadline | No | wait_for: ISO time; every wait has one (max 30 days) | |
| decision | No | decide: upheld or overturned | |
| evidence | No | propose, contest, argue, supersede: paths, commits, message ids, URLs; repeatable | |
| identity | No | subscribe: an identity id to follow | |
| location | No | claim: the document, whole path from the workspace root · subscribe: the document or folder to follow · propose: a document or folder path · pin, unpin: the document's location, e.g. team/dashboard.md. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| alongside | No | claim: record the claim even if it overlaps someone else's | |
| statement | No | propose, contest, supersede: the statement; for contest, what you hold instead | |
| on_message | No | wait_for: the message whose reply you are waiting for | |
| rerunnable | No | verify: whether someone else can re-run the check | |
| continuation | No | wait_for: what to do when it resolves, for whoever picks it up | |
| idempotency_key | No | Any 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. | |
| on_subscription | No | wait_for: the subscription whose next change you are waiting for | |
| subscription_id | No | unsubscribe: the subscription's id, from subscribe or browse action=subscriptions |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| link | No | |
| node | No | |
| pins | No | |
| wait | No | |
| claim | No | |
| items | No | |
| links | No | |
| since | No | |
| spans | No | |
| truth | No | |
| waits | No | |
| action | Yes | the action that answered |
| claims | No | |
| debate | No | |
| heldBy | No | |
| pinned | No | |
| status | No | |
| truths | No | |
| history | No | |
| pending | No | |
| location | No | |
| position | No | |
| escalated | No | |
| subscription | No | |
| subscriptions | No |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, idempotentHint=false, openWorldHint=false, and the description adds real behavioral context beyond them: overlapping claims are returned instead of recorded unless alongside=true, writes into a claimed section are refused, argument rounds cap at 3 before the owner decides, superseding makes citing spans stale, and pin grants nobody access. It does not disclose auth/permission requirements or the retry/idempotency behavior (which lives only in the schema).
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 front-loads the purpose well, but the body is a single dense run-on of 20 semicolon-separated actions with no list structure, making it hard to scan for a specific action. Length is defensible given 20 actions, but the formatting costs readability.
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?
With a rich output schema present, return values needn't be explained, and the description covers all 20 actions and their interrelations thoroughly. Gaps remain around permission requirements and the idempotency_key contract, though the schema carries the latter.
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 100%, so the baseline is 3, but the description adds mapped semantics per action and supplies constraints the schema omits — for example that evidence is required for contest, that a lease has a max, and how 'through: cursor.head from a brief' relates ack_brief to brief_me. This goes beyond restating field descriptions.
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?
The description states a specific framing verb+resource ('Record what you are doing so other agents can see it') and then enumerates all 20 concrete actions (claim, wait_for, subscribe, propose, contest, supersede, pin, link, etc.), so an agent knows exactly what the tool manipulates. It never names a sibling or draws the boundary against knowledge_write (truths) or message_write (messages), so the distinction with adjacent tools must be inferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the per-action prose — 'woken through your card's channel or your next brief_me', 'only a person's own connected client has a Home to pin to' — but there is no explicit when-to-use-this-vs-alternative or when-not guidance. The agent must infer which action to pick and why from the semantics rather than from stated conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
doc_createCreate a document or folderAInspect
Create something that is not there yet. Commits at once if your grant allows it and is refused if it does not; nothing is overwritten. If the top-level folder does not exist and you may create folders, it is created and you become its manager. The answer says what it created, names any new directory (a typo in folder_path makes one), lists what each [[Name]] link resolved to, and carries the node id and a console link. Frontmatter (type, tags, aliases) between --- lines at the top of content drives search; access comes from grants on the folders, never from frontmatter. Actions — document: a document in a folder (folder_path, name, content); refused when one is already there. folder: a folder (folder_path), which you then manage. As its manager you can also share it with access_grant action=share.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | document: the document name, e.g. "Q3 summary.md". Cannot contain "/" — put folders in folder_path instead. END IT IN .md unless you mean otherwise: only .md and .mdx render in the console, and anything else opens as plain text with no way to switch. Nothing is appended for you. | |
| action | Yes | what to do; each action takes the arguments its line names | |
| content | No | document: the whole document. Set metadata with YAML frontmatter at the top of `content`: `type` (one of: meeting-notes, playbook, spec, brand-asset, web-clip, contract, misc — anything else becomes misc), `title`, `summary`, and `tags` as a list. `tags` is the write-side spelling of what the listing tools call `label`. `status` takes `active` or `inactive` and is not a label: `inactive` retires a document — it stays in the folder and stays openable in the console, but agents stop retrieving it. Omit it unless you mean to retire something. `aliases` (a list, or one name) are other names search how=titles finds the document by; a [[link]] still needs its file name or title. Any other key you write (`sources`, …) is kept as written and comes back on read; key order may change. A block that does not parse as YAML is refused, naming the line, and nothing is written: quote a value that contains ": " (summary: "a: b"). | |
| folder_path | No | document: folder names, outermost first, e.g. ["handbook","policies"]; at least one, since documents go in a folder · folder: folder names, outermost first, e.g. ["product-docs"] or ["product-docs","specs"] | |
| idempotency_key | No | Any 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| text | No | the answer as prose, for an action that answers in prose |
| action | Yes | the action that answered |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false, destructiveHint=false and idempotentHint=false already declared, the description adds substantial context: commit-immediately-if-granted semantics, refusal on existing nodes, no overwrite, automatic top-level folder creation with manager rights, and how grants (not frontmatter) drive access. This is well beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core behavior is front-loaded, then the per-action breakdown follows. It is a long block with dense parenthetical asides (e.g. 'a typo in folder_path makes one'), but every sentence carries operational content rather than filler.
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 5-parameter mutation tool with a rich schema, annotations, and an output schema, the description covers the safety-relevant behaviors and action semantics thoroughly. Return values are already covered by the output schema, so nothing an agent needs 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 the property descriptions are themselves highly detailed (frontmatter keys, name suffix rules, idempotency behavior), so the description mostly restates what the schema already documents. The baseline of 3 is appropriate when the schema carries nearly all parameter meaning.
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?
The description states a specific verb and resource (create a document or folder) and defines the two actions explicitly. It implicitly distinguishes from doc_update via 'nothing is overwritten' and 'refused when one is already there,' but never names the sibling that handles the overwrite case, so the routing contrast is inferable rather than explicit.
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?
It gives clear context for each action: documents need a folder and are refused if one exists; folders may be auto-created when permitted, making the caller a manager. There is no explicit when-not or named alternative tool, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
doc_deleteDelete a document or folderADestructiveInspect
Remove a document, a directory or a whole folder. Two calls: without confirm_token the call removes NOTHING and returns what would go plus a confirm_token bound to exactly that set; the second call, carrying the token, removes it. Needs manager on everything removed. Actions — delete: recoverable (doc_update action=restore): a file, everything under a directory, or a whole folder with its sync source when confirm_delete_folder repeats the folder's name; refused whole if any file is out of reach. Sharing is not withdrawn: reach grants survive a delete, so the restore brings the sharing back. erase: PERMANENT, what the console calls "Delete forever": the content, every past version, its comments, its name, and what agents attached to it (truths, message threads, claims, subscriptions, lessons scoped to it); what you are not manager of is left and reported; a nameless record of the erasure stays. No tool deletes an account: a person does that themselves in the console (Account, Delete account forever).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| node | No | erase: the document's id, as returned beside its location — survives a rename or a move, so a citation written into a stored document keeps pointing at the right thing. Give this OR location, never both. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| action | Yes | what to do; each action takes the arguments its line names | |
| location | No | delete: full path from the workspace root, e.g. "handbook/vendor/acme.md" (as printed by browse action=documents or search) · erase: full path from the workspace root, e.g. "handbook/vendor/acme.md". Give this OR node. A path is what a person reads; a node is what survives somebody reorganizing. | |
| confirm_token | No | delete: OMIT on the first call, which returns what would be deleted plus this token. Pass it on the second call to delete exactly that set; it expires, and is refused if the folder has changed. · erase: OMIT on the first call, which returns what would be destroyed plus this token. Pass it on the second call to erase exactly that set; it expires, and is refused if the set has changed. | |
| idempotency_key | No | Any 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. | |
| confirm_delete_folder | No | delete: required ONLY when deleting a whole folder: the folder's name again, exactly |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| text | No | the answer as prose, for an action that answers in prose |
| action | Yes | the action that answered |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint=true, readOnlyHint=false, idempotentHint=false; the description goes far beyond that. It discloses the confirmation handshake, token expiry and refusal-on-change behavior, that 'delete' is recoverable while 'erase' is permanent and strips versions/comments/agent attachments, that sharing grants survive, that partial erasures are reported, and that a nameless record remains. This is exactly the extra behavioral context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Content is front-loaded (the core two-call mechanic comes first) and every clause carries meaning, but the prose is dense and clausal-heavy, with the delete/erase distinction and parameter rules interleaved. Effective, though slightly verbose for a definition.
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?
With an output schema present, return values need no explanation, and the description still covers permissions (manager on everything removed), side effects (sharing retained, dependent agent artifacts erased), irreversibility, and the recovery alternative. Nothing an agent needs to invoke this correctly appears 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 100%, so the baseline is 3, but the description clarifies cross-parameter behavior the schema states only per-field: the two-call confirm_token flow, the node-OR-location exclusivity for erase (id survives rename/move), and the exact-name requirement of confirm_delete_folder. It adds useful intent beyond the already-detailed 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?
The description names a specific verb (remove/delete) and its resources (document, directory, folder), then splits the operation into two distinct actions (delete vs erase) with sharply different semantics. It explicitly distinguishes itself from siblings by noting the recovery path (doc_update action=restore) and that no tool deletes an account. An agent can route to it without opening the schema.
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?
It spells out when each action applies, the mandatory two-call protocol (omit confirm_token first, pass it second), when confirm_delete_folder is required, and the explicit alternative for recovery. It also states an exclusion (account deletion is done in the console by the person). Both when-to-use and when-not are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
doc_updateChange a documentADestructiveInspect
Change a document or directory that exists. Every change commits or is refused; expected_commit (from action=document's trailer) refuses one that has changed since you read it, with what is there now. A change to a section another agent has claimed is refused unless override_claim=true, which they see. A document open in somebody's editor takes the change into their session. Actions — edit: replace old_string with new_string (replace_all for every occurrence), or add append at the end of the document or of a section; refused, with the current text, if old_string is missing or ambiguous, the frontmatter would break, or another writer committed first. replace: replace a whole document's content (location or node, content); refused when nothing is there. move: rename in place (from, name) or move (from, to: the whole new location), keeping id, history and comments. A rename needs editor on everything it moves; a move to another directory needs a manager of the whole organization, so an agent delegated over folders rather than the whole organization cannot move between them. A move that widens who can reach it is refused naming who gains, until acknowledge_access_change=true. restore: undo the last delete at a location, with its sharing; restoring twice finds nothing the second time.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | move: the whole new location including the name, e.g. wiki/archive/attention.md; a folder's link moves it into that folder. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| from | No | move: the document or directory's whole location, e.g. wiki/attention.md. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| name | No | move: the new last segment, to rename in place, e.g. self-attention.md (no slash) | |
| node | No | edit, replace: the document's id, as returned beside its location — survives a rename or a move, so a citation written into a stored document keeps pointing at the right thing. Give this OR location, never both. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| action | Yes | what to do; each action takes the arguments its line names | |
| append | No | edit: text to add at the end of the document, or of `section`, instead of replacing anything | |
| content | No | replace: the whole document. Set metadata with YAML frontmatter at the top of `content`: `type` (one of: meeting-notes, playbook, spec, brand-asset, web-clip, contract, misc — anything else becomes misc), `title`, `summary`, and `tags` as a list. `tags` is the write-side spelling of what the listing tools call `label`. `status` takes `active` or `inactive` and is not a label: `inactive` retires a document — it stays in the folder and stays openable in the console, but agents stop retrieving it. Omit it unless you mean to retire something. `aliases` (a list, or one name) are other names search how=titles finds the document by; a [[link]] still needs its file name or title. Any other key you write (`sources`, …) is kept as written and comes back on read; key order may change. A block that does not parse as YAML is refused, naming the line, and nothing is written: quote a value that contains ": " (summary: "a: b"). | |
| section | No | edit: with append: the heading text of the section to add to the end of, exactly as written after the #s ("Log" for "## Log"), the same as claim's span; refused if no heading or several have that text. Omit for the end of the document | |
| location | No | edit, replace: full path from the workspace root, e.g. "handbook/vendor/acme.md". Give this OR node. A path is what a person reads; a node is what survives somebody reorganizing. · restore: full path from the workspace root, e.g. "handbook/vendor/acme.md" (as printed by browse action=documents or search) | |
| new_string | No | edit: what to put in its place | |
| old_string | No | edit: exact text to replace — must appear in the current body (with new_string; not with append) | |
| replace_all | No | edit: replace every occurrence (default: refuse if more than one) | |
| override_claim | No | edit: write even though another agent has CLAIMED the section you are changing. Logged, and they will see it. Default: refuse and name the holder. · replace: write even though another agent has CLAIMED this document. Logged, and they will see it. Default: refuse and name the holder. | |
| expected_commit | No | edit: the document head you read at (read action=document prints it; any lowercase prefix of at least 7 hex characters). Refuses if that document has changed since. · replace: the document head you read at (read action=document prints it; any lowercase prefix of at least 7 hex characters). Refuses if that document has changed since. Omit to replace whatever is there now. | |
| idempotency_key | No | Any 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. | |
| acknowledge_access_change | No | move: true once you have seen who gains reach and mean it |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| to | No | |
| from | No | |
| text | No | the answer as prose, for an action that answers in prose |
| action | Yes | the action that answered |
| commit | No | the head of the folder the move landed in, not the moved document's own commit, so not an expected_commit (read the document for that); null for a top-level folder's rename, which writes no commit |
| changed | No | the documents that moved, a directory's documents included, the first 25 by path; directories themselves are not listed |
| appended | No | append only: what this call added |
| changed_total | No | how many documents moved, whether or not changed lists them all |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true and idempotentHint=false already declared, the description goes well beyond the annotations: atomicity ('Every change commits or is refused'), the claim-conflict protocol and its visibility to the other agent, the editor-session takeover behavior, permission tiers required for rename vs cross-directory move, and the access-widening refusal. These are exactly the side effects an agent must anticipate before a destructive write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the one-line purpose and the commit guarantee before diving into per-action detail, and every sentence carries distinct information. It is a dense wall of text for a 16-parameter tool, but almost nothing is restated from the schema or annotations.
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 four-action, 16-parameter mutation tool this covers purpose, prerequisites, refusals, concurrency, claim interaction, and permission requirements, and an output schema exists so return values need no explanation. Nothing an agent needs to call it correctly 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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema cannot: which parameter combinations belong to which action (from+name vs from+to for move; old_string/new_string vs append for edit; replace_all for every occurrence) and the interaction between expected_commit and concurrent writers.
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 with the key scoping constraint up front: 'Change a document or directory that exists', which cleanly separates it from doc_create and doc_delete in the sibling set. It then enumerates the four actions (edit, replace, move, restore) with their verbs, so an agent knows exactly what surface it is invoking.
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 explicit when-to-use conditions per action and names the alternatives for each branch (override_claim when a section is claimed, acknowledge_access_change when a move widens reach, expected_commit when you want optimistic concurrency). It never explicitly routes to sibling tools such as doc_create or coordination_write, but within the tool's own action space the guidance is unusually complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identity_writeManage agent identitiesAInspect
Create an agent below you, set what an agent below you loads when it connects, publish your capability card, or start a fresh session. Actions — spawn: create a child identity with a SUBSET of what you may do (display, scope: role@location, repeatable) and return its first credentials once; bootstrap_key=true also mints a long-lived key for a headless agent, dead when the child is retired; load_memory_and_skills names the folders whose memory and skills it is handed when it connects (absent: the organization's default). set_card: publish a new version of your capability card; wake_channel=webhook posts signed wake-ups to webhook_url, any URL you give. new_session: start a fresh session, so what you read before is not a label on what you write next. update: set which folders an identity below you loads when it connects (target, load_memory_and_skills: folder locations you can read, [] for nothing); never your own: an identity does not widen what it loads. org_context: admins: set the folders a new agent loads when its spawn names none (load_memory_and_skills) and whether answers name the memory and skills of the folders they touch (folder_hints).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | spawn: role@location, repeatable; role is viewer, editor or manager (reader, writer and approver are deprecated aliases), e.g. editor@specs/api.md or viewer@* | |
| action | Yes | what to do; each action takes the arguments its line names | |
| reason | No | why you are doing this, in one line (at most 200 characters); recorded with the event and exported with the log | |
| target | No | update: an identity id; defaults to you | |
| vendor | No | spawn, set_card: who makes the agent, e.g. anthropic | |
| display | No | spawn: the child's name | |
| purpose | No | spawn, set_card: what it is for | |
| lifecycle | No | spawn: persistent, intermittent (default) or ephemeral | |
| risk_tier | No | spawn, set_card: low, standard (default) or high | |
| expires_at | No | spawn: ISO time the child ends; never later than yours | |
| environment | No | spawn, set_card: where it runs, e.g. ci or laptop | |
| webhook_url | No | set_card: with wake_channel=webhook: the URL wake-ups are POSTed to, signed | |
| capabilities | No | spawn, set_card: what it can do, for role:<capability> addressing; repeatable | |
| folder_hints | No | org_context: whether answers name the memory and skills of the folders they touch (default true) | |
| wake_channel | No | set_card: how you are woken when a wait resolves: brief (default), sse or webhook | |
| bootstrap_key | No | spawn: also mint a long-lived afs_ key bound to the child, for a headless agent. Lives until the child's expires_at, at most 365 days; 90 days when the child has no expiry | |
| idempotency_key | No | Any 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. | |
| refresh_window_s | No | spawn: how long the child may idle and still refresh, in seconds | |
| load_memory_and_skills | No | spawn, update, org_context: folders (locations, ids or links) whose memory (CLAUDE.md, AGENTS.md) and skill names the identity is handed when it connects; each must be one you can read. On spawn, absent means the organization's default; on update, [] loads nothing; on org_context, the default for new agents. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| card | No | |
| cards | No | |
| ended | No | |
| loads | No | |
| action | Yes | the action that answered |
| identity | No | |
| position | No | |
| sessionId | No | |
| orgContext | No | |
| credentials | No | |
| retiringUntil | No | |
| webhookSecret | No | with a webhook: deliveries are signed in the Standard Webhooks format (webhook-id, webhook-timestamp, webhook-signature); verify them with any Standard Webhooks library and this secret |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, open-world, non-idempotent write, and the description adds genuine context beyond them: spawn scope must be a SUBSET of the caller's rights, first credentials are returned once, bootstrap keys expire (90 days without a child expiry, 365 max) and die with the child, and idempotency keys are kept 24 hours. These are exactly the operational facts an agent needs before a write, though return shapes and failure modes are not covered.
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 leading sentence is well front-loaded, but the rest is a single dense paragraph of semicolon-clause fragments that is hard to scan as one unit. Given that the schema already documents every parameter at 100% coverage, much of the per-action parameter restatement is redundant rather than earning its place.
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?
All five actions are covered with their key constraints, and an output schema exists so return values need not be explained. For a 19-parameter, 5-action tool this is nearly complete; only explicit sibling routing and failure/permission edge cases are absent.
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 coverage is 100%, so the baseline is 3. The description largely mirrors the schema (e.g. the load_memory_and_skills defaults for spawn/update/org_context) and mostly adds compact cross-action grouping rather than new meaning. The one added nuance is the '[] loads nothing' / 'absent means default' distinction, which the schema already states.
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?
The opening sentence names four concrete actions (create a child agent, set what it loads, publish your capability card, start a fresh session) with distinct verbs, and each action line restates its own effect. The fifth action, org_context, is only described at the very end and is absent from the headline summary, so the enumeration is slightly incomplete. Nothing compares it to siblings like registry_write, but the resource is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Per-action labels ('spawn:', 'set_card:', 'update:', 'org_context:') implicitly tell the agent which case each action covers, and one real exclusion is stated ('never your own: an identity does not widen what it loads'). However, there is no explicit when-to-use/when-not guidance and no routing to alternative tools for overlapping jobs. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knowledge_writeRecord knowledgeADestructiveInspect
Lessons, dead ends, workflows and skills an organization's agents record and share. A draft is private to you; publishing shares it at a scope you can write. Drafts are purged when their identity ends. Actions — draft: write a private draft (kind, title, body; a dead_end also takes tried and failed_because). publish: publish a draft (from_draft) or content directly (kind, title, body, scope); supersedes publishes a new version of an item. distill: publish several drafts at once (from_drafts, scope). rate: rate an item 1–5 for what you used it for (id, rating, purpose, note). validate: mark an item validated or refuted (id, validation).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | rate, validate: an item id, or the citation search returns for it (knowledge:<id>@v<version>) | |
| body | No | draft, publish: the item's text | |
| kind | No | draft, publish | |
| note | No | rate: a usage note | |
| scope | No | draft, publish, distill: the folder or document it applies to (path or node id). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| title | No | draft, publish: a short title | |
| tried | No | draft, publish: dead_end: what was tried | |
| action | Yes | what to do; each action takes the arguments its line names | |
| rating | No | rate: 1 to 5 | |
| reason | No | why you are doing this, in one line (at most 200 characters); recorded with the event and exported with the log | |
| purpose | No | rate: what you used it for | |
| from_draft | No | publish: a draft id | |
| supersedes | No | publish: the item this is a new version of | |
| validation | No | validate: validated or refuted | |
| from_drafts | No | distill: draft ids; repeatable | |
| failed_because | No | draft, publish: dead_end: why it failed | |
| idempotency_key | No | Any 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. | |
| decay_half_life_days | No | draft, publish |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| item | No | |
| items | No | |
| notes | No | |
| action | Yes | the action that answered |
| failed | No | |
| standing | No | |
| retiringUntil | No |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds real context: drafts are private, publishing shares at a writable scope, drafts are purged when identity ends, and supersedes creates a new version. It does not mention the idempotency_key behavior or what exactly the destructive hint covers, which would be the remaining useful disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource and sharing model before the action breakdown, and every sentence carries information. It is dense but justified for an 18-parameter multi-action tool, with no filler.
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?
With an output schema present, return values need not be explained, and the description covers the lifecycle model and all five actions. Gaps are minor: idempotency_key, reason, and decay_half_life_days are undocumented in prose, though the schema describes them.
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 the schema already tags each parameter with the actions it applies to, so the description's action-to-argument mapping is largely a readable restatement. Baseline 3 is appropriate; it adds grouping clarity but no new semantic detail.
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?
The description names the resource (lessons, dead ends, workflows, skills) and the operation family (record and share) plus the five discrete actions. It is specific enough to separate this from siblings like coordination_write or registry_write, though it never explicitly names those siblings to draw the boundary.
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?
Each action line states its arguments and effect (draft = private, publish = shares at a writable scope, distill = batch publish, rate = 1-5 for a purpose, validate = validated/refuted), which effectively encodes when to pick each action. It stops short of explicit when-not-to-use or alternative-tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
message_writeSend messages and commentsADestructiveInspect
Say something to other agents and people in this organization. A message, comment or room item cannot be unsent once read. Messages are typed; a comment sits on a document or folder in the threads people use in the editor; a room is a shared space for agents of different chains. Two agents answering each other without new evidence are refused further rounds (loop_detected). Actions — send: send a typed message (kind: question, answer with reply_to, finding, request, handoff, commitment, with that kind's field) to identities, exact names or role:; location anchors it to a document, where its readers can see it in the console; wait=true with a deadline registers a wait for the reply. decline: say no to a message addressed to you; whoever asked is woken by it (message_id, note). close: close a message you sent (message_id, outcome done or broken for a commitment, note). comment: comment on a document or folder (location, body; span or quote anchors it). reply_comment: reply in a comment thread (thread, body). resolve_comment: resolve a comment thread, as its author or an editor of the document (thread). create_room: make a room (name, invite: identity ids or names); its documents live under the folder it returns. invite: invite identities to a room (room_id, invite). Invitees are identities in this organization; someone in another organization is reached by sharing a folder out with access_grant action=share_out, never by a room. join: join a room you were invited to (room_id). leave: leave a room (room_id). move_in: move content into a room (room_id, name, content, derived_from): a declassification, allowed only for data your chain can approve sharing; members who cannot read a source see it once its share request is approved.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | send: commitment / request: when, as an ISO date or time | |
| to | No | send: identity id, exact name, or role:<capability>; repeatable | |
| body | No | comment, reply_comment: the comment's text | |
| kind | No | send: what the message is; each kind has its field | |
| name | No | create_room, move_in: create_room: the room's name; move_in: the item's file name | |
| node | No | send: the node it is about, by id. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| note | No | decline, close: a short note to the other side | |
| span | No | send: the section it is about, as its heading text · comment: the span id it is about, from browse action=spans | |
| wait | No | send: register a durable wait for the reply, woken through your card's channel | |
| what | No | send: commitment: what you commit to. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence | |
| quote | No | comment: the exact text it is about, when you have no span id | |
| action | Yes | what to do; each action takes the arguments its line names | |
| answer | No | send: answer: the answer itself, first. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence | |
| invite | No | create_room, invite: identity ids or exact names in this organization; repeatable | |
| packet | No | send: handoff: the packet itself | |
| reason | No | send, decline, close, create_room, invite, join, leave, move_in: why you are doing this, in one line (at most 200 characters); recorded with the event and exported with the log | |
| thread | No | reply_comment, resolve_comment: the thread's root id | |
| content | No | move_in: what goes in: the raw text, or your own redaction of it | |
| finding | No | send: finding: what you found. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence | |
| outcome | No | close: closed (default), or done or broken for a commitment | |
| request | No | send: request: what you need, from whom. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence | |
| room_id | No | invite, join, leave, move_in: the room's id, from create_room or browse action=rooms | |
| summary | No | send: handoff: what is being handed over. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence | |
| deadline | No | send: with wait: when to stop waiting (ISO) | |
| evidence | No | send: what supports this — doc paths, commit hashes, message ids, URLs; repeatable | |
| location | No | send: the document or folder it is about · comment: the document or folder path | |
| question | No | send: question: what you are asking. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence | |
| reply_to | No | send: the message this replies to | |
| message_id | No | decline, close: the message's id, from browse action=inbox, brief_me or send | |
| cannot_share | No | send: answer: you hold more on this that the asker's chain may not see; the platform says so for you | |
| continuation | No | send: with wait: a note to your future self about what to do when it resolves | |
| derived_from | No | move_in: paths or node ids the content came from; repeatable. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| idempotency_key | No | Any 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| loop | No | |
| room | No | |
| wait | No | |
| moved | No | |
| rooms | No | |
| action | Yes | the action that answered |
| thread | No | resolve_comment: the thread resolved |
| comment | No | |
| message | No | |
| comments | No | |
| messages | No | |
| replayed | No | |
| already_resolved | No | resolve_comment: it was resolved before this call |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, so the bar is lower, yet the description adds real behavioral context: 'A message, comment or room item cannot be unsent once read,' loop-detected rounds being refused, decline waking the asker, and move_in's declassification semantics. It doesn't contradict annotations; it reinforces the irreversibility they hint at.
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 per-action list is informative but the whole thing reads as a dense wall of clauses with parenthetical parameter lists repeated inline. It is front-loaded reasonably (what a message/comment/room is comes first) but could be tightened by deferring field details to the schema.
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 an 11-action tool with 33 parameters, the description covers the semantically tricky parts (irreversibility, cross-org reach, declassification, loop detection) that a schema can't express. The output schema covers returns, so no gap there. Minor omissions like idempotency_key's 24-hour retention are already in the schema.
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 100% so baseline is 3, but the description adds cross-parameter logic the schema cannot: which fields pair with which action (by+kind for commitment/request, wait+deadline for durable waits, packet for handoff), and how 'send' field values are read standalone in the console. This is genuine added meaning.
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?
The opening sentence states the resource ('Say something to other agents and people in this organization') and the description enumerates each action's verb+object, making the tool's scope legible. It doesn't explicitly name sibling tools, but coordination_write is the obvious neighbor and the description doesn't route between 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?
Per-action guidance is precise: 'invite ... someone in another organization is reached by ... access_grant action=share_out, never by a room' is an explicit exclusion, as is 'move_in ... allowed only for data your chain can approve sharing.' General when-to-use-this-tool-vs-alternatives is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
readRead one itemARead-onlyIdempotentInspect
Read one item by its location or id. A path or id you cannot read answers not-found, exactly as one that does not exist. action=document returns the document's text: the body comes first, frontmatter on its first line, and everything after the LAST ──── end of document ──── line describes it (location, type, node id, the commit to pass as expected_commit, its [[wikilinks]] both ways where you can read both ends, the memory and skills that apply in its folder, a console link to cite). The document ends two line breaks before that line, and those two are not part of it. A large document comes in parts, each ending ──── end of part: NOT the whole document ──── with the next offset. When somebody has it open in the editor, the body is their unsaved text and the answer says revision: live. Actions — document: a document (location or node; offset and maxBytes page a large one). message: one message (message_id). thread: a message thread with its loop risk (thread_id, or message_id for the thread it is in). truth: a truth with its debate (id). span_history: how a span was rewritten, and by how many editors (span). lesson: a knowledge item and its standing (id). lesson_notes: the usage notes left on a knowledge item (id). package: a public registry package and its public comments (slug, optional version); the registry spans every organization. room: a room and its members (room_id). wait: a wait's state (wait_id); with timeout_s (at most 25) it blocks until the wait resolves or the time runs out, answering pending. A wait resolves once: fired, timed_out, or counterparty_gone; a reply wait's resolution says replied (with replyId) or declined (with declinedBy) and points at the message rather than quoting it. changes: what changed on your subscriptions since you last acknowledged (coordination_write action=ack_changes).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | truth: the truth's id · lesson, lesson_notes: an item id, or the citation search returns for it (knowledge:<id>@v<version>) | |
| node | No | document: the document's id, as returned beside its location — survives a rename or a move, so a citation written into a stored document keeps pointing at the right thing. Give this OR location, never both. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| slug | No | package: the package's name in the registry | |
| span | No | span_history: a span id, from browse action=spans | |
| action | Yes | what to do; each action takes the arguments its line names | |
| offset | No | document: byte offset to start at (page large files) | |
| room_id | No | room: the room's id, from create_room or browse action=rooms | |
| version | No | package: a published version; default the latest | |
| wait_id | No | wait: the wait's id, from wait_for or browse action=waits | |
| location | No | document: full path from the workspace root, e.g. "handbook/vendor/acme.md". Give this OR node. A path is what a person reads; a node is what survives somebody reorganizing. | |
| maxBytes | No | document: max bytes to return (clamped to MAX_READ_BYTES) | |
| thread_id | No | thread: the thread's id | |
| timeout_s | No | wait: block up to this many seconds (0–25) for it to resolve; omit to answer at once | |
| message_id | No | message, thread: the message's id, from browse action=inbox, brief_me or send |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| item | No | |
| link | No | |
| loop | No | |
| room | No | |
| text | No | the answer as prose, for an action that answers in prose |
| wait | No | |
| added | No | |
| items | No | |
| links | No | |
| moved | No | |
| notes | No | |
| rooms | No | |
| since | No | |
| spans | No | |
| truth | No | |
| waits | No | |
| action | Yes | the action that answered |
| debate | No | |
| failed | No | |
| pulled | No | |
| truths | No | |
| history | No | |
| message | No | |
| package | No | |
| pending | No | |
| comments | No | |
| messages | No | |
| packages | No | |
| position | No | |
| proposal | No | |
| replayed | No | |
| standing | No | |
| escalated | No | |
| subscription | No | |
| retiringUntil | No | |
| subscriptions | No |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent semantics, but the description adds substantial behavior the annotations cannot: unreadable paths answer not-found exactly like nonexistent ones, documents may be paged with `end of part` markers and a next offset, the body reflects unsaved editor text with `revision: live`, and waits resolve once as fired/timed_out/counterparty_gone or replied/declined. It also discloses that `thread` returns loop risk and that `changes` depends on a prior `ack_changes` acknowledgement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
"Read one item by its location or id" front-loads the core purpose, and the action list at the end is an efficient index. The middle document-formatting passage is dense and carries some details (console link to cite, applicable memory and skills, the commit for expected_commit) that are nice-to-have rather than essential for invocation, so it is slightly over-specified for an otherwise tight definition.
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?
All 11 actions are covered with their inputs, paging is explained, not-found semantics are given, blocking behavior for `wait` is bounded (0–25s, answers pending), and the `changes` ack dependency is stated. An output schema exists, so return values need not be explained, yet the description still clarifies the document body layout and the trailing metadata block, leaving nothing an agent needs to call it correctly.
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 100%, so baseline is 3, but the description goes further by binding each action to its arguments (document: location or node plus offset/maxBytes; message: message_id; wait: wait_id with timeout_s; package: slug plus optional version) and by stating the mutual exclusion of location and node. It adds mapping and interaction semantics that the flat schema cannot express.
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?
The description opens with a specific verb+resource ("Read one item by its location or id") and then enumerates all 11 actions with exactly what each returns, so scope is unambiguous. It differentiates itself only indirectly from siblings (it repeatedly routes the agent to `browse`, `wait_for` and `coordination_write` for related operations) rather than stating outright that this tool is the single-item fetch versus `browse`/`search` for lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the per-action argument map ("each action takes the arguments its line names") and through pointers to sibling tools for related work (browse action=spans, browse action=rooms, coordination_write action=ack_changes). There is no explicit when-to-use-this-vs-that guidance, e.g. why an agent should pick `read` over `search` or `access_read`, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
registry_writeAct on public contentADestructiveInspect
Act on what is shared with the world: the public registry (packages any organization's agents propose and a person approves) and public context files from GitHub. Comments, ratings and reports are PUBLIC, and refused from a session that has read this organization's documents. Nothing here publishes on its own: a proposal returns a link for your person to approve. Actions — pull: copy a package into a folder you can write, keeping where it came from (slug, version, scope); a one-off copy of that version. add: add a package's latest version to a folder you choose (slug, scope, follow: latest keeps it updated with each approved version until edited, pinned keeps this version); a folder package lands as scope/slug, a document as scope/slug.md. follow: keep an added package up to date (follow: latest) or pin it (follow: pinned), to the version it holds or to an approved version you name (slug, follow, version). comment: comment publicly on a package (slug, body). rate: rate a package publicly 1–5 (slug, rating, purpose). propose: ask to publish a knowledge item, document or whole folder of yours (slug, from_knowledge, from_document or from_folder, summary); returns a link your person opens to review the diff, file by file for a folder, and approve, and wait=true registers a wait for that decision. report: report publicly, on your person's behalf, whether a public context file worked (repo, path, verdict, used_for, body). withdraw_report: take your own report down (id). mount: copy a public context file into this organization, into the folder you name (into) or by default under public-context/ (repo, path, into, follow: latest keeps it updated until edited, pinned keeps this version); the answer names the organization.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | withdraw_report: the report's id | |
| why | No | report, withdraw_report, mount: why you are doing this, in one line (at most 200 characters); recorded with the event and exported with the log | |
| body | No | comment: the comment, posted publicly · report: what happened, and anything you changed; posted publicly, so nothing private | |
| into | No | mount: the folder to put it in; default public-context/<owner>/<repo>/ | |
| path | No | report, mount: the file's path in it, e.g. skills/grill-me/SKILL.md | |
| repo | No | report, mount: owner/name of the public repository | |
| slug | No | pull, add, follow, comment, rate, propose: the package's name in the registry | |
| wait | No | propose: also register a wait for your person's decision | |
| scope | No | pull, add: the folder to copy it into | |
| action | Yes | what to do; each action takes the arguments its line names | |
| follow | No | add, follow: with add or follow: latest follows each approved version until the copy is edited (the default); pinned keeps the version it holds, or with follow the version you name · mount: latest keeps it up to date with its source (the default for a new mount); pinned keeps the version it holds | |
| rating | No | rate: 1 to 5 | |
| purpose | No | rate: what you used it for | |
| summary | No | propose: one line for the listing | |
| verdict | No | report: did it work | |
| version | No | pull, follow: a published version; default the latest | |
| deadline | No | propose: with wait: when to stop waiting (ISO); defaults to the link's expiry | |
| used_for | No | report: what you used it for, in a sentence | |
| from_folder | No | propose: a folder path or node id: every text document in it, by path (a skill when it holds SKILL.md). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| continuation | No | propose: with wait: a note to your future self for when it resolves | |
| from_document | No | propose: a document path or node id. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| from_knowledge | No | propose: a knowledge item id | |
| idempotency_key | No | Any 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| link | No | |
| wait | No | |
| added | No | |
| mount | No | |
| tally | No | |
| action | Yes | the action that answered |
| pulled | No | |
| report | No | |
| package | No | |
| reports | No | |
| comments | No | |
| packages | No | |
| proposal | No | |
| withdrawn | No |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=true and readOnlyHint=false, so the safety profile is covered; the description goes further by explaining that comments/ratings/reports are PUBLIC, that nothing publishes on its own (propose only returns an approval link, with wait registering a wait for the decision), what gets taken down by withdraw_report, and how follow pins versus tracks versions. It never spells out what a destructive action removes beyond the report case, so it stops short of a 5.
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?
Almost all content is substantive, but it is delivered as one dense paragraph of em-dash-clause prose that is hard to scan for a given action. Overall scope is front-loaded, yet the nine actions are not broken out into a scannable structure despite a 23-parameter schema.
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 23-parameter, nine-action multiplexed tool with an output schema present, the description covers the approval workflow, visibility rules, defaults for follow/into, and the idempotency-key behavior well, so an agent can call it without reading the schema top to bottom. It omits explicit failure/refusal modes for most actions and leaves pinning/version semantics partly to the schema.
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 description coverage is 100%, so the baseline is 3, but the description adds non-obvious semantics the schema does not: the per-action argument groupings, 'follow: latest keeps it updated with each approved version until edited', and the naming outcome that a folder package lands as scope/slug while a document lands as scope/slug.md. It still largely restates the enum of actions rather than adding new argument meaning, so it is not a 5.
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?
The description names the two resources precisely (the public registry of proposed packages and public context files from GitHub) and enumerates the nine verbs it supports, so an agent knows exactly what surface this tool covers rather than guessing from the vague title 'Act on public content'. It differentiates from siblings only implicitly, by scoping everything to public/registry content versus the org-internal tools like doc_create and knowledge_write.
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?
Each action line implies its own trigger (pull/add to copy a package, propose to ask for publication, report to record whether a public file worked, withdraw_report to remove one). It also states a real precondition: comments, ratings and reports are refused from a session that has read this organization's documents. What's missing is any explicit statement of when to prefer a sibling tool (e.g. knowledge_write) over propose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearchARead-onlyIdempotentInspect
Search what you can read, and get back hits you can cite: each has a citation (location@commit, and #span for a block), its freshness (when committed; for a mirror, when it last synced and who connected it) and a trust signal (verified_truth, stated_truth, mirror or text) with the truths about it. A document hit also carries matched: why it matched, strongest first (titles, labels, text, meaning). score names no strategy, so matched is the only field that says which of them found the hit. PUBLIC GITHUB, a separate corpus: scope "public" searches agent instruction files (skills, CLAUDE.md, AGENTS.md, cursor rules, copilot instructions, llms.txt) written by strangers, not your organization. They come back only in public, never in hits: 5 by default (limit up to 20), each a pointer with its licence, capabilities (what it would have an agent do), stars, whether its publisher is known, when its repository's agent context changed, a commit-pinned citation, a link for a person, a sourceLink to GitHub (readable whatever the licence) and an agentlefs://public/ URI. The citation and sourceLink are portable references; the uri pins no commit. No field proves one file changed. licensed_only keeps the files whose text may be served. With within owner/repo/path (or the URI) it opens one file in file: its text if licensed, otherwise a description and the link; a long file comes in parts of up to 50,000 bytes (max_bytes for smaller ones), the next by offset; the file's own text is everything above the last ──── end of … line, less its last two line breaks, and an entry before it says it is public. A public query needs two characters or more. Your own folder named public is scope /public. how: auto (default) runs every strategy and merges them; meaning ranks by what a passage is about; text matches the words in a body; titles finds a document by name (file name, title or frontmatter aliases, typo-tolerant, and the excerpt says which name matched). Documents come best first, and a document hit's score is the quantity they were ordered by, comparable only within one answer; a hit's line, when set, is the line its excerpt is from. Narrow it with scope (a location), within (one document: returns its matching spans), thread (a message id: searches that thread), or source (one connected source, by id or a location in it). follow (1-3) adds the links around each hit. Nothing you cannot read is returned or counted. Hits are documents, their spans, messages, and published knowledge (lessons, dead ends, workflows, skills): a knowledge hit cites knowledge:@v, is dated by its last change, and its trust is validated_knowledge, unvalidated_knowledge or refuted_knowledge. Knowledge matches the query as one phrase, so a key term finds a lesson where a whole question may not; drafts are never returned. skills names the skills (.claude/skills or .agents/skills) and memory names the CLAUDE.md and AGENTS.md files that apply at scope and at the hits' folders, ones you can read only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| how | No | ||
| limit | No | how many hits (at most 20 with scope "public") | |
| query | No | what you want to know (not needed to open a public file with scope "public" and within) | |
| scope | No | "public" searches the public corpus; a folder path (e.g. "specs", or "/public" for your own folder named public) limits the search to it (a document is refused: search one document with within); omit for everything you can read | |
| follow | No | ||
| offset | No | scope "public" with within only: where in the file to start, in bytes as read action=document takes it (a part gives nextOffset) | |
| source | No | a sync source id, or a location inside the mirror | |
| thread | No | a message id in the thread | |
| within | No | a document path or node id; with scope "public", one public file as owner/repo/path, its agentlefs://public/ URI, a hit's citation or its GitHub link at a commit (either also says whether the repository has moved on since), or its link (not one from another console served under a path prefix). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. | |
| max_bytes | No | scope "public" with within only: the largest part to return, in bytes (default and ceiling 50,000); a part never splits a character, so one smaller than the character at offset holds that character | |
| licensed_only | No | scope "public" only: just the files whose licence lets their text be served (default false: every match, unlicensed ones described with a link) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| file | No | |
| hits | Yes | |
| mode | Yes | |
| query | Yes | |
| memory | No | the memory files (CLAUDE.md, AGENTS.md) of scope and of the hits' folders and above, only ones you can read |
| public | No | |
| skills | No | the skills that apply at scope and at the folders of the hits (a .claude/skills/<name>/SKILL.md or .agents/skills/<name>/SKILL.md there or above), only ones you can read |
| degraded | Yes | |
| truncated | Yes | |
| licensedOnly | No | |
| spansPending | No |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real behavioral context on top: drafts are never returned, nothing unreadable is returned or counted, the public corpus is a separate limited set (5 by default, 20 max), and file reads are chunked at 50,000 bytes with offset paging. The content is valuable, though the dense run-on phrasing makes it harder to absorb than it should be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single enormous paragraph of chained clauses with no headings or paragraph breaks, mixing return-field semantics, public-corpus rules, and file-paging mechanics. Much of it restates what the output schema and parameter descriptions already carry, and the front-loaded summary is quickly buried.
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 an 11-parameter, zero-required tool with an output schema and a dual public/private corpus, the description covers the tricky cases an agent would otherwise get wrong (public needs 2+ characters, licensed_only filters servable text, knowledge hits are phrase-matched, your own folder named public is scope /public). Return-value explanation is partly redundant given the output schema, but nothing critical 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 82%, so the baseline is 3, and the description genuinely adds meaning beyond it: it explains what each `how` strategy matches on, the semantics of `matched` versus `score`, how `within` accepts a citation, URI, GitHub link, or console link, and that `offset`/`max_bytes` are byte-based and only apply to public single-file reads.
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?
The opening clause states a clear verb and resource ('Search what you can read, and get back hits you can cite') and the description goes on to enumerate what a hit contains, so an agent knows this is a corpus search returning citable results. It never names or contrasts with siblings like browse or read, however, and the sprawling middle makes the core purpose hard to extract on a first read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives substantial conditional guidance on how to narrow a query (scope, within, thread, source, follow) and what each `how` strategy does, which implies when to reach for each option. But it never states when to use search versus read/browse, even though `within` on a public file returns a single file's text – exactly the overlap a routing statement should resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sources_writeConnect sourcesAInspect
Connect GitHub or Google Drive and sync from it. Sync is one-way, into agentleFS, and repeats; a connector-owned path refuses direct edits. Actions — connect: start connecting an EXTERNAL account (provider), not a folder already in agentleFS (browse action=documents lists those); returns a link for the person to authorise in their browser. sync: point one repository (repo_owner, repo_name, branch) or Drive folder (folder_id) of a connected account at a folder here (location). vote: vote for a connector that does not exist yet (connector, why); one vote per person, shared with their agents.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| why | No | vote: what you would do with it, in one line (at most 200 characters); recorded with the vote | |
| action | Yes | what to do; each action takes the arguments its line names | |
| branch | No | sync: GitHub only: the branch to follow (default: the repo default) | |
| account | No | sync: the connected account, exactly as browse action=sources prints it (the installation or account ref) | |
| location | No | sync: the FOLDER this source writes into, whole path from the workspace root, e.g. "handbook" or "handbook/vendor" | |
| provider | No | connect: which source to connect: github, or gdrive for Google Drive · sync: which connected account this source uses | |
| connector | No | vote: the product to connect, e.g. Notion | |
| folder_id | No | sync: Google Drive only: the Drive folder id to pull | |
| repo_name | No | sync: GitHub only: the repository name | |
| repo_owner | No | sync: GitHub only: the repository owner | |
| idempotency_key | No | Any 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| text | No | the answer as prose, for an action that answers in prose |
| vote | No | |
| action | Yes | the action that answered |
| wanted | No | |
| available | No |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare write/openWorld/non-idempotent/non-destructive; the description adds real behavioral context beyond them: sync is one-way into agentleFS and repeats, connector-owned paths refuse direct edits, connect returns a browser authorisation link, and vote is one-per-person shared with agents. These are non-obvious traits an agent cannot infer from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then action-labelled clauses ('connect:', 'sync:', 'vote:') that keep a dense 11-param tool readable. Every sentence carries information, though the run-on action block is heavy and could be trimmed slightly.
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?
Given three actions, 11 parameters, an output schema, and full annotation coverage, the description supplies the action dispatch semantics, side-effect behavior, and auth flow needed to call it correctly. Nothing essential 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 100%, so the baseline is 3, but the description goes further by mapping parameters to actions (repo_owner/repo_name/branch for GitHub, folder_id for Drive, location as the destination folder, account as the connected account ref). It adds action-scoping that helps disambiguate the many optional params.
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 ('Connect GitHub or Google Drive and sync from it') and enumerates the three actions (connect, sync, vote) with their distinct objects. It explicitly distinguishes itself from the sibling 'browse' (action=documents lists folders already in agentleFS), so an agent can tell it apart without opening other schemas.
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?
Each action line gives clear when-to-use context: connect is for an EXTERNAL account, not a folder already in agentleFS, and it redirects to browse for the latter; sync points a repo/folder at a location here; vote is for a connector that does not exist yet. No explicit exclusions for sync/vote beyond their definitions, so slightly short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
- Changed
access_grant1 field changed- changed
Input schema / properties / location / descriptionPrevious 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)"
- Changed
access_read1 field changed- changed
Input schema / properties / location / descriptionPrevious value: -"who_can_read: full path from the workspace root, e.g. \"handbook/vendor/acme.md\" (as printed by browse action=documents or search). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · can_see, labels, settings: the document or folder, by path"New value: +"who_can_read: full path from the workspace root, e.g. \"handbook/vendor/acme.md\" (as printed by browse action=documents or search). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · can_see, labels, settings: the document or folder, by path; accept_share: the folder to put it in, only you can see (default the top level)"
- Changed
browse5 fields changed- added
Output schema / properties / addedAdded value: +{ + "additionalProperties": false, + "properties": { + "created": { + "type": "boolean" + }, + "diverged": { + "type": "boolean" + }, + "follow": { + "enum": [ + "latest", + "pinned" + ], + "type": "string" + }, + "location": { + "type": "string" + }, + "version": { + "type": "number" + } + }, + "required": [ + "location", + "version", + "follow", + "diverged", + "created" + ], + "type": "object" +} - added
Output schema / properties / package / properties / filesAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "content": { + "type": "string" + }, + "path": { + "type": "string" + } + }, + "required": [ + "path", + "content" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "a folder package's documents by path; null for one document or knowledge item" +} - changed
Output schema / properties / package / requiredPrevious value: -[ - "slug", - "kind", - "title", - "summary", - "publisher", - "version", - "body", - "fields", - "approvedBy", - "publishedAt", - "standing" -]New value: +[ + "slug", + "kind", + "title", + "summary", + "publisher", + "version", + "body", + "fields", + "approvedBy", + "publishedAt", + "standing", + "files" +] - added
Output schema / properties / packages / items / properties / filesAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "content": { + "type": "string" + }, + "path": { + "type": "string" + } + }, + "required": [ + "path", + "content" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "a folder package's documents by path; null for one document or knowledge item" +} - changed
Output schema / properties / packages / items / requiredPrevious value: -[ - "slug", - "kind", - "title", - "summary", - "publisher", - "version", - "body", - "fields", - "approvedBy", - "publishedAt", - "standing" -]New value: +[ + "slug", + "kind", + "title", + "summary", + "publisher", + "version", + "body", + "fields", + "approvedBy", + "publishedAt", + "standing", + "files" +]
- Changed
read5 fields changed- added
Output schema / properties / addedAdded value: +{ + "additionalProperties": false, + "properties": { + "created": { + "type": "boolean" + }, + "diverged": { + "type": "boolean" + }, + "follow": { + "enum": [ + "latest", + "pinned" + ], + "type": "string" + }, + "location": { + "type": "string" + }, + "version": { + "type": "number" + } + }, + "required": [ + "location", + "version", + "follow", + "diverged", + "created" + ], + "type": "object" +} - added
Output schema / properties / package / properties / filesAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "content": { + "type": "string" + }, + "path": { + "type": "string" + } + }, + "required": [ + "path", + "content" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "a folder package's documents by path; null for one document or knowledge item" +} - changed
Output schema / properties / package / requiredPrevious value: -[ - "slug", - "kind", - "title", - "summary", - "publisher", - "version", - "body", - "fields", - "approvedBy", - "publishedAt", - "standing" -]New value: +[ + "slug", + "kind", + "title", + "summary", + "publisher", + "version", + "body", + "fields", + "approvedBy", + "publishedAt", + "standing", + "files" +] - added
Output schema / properties / packages / items / properties / filesAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "content": { + "type": "string" + }, + "path": { + "type": "string" + } + }, + "required": [ + "path", + "content" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "a folder package's documents by path; null for one document or knowledge item" +} - changed
Output schema / properties / packages / items / requiredPrevious value: -[ - "slug", - "kind", - "title", - "summary", - "publisher", - "version", - "body", - "fields", - "approvedBy", - "publishedAt", - "standing" -]New value: +[ + "slug", + "kind", + "title", + "summary", + "publisher", + "version", + "body", + "fields", + "approvedBy", + "publishedAt", + "standing", + "files" +]
- Changed
registry_write12 fields changed- changed
Input schema / properties / action / enumPrevious value: -[ - "pull", - "comment", - "rate", - "propose", - "report", - "withdraw_report", - "mount" -]New value: +[ + "pull", + "add", + "follow", + "comment", + "rate", + "propose", + "report", + "withdraw_report", + "mount" +] - changed
Input schema / properties / follow / descriptionPrevious value: -"mount: latest keeps it up to date with its source (the default for a new mount); pinned keeps the version it holds"New value: +"add, follow: with add or follow: latest follows each approved version until the copy is edited (the default); pinned keeps the version it holds, or with follow the version you name · mount: latest keeps it up to date with its source (the default for a new mount); pinned keeps the version it holds" - added
Input schema / properties / from_folderAdded value: +{ + "description": "propose: a folder path or node id: every text document in it, by path (a skill when it holds SKILL.md). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.", + "type": "string" +} - added
Input schema / properties / intoAdded value: +{ + "description": "mount: the folder to put it in; default public-context/<owner>/<repo>/", + "type": "string" +} - changed
Input schema / properties / scope / descriptionPrevious value: -"pull: the folder to copy it into"New value: +"pull, add: the folder to copy it into" - changed
Input schema / properties / slug / descriptionPrevious value: -"pull, comment, rate, propose: the package's name in the registry"New value: +"pull, add, follow, comment, rate, propose: the package's name in the registry" - changed
Input schema / properties / version / descriptionPrevious value: -"pull: a published version; default the latest"New value: +"pull, follow: a published version; default the latest" - added
Output schema / properties / addedAdded value: +{ + "additionalProperties": false, + "properties": { + "created": { + "type": "boolean" + }, + "diverged": { + "type": "boolean" + }, + "follow": { + "enum": [ + "latest", + "pinned" + ], + "type": "string" + }, + "location": { + "type": "string" + }, + "version": { + "type": "number" + } + }, + "required": [ + "location", + "version", + "follow", + "diverged", + "created" + ], + "type": "object" +} - added
Output schema / properties / package / properties / filesAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "content": { + "type": "string" + }, + "path": { + "type": "string" + } + }, + "required": [ + "path", + "content" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "a folder package's documents by path; null for one document or knowledge item" +} - changed
Output schema / properties / package / requiredPrevious value: -[ - "slug", - "kind", - "title", - "summary", - "publisher", - "version", - "body", - "fields", - "approvedBy", - "publishedAt", - "standing" -]New value: +[ + "slug", + "kind", + "title", + "summary", + "publisher", + "version", + "body", + "fields", + "approvedBy", + "publishedAt", + "standing", + "files" +] - added
Output schema / properties / packages / items / properties / filesAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "content": { + "type": "string" + }, + "path": { + "type": "string" + } + }, + "required": [ + "path", + "content" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "a folder package's documents by path; null for one document or knowledge item" +} - changed
Output schema / properties / packages / items / requiredPrevious value: -[ - "slug", - "kind", - "title", - "summary", - "publisher", - "version", - "body", - "fields", - "approvedBy", - "publishedAt", - "standing" -]New value: +[ + "slug", + "kind", + "title", + "summary", + "publisher", + "version", + "body", + "fields", + "approvedBy", + "publishedAt", + "standing", + "files" +]
46 tool updates
- Added
access_grant - Added
access_read - Added
access_revoke - Removed
add_org_source - Removed
await - Changed
brief_me7 fields changed- removed
Input schema / properties / ack_throughRemoved value: -{ - "description": "advance your cursor to this log position first (cursor.head from a previous brief)", - "maximum": 9007199254740991, - "minimum": 0, - "type": "integer" -} - removed
Input schema / properties / idempotency_keyRemoved value: -{ - "description": "Any 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.", - "maxLength": 200, - "minLength": 1, - "type": "string" -} - added
Output schema / properties / loadedAdded value: +{ + "description": "the folders your person set you to load at connect that you can still read: their memory whole and their skills by name", + "items": { + "additionalProperties": false, + "properties": { + "location": { + "type": "string" + }, + "memory": { + "items": { + "additionalProperties": false, + "properties": { + "location": { + "type": "string" + }, + "text": { + "type": "string" + }, + "truncated": { + "type": "boolean" + } + }, + "required": [ + "location", + "text", + "truncated" + ], + "type": "object" + }, + "type": "array" + }, + "moreSkills": { + "type": "number" + }, + "skills": { + "items": { + "additionalProperties": false, + "properties": { + "description": { + "type": "string" + }, + "location": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "name", + "description", + "location" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "location", + "memory", + "skills", + "moreSkills" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / membershipsAdded value: +{ + "description": "organizations that invited your human to join; only they accept or decline, in the console at decideAt", + "items": { + "additionalProperties": false, + "properties": { + "at": { + "type": "string" + }, + "decideAt": { + "type": "string" + }, + "from": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "grants": { + "type": "number" + }, + "id": { + "type": "string" + }, + "organization": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "role": { + "type": "string" + } + }, + "required": [ + "id", + "organization", + "from", + "role", + "grants", + "at", + "decideAt" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / memoryAdded value: +{ + "description": "the memory files (CLAUDE.md, AGENTS.md) that apply in the folders near your work, only ones you can read, at most ten", + "items": { + "additionalProperties": false, + "properties": { + "changed": { + "type": "boolean" + }, + "folder": { + "type": "string" + }, + "location": { + "type": "string" + } + }, + "required": [ + "location", + "folder", + "changed" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / skillsAdded value: +{ + "description": "the skills (.claude/skills or .agents/skills) that apply in the folders near your work, only ones you can read, at most ten", + "items": { + "additionalProperties": false, + "properties": { + "changed": { + "description": "committed since this session last read it", + "type": "boolean" + }, + "description": { + "type": "string" + }, + "folder": { + "description": "the folder it applies in and below; empty for the whole organization", + "type": "string" + }, + "location": { + "description": "the SKILL.md to read", + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "name", + "description", + "location", + "folder", + "changed" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / requiredPrevious value: -[ - "cursor", - "me", - "claims", - "commitments", - "waiting", - "asked", - "answered", - "resolvedWaits", - "pendingWaits", - "approvals", - "invitations", - "offers", - "session", - "usage", - "loops", - "changed", - "contested" -]New value: +[ + "cursor", + "me", + "claims", + "commitments", + "waiting", + "asked", + "answered", + "resolvedWaits", + "pendingWaits", + "approvals", + "invitations", + "offers", + "memberships", + "session", + "usage", + "loops", + "changed", + "contested", + "skills", + "memory", + "loaded" +]
- Added
browse - Removed
claim - Removed
comment - Removed
connect_org_source - Removed
connectors - Added
coordination_write - Removed
create_org_folder - Removed
delete_org_doc - Added
doc_create - Added
doc_delete - Added
doc_update - Removed
edit_org_doc - Removed
erase_org_doc - Removed
identity - Added
identity_write - Removed
knowledge - Added
knowledge_write - Removed
list_org_docs - Removed
list_org_folders - Removed
list_org_people - Removed
list_org_sources - Removed
message - Added
message_write - Removed
move - Removed
public_context_discussion - Added
read - Removed
read_org_doc - Removed
registry - Added
registry_write - Removed
room - Changed
search5 fields changed- changed
Input schema / properties / offset / descriptionPrevious value: -"scope \"public\" with within only: where in the file to start, in bytes as read_org_doc takes it (a part gives nextOffset)"New value: +"scope \"public\" with within only: where in the file to start, in bytes as read action=document takes it (a part gives nextOffset)" - changed
Output schema / properties / hits / items / properties / matched / descriptionPrevious value: -"Why this hit matched, strongest evidence first: its file name, title or an alias (titles), a label on it (labels), a literal phrase in its body (text), or a semantically near chunk (meaning). `labels` is evidence you can read but not yet ask for: `how` takes the other three. Document hits carry it; hits from within one document, one thread, or knowledge do not, because there the single strategy is already named in `mode` and `score` is the rank key."New value: +"Why this hit matched, names before body evidence: its file name, title or an alias (titles), a label on it (labels), its words in a chunk by full-text search (keyword), a literal phrase in its body (text), or a semantically near chunk (meaning). `labels` and `keyword` are evidence you can read but not ask for: `how` takes titles, text and meaning. Document hits carry it; hits from within one document, one thread, or knowledge do not, because there the single strategy is already named in `mode` and `score` is the rank key." - changed
Output schema / properties / hits / items / properties / matched / items / enumPrevious value: -[ - "titles", - "labels", - "text", - "meaning" -]New value: +[ + "titles", + "labels", + "keyword", + "text", + "meaning" +] - added
Output schema / properties / memoryAdded value: +{ + "description": "the memory files (CLAUDE.md, AGENTS.md) of scope and of the hits' folders and above, only ones you can read", + "items": { + "additionalProperties": false, + "properties": { + "changed": { + "type": "boolean" + }, + "folder": { + "type": "string" + }, + "location": { + "type": "string" + } + }, + "required": [ + "location", + "folder", + "changed" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / skillsAdded value: +{ + "description": "the skills that apply at scope and at the folders of the hits (a .claude/skills/<name>/SKILL.md or .agents/skills/<name>/SKILL.md there or above), only ones you can read", + "items": { + "additionalProperties": false, + "properties": { + "changed": { + "description": "committed since this session last read it", + "type": "boolean" + }, + "description": { + "type": "string" + }, + "folder": { + "description": "the folder it applies in and below; empty for the whole organization", + "type": "string" + }, + "location": { + "description": "the SKILL.md to read", + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "name", + "description", + "location", + "folder", + "changed" + ], + "type": "object" + }, + "type": "array" +}
- Removed
search_org_knowledge - Removed
share - Removed
share_org_folder - Added
sources_write - Removed
subscribe - Removed
truth - Removed
undo_delete - Removed
who_can_read - Removed
write_org_doc
5 tool updates
- Changed
identity1 field changed- changed
Input schema / properties / scope / descriptionPrevious value: -"spawn: role@location, repeatable, e.g. writer@specs/api.md or reader@*"New value: +"spawn: role@location, repeatable; role is viewer, editor or manager (reader, writer and approver are deprecated aliases), e.g. editor@specs/api.md or viewer@*"
- Changed
public_context_discussion6 fields changed- added
Input schema / properties / followAdded value: +{ + "description": "mount: latest keeps it up to date with its source (the default for a new mount); pinned keeps the version it holds", + "enum": [ + "latest", + "pinned" + ], + "type": "string" +} - added
Output schema / properties / mount / properties / changedAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / mount / properties / commitShaAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / mount / properties / followAdded value: +{ + "enum": [ + "latest", + "pinned" + ], + "type": "string" +} - added
Output schema / properties / mount / properties / organizationAdded value: +{ + "description": "the organization the file was mounted in, by name", + "type": "string" +} - changed
Output schema / properties / mount / requiredPrevious value: -[ - "location", - "created", - "diverged" -]New value: +[ + "location", + "created", + "diverged", + "organization", + "follow", + "commitSha", + "changed" +]
- Changed
search2 fields changed- added
Output schema / properties / hits / items / properties / freshness / properties / spansPendingAdded value: +{ + "description": "true when this document's span map is still being built: staleSpans is 0 because nothing is recorded yet, not because nothing is stale", + "type": "boolean" +} - added
Output schema / properties / spansPendingAdded value: +{ + "type": "boolean" +}
- Changed
share16 fields changed- changed
Input schema / properties / action / enumPrevious value: -[ - "request", - "approve", - "decline", - "withdraw", - "inbox", - "list", - "can_see", - "declassify", - "labels", - "hold", - "release_hold", - "share_out", - "offers", - "accept_share", - "decline_share", - "withdraw_share", - "proposals", - "decide_share", - "shared" -]New value: +[ + "request", + "approve", + "decline", + "withdraw", + "inbox", + "list", + "can_see", + "declassify", + "labels", + "hold", + "release_hold", + "share_out", + "offers", + "accept_share", + "decline_share", + "withdraw_share", + "proposals", + "decide_share", + "shared", + "settings" +] - added
Input schema / properties / editors_can_shareAdded value: +{ + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "settings: true lets editors share here, false stops them, null clears this node's own setting so it inherits; omit to read" +} - changed
Input schema / properties / role / descriptionPrevious value: -"request: default reader. approver can also share it, grant within it and decide requests for it. Approval gives the role to everyone you work under who lacks it, too. Asking for a role you already hold, or one below it (approver implies writer, writer implies reader), is refused"New value: +"request: default viewer. editor can also edit; manager can also share it, grant within it and decide requests for it. Approval 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. share_out: viewer or editor. reader, writer and approver are deprecated aliases for viewer, editor and manager" - changed
Input schema / properties / role / enumPrevious value: -[ - "reader", - "writer", - "approver" -]New value: +[ + "viewer", + "editor", + "manager", + "reader", + "writer", + "approver" +] - added
Output schema / properties / across / items / properties / role / enumAdded value: +[ + "viewer", + "editor", + "manager" +] - added
Output schema / properties / emailedAdded value: +{ + "description": "share_out when offered or invited: whether the recipient is emailed; when false, send them recipient_link", + "type": "boolean" +} - added
Output schema / properties / invitationAdded value: +{ + "additionalProperties": false, + "properties": { + "email": { + "type": "string" + }, + "id": { + "type": "string" + }, + "role": { + "enum": [ + "viewer", + "editor", + "manager" + ], + "type": "string" + } + }, + "required": [ + "id", + "email", + "role" + ], + "type": "object" +} - added
Output schema / properties / not_emailed_reasonAdded value: +{ + "description": "share_out when invited: why the recipient is not emailed, when emailed is false", + "type": "string" +} - added
Output schema / properties / recipient_linkAdded value: +{ + "description": "share_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", + "type": "string" +} - changed
Output schema / properties / request / properties / alsoGains / descriptionPrevious value: -"an approver's view only (inbox, brief_me, list with request_id): who else approving gives the role to, the identities the requester works under that lack it. Absent means this view does not compute it, not that nobody gains"New value: +"the decider's view only (inbox, brief_me, list with request_id): who else approving gives the role to, the identities the requester works under that lack it. Absent means this view does not compute it, not that nobody gains" - added
Output schema / properties / request / properties / role / descriptionAdded value: +"the role asked for: viewer, editor or manager" - added
Output schema / properties / request / properties / role / enumAdded value: +[ + "viewer", + "editor", + "manager" +] - changed
Output schema / properties / requests / items / properties / alsoGains / descriptionPrevious value: -"an approver's view only (inbox, brief_me, list with request_id): who else approving gives the role to, the identities the requester works under that lack it. Absent means this view does not compute it, not that nobody gains"New value: +"the decider's view only (inbox, brief_me, list with request_id): who else approving gives the role to, the identities the requester works under that lack it. Absent means this view does not compute it, not that nobody gains" - added
Output schema / properties / requests / items / properties / role / descriptionAdded value: +"the role asked for: viewer, editor or manager" - added
Output schema / properties / requests / items / properties / role / enumAdded value: +[ + "viewer", + "editor", + "manager" +] - added
Output schema / properties / settingsAdded value: +{ + "additionalProperties": false, + "properties": { + "editorsCanShare": { + "description": "whether an editor may share this as viewer or editor", + "type": "boolean" + }, + "explicit": { + "description": "true when set on this node itself, false when inherited or the default", + "type": "boolean" + }, + "inheritedFrom": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "the folder it is inherited from, when you can read it; null for this node's own setting or the default" + } + }, + "required": [ + "editorsCanShare", + "explicit", + "inheritedFrom" + ], + "type": "object" +}
- Changed
share_org_folder2 fields changed- changed
Input schema / properties / role / descriptionPrevious value: -"reader opens it; writer also edits; approver can also approve access requests for it, share it and grant within it. Sharing needs approver on this folder or one above it"New value: +"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 (share action=settings). reader, writer and approver are deprecated aliases for viewer, editor and manager" - changed
Input schema / properties / role / enumPrevious value: -[ - "reader", - "writer", - "approver" -]New value: +[ + "viewer", + "editor", + "manager", + "reader", + "writer", + "approver" +]
5 tool updates
- Changed
brief_me2 fields changed- added
Output schema / properties / offersAdded value: +{ + "items": { + "additionalProperties": false, + "properties": { + "at": { + "type": "string" + }, + "from": { + "type": "string" + }, + "id": { + "type": "string" + }, + "kind": { + "type": "string" + }, + "name": { + "type": "string" + }, + "role": { + "type": "string" + } + }, + "required": [ + "id", + "from", + "kind", + "name", + "role", + "at" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / requiredPrevious value: -[ - "cursor", - "me", - "claims", - "commitments", - "waiting", - "asked", - "answered", - "resolvedWaits", - "pendingWaits", - "approvals", - "invitations", - "session", - "usage", - "loops", - "changed", - "contested" -]New value: +[ + "cursor", + "me", + "claims", + "commitments", + "waiting", + "asked", + "answered", + "resolvedWaits", + "pendingWaits", + "approvals", + "invitations", + "offers", + "session", + "usage", + "loops", + "changed", + "contested" +]
- Changed
edit_org_doc5 fields changed- added
Input schema / properties / appendAdded value: +{ + "description": "text to add at the end of the document, or of `section`, instead of replacing anything", + "minLength": 1, + "type": "string" +} - changed
Input schema / properties / old_string / descriptionPrevious value: -"exact text to replace — must appear in the current body"New value: +"exact text to replace — must appear in the current body (with new_string; not with append)" - added
Input schema / properties / sectionAdded value: +{ + "description": "with append: the heading text of the section to add to the end of, exactly as written after the #s (\"Log\" for \"## Log\"), the same as claim's span; refused if no heading or several have that text. Omit for the end of the document", + "type": "string" +} - removed
Input schema / requiredRemoved value: -[ - "old_string", - "new_string" -] - added
Output schema / properties / appendedAdded value: +{ + "additionalProperties": false, + "description": "append only: what this call added", + "properties": { + "commit": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "the commit the append made; null when the stored body came out unchanged" + }, + "end": { + "description": "the byte after the last one it added: read_org_doc offset=start maxBytes=end-start returns exactly them", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "revision": { + "description": "live when it was appended to an unsaved editing session's text, which the commit now carries", + "enum": [ + "live", + "committed" + ], + "type": "string" + }, + "section": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "the section it went to the end of; null for the end of the document" + }, + "spans": { + "description": "the span ids of the blocks it added; empty when it continued the block above rather than adding one", + "items": { + "type": "string" + }, + "type": "array" + }, + "start": { + "description": "first byte it added, in the document as read_org_doc serves it", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "commit", + "section", + "start", + "end", + "spans", + "revision" + ], + "type": "object" +}
- Changed
message6 fields changed- added
Input schema / properties / answer / descriptionAdded value: +"answer: the answer itself, first. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence" - added
Input schema / properties / finding / descriptionAdded value: +"finding: what you found. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence" - added
Input schema / properties / question / descriptionAdded value: +"question: what you are asking. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence" - added
Input schema / properties / request / descriptionAdded value: +"request: what you need, from whom. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence" - changed
Input schema / properties / summary / descriptionPrevious value: -"handoff: what is being handed over"New value: +"handoff: what is being handed over. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence" - changed
Input schema / properties / what / descriptionPrevious value: -"commitment: what you commit to"New value: +"commitment: what you commit to. A person reads this field on its own in the console, without the thread: it is clearest as a sentence or two that stands alone, with longer detail in a document named in evidence"
- Added
public_context_discussion - Changed
search1 field changed- changed
Input schema / properties / scope / descriptionPrevious value: -"\"public\" searches the public corpus; a folder path (e.g. \"specs\", or \"/public\" for your own folder named public) limits the search to it; omit for everything you can read"New value: +"\"public\" searches the public corpus; a folder path (e.g. \"specs\", or \"/public\" for your own folder named public) limits the search to it (a document is refused: search one document with within); omit for everything you can read"
1 tool update
- Changed
write_org_doc2 fields changed- changed
Input schema / properties / folder_path / descriptionPrevious value: -"folder names, outermost first, e.g. [\"handbook\",\"policies\"]"New value: +"folder names, outermost first, e.g. [\"handbook\",\"policies\"]; at least one, since documents go in a folder" - removed
Input schema / properties / folder_path / minItemsRemoved value: -1
31 tool updates
- Changed
add_org_source1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
await1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
brief_me1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
claim1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
comment1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
connect_org_source1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
connectors1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
create_org_folder1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
delete_org_doc1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
edit_org_doc1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
erase_org_doc1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
identity1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
knowledge2 fields changed- changed
Input schema / properties / body / descriptionPrevious value: -"send long text with - for stdin"New value: +"the item's text" - removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
list_org_docs1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
list_org_folders1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
list_org_people1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
list_org_sources1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
message2 fields changed- changed
Input schema / properties / packet / descriptionPrevious value: -"handoff: the packet itself (send with --input -)"New value: +"handoff: the packet itself" - removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
move1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
read_org_doc1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
registry1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
room2 fields changed- changed
Input schema / properties / content / descriptionPrevious value: -"move_in: what goes in (send long text with - for stdin)"New value: +"move_in: what goes in" - removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
search2 fields changed- added
Input schema / properties / scope / descriptionAdded value: +"\"public\" searches the public corpus; a folder path (e.g. \"specs\", or \"/public\" for your own folder named public) limits the search to it; omit for everything you can read" - removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
search_org_knowledge2 fields changed- changed
Input schema / properties / query / descriptionPrevious value: -"what you want to know, in the user's own words"New value: +"what to look for, as plain text" - removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
share1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
share_org_folder1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
subscribe1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
truth1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
undo_delete1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
who_can_read1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
- Changed
write_org_doc1 field changed- removed
Input schema / properties / tokenRemoved value: -{ - "description": "Bearer token identifying the principal. Usually omitted — supplied by the transport. Over stdio it selects the principal (else the server's AGENTLEFS_TOKEN env). Over HTTP the Authorization header decides and passing this argument is REFUSED, not ignored: it cannot override who you are acting as.", - "type": "string" -}
1 tool update
- Changed
search11 fields changed- added
Input schema / properties / licensed_onlyAdded value: +{ + "description": "scope \"public\" only: just the files whose licence lets their text be served (default false: every match, unlicensed ones described with a link)", + "type": "boolean" +} - added
Input schema / properties / limit / descriptionAdded value: +"how many hits (at most 20 with scope \"public\")" - added
Input schema / properties / max_bytesAdded value: +{ + "description": "scope \"public\" with within only: the largest part to return, in bytes (default and ceiling 50,000); a part never splits a character, so one smaller than the character at offset holds that character", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / offsetAdded value: +{ + "description": "scope \"public\" with within only: where in the file to start, in bytes as read_org_doc takes it (a part gives nextOffset)", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - changed
Input schema / properties / query / descriptionPrevious value: -"what you want to know"New value: +"what you want to know (not needed to open a public file with scope \"public\" and within)" - changed
Input schema / properties / within / descriptionPrevious value: -"a document path or node id. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too."New value: +"a document path or node id; with scope \"public\", one public file as owner/repo/path, its agentlefs://public/ URI, a hit's citation or its GitHub link at a commit (either also says whether the repository has moved on since), or its link (not one from another console served under a path prefix). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too." - removed
Input schema / requiredRemoved value: -[ - "query" -] - added
Output schema / properties / fileAdded value: +{ + "additionalProperties": false, + "properties": { + "body": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "bodyTruncated": { + "description": "the body is one part of the file, not all of it: offset and nextOffset say which", + "type": "boolean" + }, + "bytes": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "the size of the served text in bytes, which parts are counted in; for a withheld file, the size GitHub reported" + }, + "capabilities": { + "items": { + "type": "string" + }, + "type": "array" + }, + "changedAt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "when the repository's agent context last changed: one history lookup per repository (its skills folder, or its first file), so a sibling file moves it too. Freshness, not a per-file clock" + }, + "citation": { + "description": "github:owner/repo@<commit>:path, the form to write down: within reopens it and says whether the repository has moved on", + "type": "string" + }, + "citedCommit": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "the repository commit a citation, or a GitHub link at a commit, named, when the file was opened by one" + }, + "citedCommitCollected": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "whether that is the repository commit this copy was collected at; false means the repository has moved on since, not that this file did. No field here proves this one file changed: changedAt is per repository, and bytes counts GitHub's size on a search hit but the stored text's on an opened file, so the two do not compare" + }, + "citedLink": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "the file on GitHub at the cited commit, outside this server: the corpus holds one commit per file, so body is those bytes only when citedCommitCollected is true" + }, + "collectedAt": { + "type": "string" + }, + "commit": { + "type": "string" + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "kind": { + "enum": [ + "skill", + "agents_md", + "claude_md", + "cursor_rule", + "copilot_instructions", + "llms_txt" + ], + "type": "string" + }, + "knownPublisher": { + "description": "the publisher is an organization we recognise (model labs, agent and editor makers): provenance, not an endorsement", + "type": "boolean" + }, + "licence": { + "type": "string" + }, + "link": { + "description": "where a person reads it: this server's console catalog page, or GitHub when it has no console. within reopens this server's links; another console's may not", + "type": "string" + }, + "maxBytes": { + "description": "the part size this read asked for; pass it again with nextOffset to keep parts this size", + "type": "number" + }, + "name": { + "type": "string" + }, + "nextOffset": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "offset": { + "type": "number" + }, + "origin": { + "const": "public", + "type": "string" + }, + "path": { + "type": "string" + }, + "redistributable": { + "description": "whether the licence lets agentleFS serve the text: false means body is null, withheld says why, and sourceLink is where to read it", + "type": "boolean" + }, + "repo": { + "type": "string" + }, + "sourceLink": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "the file on GitHub at the commit collected, readable whatever its licence; null when no commit is known. within reopens it and says whether the repository has moved on" + }, + "stars": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "uri": { + "description": "agentlefs://public/… for an agent: read it as a resource, or pass it as within", + "type": "string" + }, + "withheld": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "origin", + "name", + "repo", + "path", + "kind", + "description", + "licence", + "redistributable", + "capabilities", + "stars", + "bytes", + "knownPublisher", + "changedAt", + "citation", + "link", + "sourceLink", + "uri", + "commit", + "collectedAt", + "body", + "offset", + "nextOffset", + "maxBytes", + "bodyTruncated", + "withheld", + "citedCommit", + "citedLink", + "citedCommitCollected" + ], + "type": "object" +} - added
Output schema / properties / hits / items / properties / matchedAdded value: +{ + "description": "Why this hit matched, strongest evidence first: its file name, title or an alias (titles), a label on it (labels), a literal phrase in its body (text), or a semantically near chunk (meaning). `labels` is evidence you can read but not yet ask for: `how` takes the other three. Document hits carry it; hits from within one document, one thread, or knowledge do not, because there the single strategy is already named in `mode` and `score` is the rank key.", + "items": { + "enum": [ + "titles", + "labels", + "text", + "meaning" + ], + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / licensedOnlyAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / publicAdded value: +{ + "items": { + "additionalProperties": false, + "properties": { + "bytes": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "the file's size in bytes as GitHub reported it, so a read can be budgeted before it is made" + }, + "capabilities": { + "items": { + "type": "string" + }, + "type": "array" + }, + "changedAt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "when the repository's agent context last changed: one history lookup per repository (its skills folder, or its first file), so a sibling file moves it too. Freshness, not a per-file clock" + }, + "citation": { + "description": "github:owner/repo@<commit>:path, the form to write down: within reopens it and says whether the repository has moved on", + "type": "string" + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "kind": { + "enum": [ + "skill", + "agents_md", + "claude_md", + "cursor_rule", + "copilot_instructions", + "llms_txt" + ], + "type": "string" + }, + "knownPublisher": { + "description": "the publisher is an organization we recognise (model labs, agent and editor makers): provenance, not an endorsement", + "type": "boolean" + }, + "licence": { + "type": "string" + }, + "link": { + "description": "where a person reads it: this server's console catalog page, or GitHub when it has no console. within reopens this server's links; another console's may not", + "type": "string" + }, + "name": { + "type": "string" + }, + "origin": { + "const": "public", + "type": "string" + }, + "path": { + "type": "string" + }, + "redistributable": { + "description": "whether the licence lets agentleFS serve the text: false means body is null, withheld says why, and sourceLink is where to read it", + "type": "boolean" + }, + "repo": { + "type": "string" + }, + "sourceLink": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "the file on GitHub at the commit collected, readable whatever its licence; null when no commit is known. within reopens it and says whether the repository has moved on" + }, + "stars": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "uri": { + "description": "agentlefs://public/… for an agent: read it as a resource, or pass it as within", + "type": "string" + } + }, + "required": [ + "origin", + "name", + "repo", + "path", + "kind", + "description", + "licence", + "redistributable", + "capabilities", + "stars", + "bytes", + "knownPublisher", + "changedAt", + "citation", + "link", + "sourceLink", + "uri" + ], + "type": "object" + }, + "type": "array" +}
1 tool update
- Changed
comment1 field changed- changed
Input schema / properties / location / descriptionPrevious value: -"the document's path"New value: +"the document or folder path"
31 tool updates
- Changed
add_org_source1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
await1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
brief_me1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
claim1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
comment1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
connect_org_source1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
connectors1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
create_org_folder1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
delete_org_doc1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
edit_org_doc3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / expected_commit / descriptionPrevious value: -"the document head you read at (read_org_doc prints it). Refuses if that document has moved since."New value: +"the document head you read at (read_org_doc prints it; any lowercase prefix of at least 7 hex characters). Refuses if that document has changed since." - added
Input schema / properties / expected_commit / patternAdded value: +"^[0-9a-f]{7,64}$"
- Changed
erase_org_doc1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
identity1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
knowledge1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
list_org_docs2 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / location / descriptionPrevious value: -"the folder to list, full path from the workspace root, e.g. \"handbook\" or \"handbook/vendor\""New value: +"the folder to list, full path from the workspace root, e.g. \"handbook\" or \"handbook/vendor\". A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too."
- Changed
list_org_folders3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / location / descriptionPrevious value: -"full path to scope to, e.g. \"handbook\" or \"handbook/vendor\". Omit to cover everything you can reach."New value: +"full path to scope to, e.g. \"handbook\" or \"handbook/vendor\". Omit to cover everything you can reach. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too." - changed
Input schema / properties / parent / descriptionPrevious value: -"list inside this folder, e.g. \"handbook\" or \"handbook/vendor\". Omit for the top level."New value: +"list inside this folder, e.g. \"handbook\" or \"handbook/vendor\". Omit for the top level. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too."
- Changed
list_org_people1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
list_org_sources1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
message1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
move3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / from / descriptionPrevious value: -"the document or directory's whole location, e.g. wiki/attention.md"New value: +"the document or directory's whole location, e.g. wiki/attention.md. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too." - changed
Input schema / properties / to / descriptionPrevious value: -"move: the whole new location including the name, e.g. wiki/archive/attention.md"New value: +"move: the whole new location including the name, e.g. wiki/archive/attention.md; a folder's link moves it into that folder. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too."
- Changed
read_org_doc1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
registry1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
room1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
search1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
search_org_knowledge1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
share1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
share_org_folder1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
subscribe1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
truth1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
undo_delete1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
who_can_read3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / location / descriptionPrevious value: -"full path from the workspace root, e.g. \"handbook/vendor/acme.md\" (as printed by list_org_docs or search)"New value: +"full path from the workspace root, e.g. \"handbook/vendor/acme.md\" (as printed by list_org_docs or search). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too." - changed
Input schema / properties / scope_type / descriptionPrevious value: -"whether location names a folder or one document; default folder"New value: +"whether location names a folder or one document; default folder, or the kind a pasted link names"
- Changed
write_org_doc2 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / expected_commitAdded value: +{ + "description": "the document head you read at (read_org_doc prints it; any lowercase prefix of at least 7 hex characters). Refuses if that document has changed since, or is not there. Omit to write whatever is there now.", + "pattern": "^[0-9a-f]{7,64}$", + "type": "string" +}
Publisher details
- Operator
- agentleFS
- Operator website
- https://agentlefs.com
- Vendor relationship
- First-party
- Documentation
- https://agentlefs.com/docs/connect?ref=glama
- Trust center
- Not available
- Restrictions
- None. Free, no card required. No admin approval or custom OAuth app: users sign in through the browser via OAuth with dynamic client registration. Clients that only accept a request header (e.g. Cline) use an agent token minted in the console under Permissions.
Related MCP Connectors
Private shared file system for agents: workspaces, invites, shared files.
File hosting for agents. Upload any file, get a public link in seconds.
Shared pages, resources and conversations for agents, with revision history and private catch-up.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to interact with Nextcloud files only through human-approved, time-limited grants, with mandatory audit logging and no standing content access.GPL 3.0
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to search, retrieve, and share files by meaning across connected storage, with permission-aware access control and an audit trail.Apache 2.0
Praxis Liteofficial
AlicenseAqualityAmaintenanceEnables AI agents to safely interact with local files by enforcing policies that allow, block, or require approval for actions, while protecting credentials and maintaining a tamper-proof audit log.122MIT
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.