The lasuite-docs-mcp server provides an MCP interface to the LaSuite Docs external API, enabling comprehensive document management through a secure OpenID Connect (PKCE) authentication flow.
User
Retrieve the authenticated user's profile.
Document Reading
List all accessible documents (with pagination), child documents, document versions, trashbin contents, and favorited documents.
Get a document's metadata or body content (as markdown, HTML, or JSON).
Document Writing
Create documents with an optional title, markdown body, and parent (for nesting).
Update a document's title or content (via raw base64-encoded Yjs data).
Soft-delete documents (move to trashbin) and restore them.
Move documents under a different parent.
Favorites
Add or remove documents from favorites.
Access Control (requires enabling document_access actions in server config)
List, retrieve, create, update, and delete document access permissions for sharing.
Authentication
Uses OIDC Authorization Code + PKCE flow, with refresh tokens stored securely in the OS keychain.
Integration with Auth0 as an OpenID Connect provider for authentication to the LaSuite Docs API.
Integration with Authentik as an OpenID Connect provider for authentication to the LaSuite Docs API.
Integration with Keycloak as an OpenID Connect provider for authentication to the LaSuite Docs API.
Integration with Okta as an OpenID Connect provider for authentication to the LaSuite Docs API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lasuite-docs-mcp list my documents"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the LaSuite Docs external API.
It exposes Docs operations (list/read/create/update/delete documents, versions,
favorites, current user) as MCP tools. Authentication uses the OIDC
Authorization Code + PKCE flow against any OpenID Connect provider, with a
refresh token cached in the OS keychain. Runs over stdio — no public hosting,
no inbound ports. The OIDC redirect is captured by a one-shot loopback server on
127.0.0.1.
Claude ──stdio──> lasuite-docs-mcp ──Bearer token──> Docs /external_api/v1.0
│
└── Auth Code + PKCE ──> OIDC provider (issues + introspects tokens)Works with any standards-compliant OIDC provider (Keycloak, Authentik, Zitadel, Auth0, Okta, Ory Hydra, …). Authentik is used as a worked example throughout, marked Example (Authentik).
Python ≥ 3.10
A running LaSuite Docs instance with the resource server enabled (§2)
An OIDC provider you control, able to register clients and run token introspection (§3)
Related MCP server: google-workspace-mcp-server
Docs must run as an OIDC resource server. Set in Docs' environment:
OIDC_RESOURCE_SERVER_ENABLED=True
OIDC_OP_URL=<issuer URL of your OIDC provider>
OIDC_OP_INTROSPECTION_ENDPOINT=<provider token-introspection endpoint>
OIDC_RS_CLIENT_ID=<client id Docs uses to call introspection>
OIDC_RS_CLIENT_SECRET=<that client's secret>
OIDC_RS_AUDIENCE_CLAIM=<claim Docs checks for audience, e.g. aud>
OIDC_RS_ALLOWED_AUDIENCES=<value the MCP token must carry, see §3.4>Introspection-response format — important. django-lasuite ships two resource server backends:
| Expects the introspection response as |
| a signed+encrypted JWT (RFC 9701 |
| plain JSON (RFC 7662, standard) |
Most providers (Keycloak, Authentik, Zitadel, Auth0, …) return plain JSON. If yours does, set:
OIDC_RS_BACKEND_CLASS=lasuite.oidc_resource_server.backend.ResourceServerBackendLeave the default only if your provider actually issues JWT-secured introspection
responses (e.g. ProConnect). Wrong choice → 400 Bad Request / "improperly
configured" (see §9).
EXTERNAL_API action allowlistEXTERNAL_API controls which resources/actions the resource-server API exposes.
Every tool maps to an action that must appear in this allowlist, or the call
returns 403 (and unknown nested resources return 404). The default only
allows documents: [list, retrieve, create, children] and users: [get_me],
so most tools need it widened. Full config covering every tool in this server:
EXTERNAL_API={"documents":{"enabled":True,"actions":["list","retrieve","create","children","formatted_content","content_retrieve","content","partial_update","destroy","move","favorite","versions_list","trashbin","favorite_list","restore"]},"document_access":{"enabled":True,"actions":["list","retrieve","create","update","partial_update","destroy"]},"users":{"enabled":True,"actions":["get_me"]}}Gotcha — Python literal, not JSON. Docs parses this env var with
ast.literal_eval, so booleans must beTrue/False(capitalized), not JSONtrue/false. JSON booleans crash Docs at boot withValueError: Cannot interpret dict value ... malformed node or string(§9).
Action → tool mapping (non-obvious ones): formatted_content →
get_document_content (reads the body), content → update_document_content
(PATCH raw Yjs), content_retrieve → raw base64 Yjs GET, children →
parented create_document, document_access.* → the *_document_access tools.
The document resource has no plain content field. create_document with a
markdown body uploads it as a .md file that Docs converts to Yjs server-side.
That conversion needs:
CONVERSION_UPLOAD_ENABLED=TrueWithout it, create_document(markdown=...) returns 400 file upload is not allowed. Reading the body back uses the formatted_content action (above).
Docs validates every token by introspecting it and checking: the token is
active, its issuer equalsOIDC_OP_URL, and its audience claim is inOIDC_RS_ALLOWED_AUDIENCES. All three must line up (§3). Mismatch → 400/401.
Register a client for the MCP server and make sure the tokens it issues pass Docs' three checks. The concepts are provider-agnostic; the example shows where each lives in Authentik.
Create an OAuth2 / OIDC client for the MCP server:
Client type: public (PKCE, no secret) — recommended for a desktop/CLI tool. Confidential (with secret) also works.
Grant type: Authorization Code (+ refresh token).
Redirect URI: http://127.0.0.1:8765/callback (exact match; change both
here and OIDC_REDIRECT_URI together).
Scopes: openid profile email (+ an audience scope, §3.4).
Example (Authentik) — Admin → Applications → Providers → Create → OAuth2/OpenID Provider. Set redirect URI
http://127.0.0.1:8765/callback, client type Public, attach an Application. Note its issuer URLhttps://<host>/application/o/<app-slug>/.
iss check)The token's iss claim must equal Docs' OIDC_OP_URL exactly. Easiest way:
let the MCP client and Docs trust the same issuer.
If your provider has one global issuer (Keycloak realm, Zitadel, Auth0 tenant), this is automatic — point both at it.
If your provider issues a per-client/per-application issuer, either reuse
the same provider/issuer Docs already trusts, or switch to a global/shared
issuer mode so both emit the same iss.
Example (Authentik) — issuer is per-application by default (
…/o/<slug>/), so a separate MCP application gets a differentissthan the Docs login app →InvalidClaimError: iss. Fix: set the provider's Issuer mode = "Same identifier (global)" on both providers, or have the MCP use the same provider Docs trusts.
active check)Docs introspects with OIDC_RS_CLIENT_ID/SECRET. Many providers only return
active: true when the introspecting client is allowed to introspect that
token (usually the token-issuing client, or one explicitly granted). If a
different client introspects, you get active: false → "user is not active".
Fix: set Docs' OIDC_RS_CLIENT_ID/SECRET to a client permitted to introspect
the MCP tokens — typically the same client that issues them, or configure
your provider's introspection/audience permissions accordingly.
Example (Authentik) — cross-client introspection returns
active:false. Set DocsOIDC_RS_CLIENT_ID/SECRETto the MCP application's client.
OIDC_RS_ALLOWED_AUDIENCES check)The token must carry an audience value that Docs allows. Two approaches:
A — provider emits the audience claim (recommended).
Add a claim/mapper so issued tokens include the configured audience under the
claim Docs reads (OIDC_RS_AUDIENCE_CLAIM). Set
OIDC_RS_ALLOWED_AUDIENCES to that value.
Example (Authentik) — Customisation → Property Mappings → Create → Scope Mapping: scope name
docs, expressionreturn {"docs-aud": "<your-audience>"}. Attach scopedocsto the provider, adddocstoOIDC_SCOPE, set DocsOIDC_RS_AUDIENCE_CLAIM=docs-audandOIDC_RS_ALLOWED_AUDIENCES=<your-audience>. Simpler alternative: use the standardaudclaim (= client id by default) — setOIDC_RS_AUDIENCE_CLAIM=aud,OIDC_RS_ALLOWED_AUDIENCES=<mcp-client-id>.
B — audience request parameter.
If your provider honors an audience auth-request param, set OIDC_AUDIENCE
(§4). Not all providers honor it (Authentik ignores it) — prefer A.
The claim name in OIDC_RS_AUDIENCE_CLAIM and the value in
OIDC_RS_ALLOWED_AUDIENCES must point at the same thing, and that thing must
be present in the token / introspection response.
cp .env.example .env # then edit, or pass these via the MCP env block (§6)Var | Meaning |
| Docs host, e.g. |
| API prefix, default |
| Your provider's issuer URL (server reads |
| the MCP client's id |
| empty for public/PKCE; set for a confidential client |
|
|
|
|
| only for §3.4 B; else leave empty |
Pick one. All expose the lasuite-docs-mcp command.
uv tool (recommended):
uv tool install git+https://github.com/Bone2510/lasuite-docs-mcp # from GitHub
uv tool install . # local checkoutpipx:
pipx install git+https://github.com/Bone2510/lasuite-docs-mcpEditable dev install:
python -m venv .venv && source .venv/bin/activate
pip install -e .No install (uvx, run on demand):
uvx --from git+https://github.com/Bone2510/lasuite-docs-mcp lasuite-docs-mcpAdd to your MCP config (~/.claude.json / project .mcp.json). With uv tool/pipx
the command is on your PATH. The installed command runs from an arbitrary working
dir, so pass config via the env block (a .env is only picked up when the cwd
is the project dir):
{
"mcpServers": {
"lasuite-docs": {
"command": "lasuite-docs-mcp",
"env": {
"DOCS_BASE_URL": "https://docs.example.org",
"OIDC_OP_URL": "https://auth.example.org/realms/main",
"OIDC_CLIENT_ID": "lasuite-docs-mcp",
"OIDC_CLIENT_SECRET": "...",
"OIDC_SCOPE": "openid profile email docs",
"OIDC_REDIRECT_URI": "http://127.0.0.1:8765/callback"
}
}
}
}No-install variant:
"command": "uvx",
"args": ["--from", "git+https://github.com/Bone2510/lasuite-docs-mcp", "lasuite-docs-mcp"]On the first tool call the server opens your browser to the provider. After
login it captures the redirect on 127.0.0.1:8765, stores the refresh token in
your OS keychain, and reuses/refreshes it silently afterward.
mcp dev lasuite_mcp/server.py # MCP inspector (interactive)Call get_current_user first — it exercises the whole chain (login →
introspection → issuer → audience → user).
Read: get_current_user, list_documents, get_document (metadata only),
get_document_content (body as markdown/html/json), get_children,
list_versions, list_trashbin, list_favorites.
Write: create_document (optional markdown body), update_document (title),
update_document_content (raw base64 Yjs), delete_document,
restore_document, move_document, add_favorite, remove_favorite.
Accesses (sharing): list_document_accesses, get_document_access,
create_document_access, update_document_access, delete_document_access.
get_documentnever returns the body — Docs stores it as collaborative Yjs. Useget_document_contentto read it (needs theformatted_contentaction, §2.1).
Server-side errors surface as a bare Django page; the real reason is in the Docs backend logs. Common cases (all server-side OIDC config):
Symptom | Cause / fix |
| RS backend failed to init — |
| Provider returns plain-JSON introspection but |
| Introspecting client may not introspect this token → set Docs RS creds to the token-issuing client (§3.3). |
| Token |
| Token audience ∉ |
Browser never opens | stdio has no TTY; the auth URL is printed to stderr — open it manually. |
| Provider redirect URI ≠ |
| Your Docs version uses a different path — adjust in |
accesses/invitations | Those scopes are disabled in Docs |
| The action is not in the |
| By design — body is Yjs, use |
|
|
Docs crashes at boot, |
|
Port 8765 in use | Change |
PKCE (S256) is always used, even with a client secret.
Redirect is loopback-only (127.0.0.1), random state checked against CSRF.
Refresh token lives in the OS keychain (via keyring); if keyring is
unavailable it falls back to in-memory (re-login each start).
Tokens are never logged.
Content model (verified against current Docs): the body is a Yjs/BlockNote
CRDT, not a field on the document resource. Read it via get_document_content
(formatted-content endpoint → markdown/html/json). Write paths: create_document
uploads a markdown file that Docs converts to Yjs (needs CONVERSION_UPLOAD_ENABLED);
update_document_content PATCHes a raw base64 Yjs blob (no markdown→Yjs path
exists for updates). update_document only changes the title.
Exact sub-paths (favorite-list/, move/, restore/, favorite/,
accesses/) follow current conventions — confirm against your Docs
EXTERNAL_API routes.
Mark a document as favorite.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose idempotency, permission requirements, side effects, or error conditions. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 4 words is concise but too brief for a helpful description. Front-loaded, but lacks essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, no output schema), the description should specify that the document must exist or that it's user-scoped. It is incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not add meaning beyond the parameter name 'document_id', e.g., format or expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark a document as favorite' clearly states the action (mark) and resource (document), and distinguishes from sibling tools like remove_favorite and list_favorites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool (e.g., document must exist, user must have access) or when not to use alternatives. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a document. content is the body (markdown/text per instance).
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | No | ||
| parent_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Create a document' (a mutation) and explains the content parameter. It fails to mention permissions, rate limits, whether overwriting occurs, or what the tool returns. This is minimal disclosure for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first declaratively states the purpose, and the second adds relevant detail about the content parameter. No extraneous words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no annotations, and no output schema, the description is too sparse. It omits return value, error handling, side effects, and parameter constraints beyond a single content type hint. Incomplete for a creation tool that needs to inform the agent about what happens after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It only explains 'content' as markdown/text, leaving 'title' and 'parent_id' with no additional context. This does not adequately compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a document', a specific verb+resource pair. It distinguishes from sibling tools like delete_document, update_document, etc. It also clarifies the 'content' parameter as the body, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use create_document versus alternatives such as update_document or restore_document. No context on prerequisites, such as whether parent_id is optional or required for hierarchical structures, is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Soft-delete a document (moves to trashbin).
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait (soft-delete, moves to trashbin), which is critical because it implies reversibility. However, with no annotations provided, it lacks details on authorization needs, rate limits, or whether the operation can fail silently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no verbosity. It is front-loaded with the primary action. However, it could include a brief note about parameter context without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools like restore_document and list_trashbin, the description provides enough context for the basic operation. However, it omits prerequisites, output description, and any mention of error conditions, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional meaning for the 'document_id' parameter beyond its type and requirement. The agent gains no guidance on how to obtain or format the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (soft-delete) and the resource (document) with the side effect (moves to trashbin). It distinguishes from sibling tools like restore_document and list_trashbin by specifying the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., move_document, hard delete). The description does not mention prerequisites, such as ownership or permissions, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List child (sub-)documents of a document.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing behavioral details such as what happens for invalid document IDs, whether it is read-only, or the depth of child nesting returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It could benefit from separating input and output details or adding a note about limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is insufficiently complete. It omits what the returned list contains, error handling, and pagination or ordering info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to add meaning beyond the parameter name. It does not explain the format, constraints, or expected values for document_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists child documents of a parent document. This distinguishes it from sibling tools like list_documents (which lists all documents) and get_document (which retrieves a single document).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like list_favorites or list_trashbin. No context about prerequisites or typical use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the authenticated user (GET /users/me/).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states the action, omitting details like authentication requirements, rate limits, response format, or that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It immediately conveys the tool's purpose and includes the HTTP method and path for reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameters and annotations, the description is minimal. It does not explain the return value structure or any potential errors, which could be necessary for an agent to effectively use the result. However, for a simple retrieval tool, it may be marginally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description adds no parameter information. Schema coverage is 100%, and no additional semantic clarification is needed. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return the authenticated user' with a specific verb and resource, and includes the API endpoint for reference. It is distinct from sibling tools which focus on documents and favorites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the current user's information, but provides no explicit guidance on when to use this tool versus alternatives (e.g., if there were a tool to get another user by ID). No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single document's metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits like read-only nature, auth requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but lacks any structure; it is a single sentence that does not fully utilize its length to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description fails to explain what 'metadata' includes, leaving the agent without expected response details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the 'document_id' parameter, and the schema has 0% coverage, so the parameter is entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'document's metadata', distinguishing it from sibling tools like 'get_children' or 'list_documents'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as when metadata is needed versus full content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List documents accessible to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only states listing documents, omitting pagination behavior (though schema has page/page_size), sorting, whether trashed documents are included, or if authentication is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence) but lacks structure. It is front-loaded with the verb, but the minimalism sacrifices informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with pagination and no output schema, the description does not indicate what is returned (e.g., metadata, content) or how pagination is handled. Incomplete for an agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the page or page_size parameters or their defaults, providing no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'documents', with scope 'accessible to the user'. It distinguishes from sibling tools like get_document (single document), list_favorites, list_trashbin, and list_versions, which have more specific scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention that it lists all accessible documents without filtering, or that get_document retrieves a single document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List favorited documents.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'List favorited documents.' No details on authentication, pagination, or behavior when no favorites exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (two words) and front-loaded without waste, though a bit more context could improve usability without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description is minimal. It tells what the tool does but omits return format or behavioral details, leaving gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100% trivially. Description adds no additional meaning beyond the schema, warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List favorited documents.' clearly states the action (list) and the resource (favorited documents), distinguishing it from siblings like list_documents and remove_favorite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; usage is implied by the name and description, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List soft-deleted documents in the trashbin.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states a read operation without disclosing details like authorization, scope (user vs. system), or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool, the description is mostly adequate but lacks details on what fields are returned or any filtering context, which could be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; description adds meaning by specifying the resource type (soft-deleted documents) and location (trashbin), which is essential given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (soft-deleted documents in the trashbin), distinguishing it from siblings like list_documents and list_favorites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives; no prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List stored versions of a document.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention whether versions are sorted, if pagination exists, or if full document content is returned. The statement 'List stored versions' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than good conciseness. Every sentence should earn its place; here, the sentence is too brief to be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one parameter, the description is incomplete. It fails to explain what the tool returns (e.g., a list of version metadata) or any behavior like limiting the number of versions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the parameter name 'document_id.' It does not explain how to obtain a valid document_id or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource 'stored versions of a document.' However, it does not differentiate from sibling tools like 'list_documents' or 'list_favorites,' though the resource is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_document' or 'list_trashbin.' The description merely states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a document under another document.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | ||
| target_parent_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it fails to mention any side effects, permissions needed, reversibility, or error conditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no unnecessary words, but it is overly concise missing critical information. Conciseness alone does not compensate for lack of depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description is severely incomplete. It does not cover return values, error scenarios, or behavioral implications, making it inadequate for safe tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no additional meaning to the parameters beyond their names. It does not explain what format the IDs should be, what 'target_parent_id' refers to, or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Move a document under another document.' It uses a specific verb and resource, and it distinguishes from sibling tools like create_document or delete_document, as no other tool performs a move operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or conditions mentioned. The description only states what it does, without any contextual usage notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a document from favorites.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose side effects, permissions required, or error behaviors beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise, but underspecified for a tool with no annotations and only one parameter. Could be expanded to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a single undocumented parameter, the description is incomplete. Does not explain return values or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single parameter 'document_id'. Description adds no meaning or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('a document from favorites'), clearly distinguishing it from siblings like 'add_favorite'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites or exceptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore a soft-deleted document from the trashbin.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states the action without disclosing side effects, required permissions, or behavior in edge cases (e.g., if document is not in trashbin).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words, delivering the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, no output schema), the description is minimally adequate but could mention that the document must be soft-deleted and what the return value is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description adds no meaning beyond the parameter name 'document_id'. The agent gains no insight into what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (restore), the object (soft-deleted document), and the source (trashbin), effectively distinguishing it from siblings like delete_document and list_trashbin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for documents in the trashbin, but lacks explicit guidance on when not to use or mention of alternatives. Clear context partially compensates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a document's title and/or content (PATCH).
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | ||
| title | No | ||
| content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only indicates 'PATCH' semantics. It does not disclose whether authentication is needed, what happens if the document doesn't exist, if the operation is idempotent, or if the updated document is returned. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. Every element (verb, resource, parameters, method) earns its place. It is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (3 parameters, no output schema, no nested objects). The description covers the basic function, but omits return value details and error conditions. Without an output schema, the agent lacks information on what the tool returns, which is a gap for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It mentions 'title and/or content', clarifying that these are optional and partial. However, it does not explain the 'document_id' parameter, nor the format expected for content (e.g., plain text, Markdown). It adds partial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Update' and the resource 'document', and mentions 'title and/or content' as updatable fields. The inclusion of '(PATCH)' indicates a partial update, distinguishing it from full replacements and from sibling tools like create_document or delete_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like move_document or list_documents. No context is given for prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_favoritecreate_documentdelete_documentget_childrenget_current_userget_documentlist_documentslist_favoriteslist_trashbinlist_versionsmove_documentremove_favoriterestore_documentupdate_documentEach tool has a clearly distinct purpose: create, delete, restore, move, update documents; listing different scopes (all, favorites, trashbin, versions); managing favorites; and user info. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_document, list_favorites, get_document). No deviations or mixed conventions.
14 tools are well-scoped for document management, covering CRUD, navigation, versioning, favorites, and trashbin operations. The count fits the 3-15 sweet spot.
The set covers most core operations, but lacks a dedicated endpoint to retrieve the full document content—only metadata is returned by get_document. Minor gap considering the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for the PDFGate API. Generate PDFs, manage documents and handle e-signatures.
The official MCP Server from Mia-Platform to interact with Mia-Platform Console
MCP server for innovationlab documentation, generated by doc2mcp.
DocBase MCP server for AI agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bone2510/lasuite-docs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
