worksmobile-mcp

by z0nam

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, with only minor potential overlap between works_share_create/works_perm_grant and works_files_list/works_search. The descriptions generally resolve ambiguity adequately.
Naming Consistency4/5
Tools follow a consistent noun_verb pattern (e.g., drive_get, files_list, perm_grant), with the exception of works_search, which lacks a resource prefix. This is a minor deviation from an otherwise predictable naming convention.
Tool Count4/5
16 tools is slightly above the typical 3-15 range, but the scope covers file management, permissions, sharing, and a raw API escape hatch. Each tool serves a distinct purpose, making the count reasonable for the apparent domain.
Completeness3/5
The toolkit covers listing, downloading, uploading, sharing, and permission management well, but lacks file delete, rename, move, and drive lifecycle operations (create/update/delete). These gaps are notable for a file management server.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states the action and provides an example of a filter parameter, but does not disclose return format, pagination, permissions, whether it is read-only, or any side effects. This is a significant gap.
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 description is a single, concise sentence that front-loads the core function. The parenthetical example adds useful context without redundancy. However, it is slightly under-structured—a brief list of parameters would improve usability without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no annotations, and no output schema, this one-line description is grossly insufficient. It does not explain how the search works, what is returned, or how filters and other parameters interact. An agent would have to guess most of the tool's behavior and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains drive_type_filters with an example ('SHARE_DRIVE'), leaving the required 'query' and optional 'user' parameters completely unexplained. This is inadequate for an agent to understand how to fill the parameters correctly.
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 clearly states the tool's purpose: 'Search drive files' with a specific verb and resource. It also includes an example filter, which helps distinguish it from sibling tools like works_files_list and works_drive_get, making the intended function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention exclusions, prerequisites, or which sibling tools are more appropriate in certain scenarios. The example filter hints at usage but does not constitute clear guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a confirm requirement, implying a safety mechanism, but does not explain its purpose or consequences. With no annotations, it fails to mention whether the operation is reversible, if special permissions are needed, or what side effects removing sharing may have on existing permissions.
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?
Two sentences, with the main action front-loaded and no extraneous detail. The confirm requirement is stated efficiently, making the description concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive operation with no annotations and no output schema, yet the description is extremely sparse. It lacks details on what 'remove sharing' entails, whether it deletes all permissions, error conditions, or success indicators, leaving an AI agent under-informed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter meaning: it notes confirm must be true. However, it does not explain file_id or owner_email semantics, and given 0% schema coverage, the description bears the full burden of explaining these parameters but fails to do so.
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 clearly states the action (remove sharing) and the resource (a My Drive folder), using a specific verb. It distinguishes itself from sibling tools like works_share_create by indicating the opposite operation, though it could more explicitly differentiate from works_perm_revoke which also deals with permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as works_perm_revoke or works_share_create. The only hint is 'Requires confirm=true,' which is a prerequisite rather than an indication of appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and scope condition, but omits any details about permissions, side effects, response format, pagination, or error handling. It doesn't even explicitly state that the operation is read-only, leaving the agent to infer it from 'List'.
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?
The description is extremely concise, using two short sentences to convey the action and the key conditional. There is no redundant phrasing or unnecessary detail. Every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters, no output schema, and no annotations, the description is quite sparse. It explains only the sharedrive_id behavior and leaves the user and folder_id semantics unclear. The description also fails to mention what data is returned (metadata, contents, recursive listing) or any constraints, making it insufficient for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only explains sharedrive_id ('that shared drive' vs 'My Drive'). It does not clarify the meaning or usage of user or folder_id, which remain ambiguous despite having titles. Since the schema provides no descriptions, the description should compensate but only partially does.
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 'List files/folders', providing a clear verb and resource. It also distinguishes between shared drives and My Drive based on the sharedrive_id parameter, which gives specific scope. However, it does not explicitly reference sibling tools like works_drives_list or works_sharedfolders_list, so differentiation is implicit 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers a conditional usage rule for sharedrive_id ('With sharedrive_id: that shared drive; else the delegated user's My Drive'), which clarifies when to use that parameter. But it provides no guidance on when to choose this tool over alternatives like works_search or works_drives_list, and it does not explain the role of user or folder_id parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the base URL and the confirm flag for non-GET, but fails to describe side effects, authentication, error behavior, rate limits, or response format. For a tool that can perform arbitrary mutations, this is a significant omission, leaving the agent under-informed about the tool's full behavior.
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 description is two sentences and front-loads the core purpose. It is concise and every sentence adds value. However, it is perhaps too terse, lacking details that could be added without undermining conciseness. Still, structure is clean and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a generic raw API caller with 5 parameters, no annotations, and no output schema. The description only provides a base path and a confirm requirement. It omits crucial operational details like how to construct endpoints, expected response format, error handling, and when to use this tool versus the many sibling tools. This is inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It provides limited context for 'path' (relative to the base URL) and 'confirm' (needed for non-GET), but does not explain 'method', 'body_json', or 'user'. This is insufficient for a 5-parameter tool where the schema itself has no descriptions.
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 clearly identifies the tool as a raw API escape hatch for the WORKS API, with a specific base URL. This distinguishes it from the sibling tools, which are purpose-built for specific operations (e.g., works_drive_get, works_files_list) and makes the tool's role obvious.
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?
The 'escape hatch' wording implies the tool is a fallback for when specific siblings don't cover an operation, but it does not explicitly state when to use this vs. alternatives. The confirm=true requirement for non-GET requests provides some usage guidance, but no exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists the output fields but does not explicitly state that the operation is read-only, mention permission requirements, or explain how the optional 'user' parameter affects results. It also lacks details on response shape, pagination, or error behavior.
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?
The description is a single sentence, front-loaded with the verb and object, and uses a parenthetical to enumerate fields. There is no filler or redundancy, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a minimal schema, no annotations, and no output schema, placing a high burden on the description. It covers the output fields but omits the meaning of the 'user' parameter, any filtering behavior, and contextual details that would help the agent invoke the tool correctly. This is incomplete for even a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'user', is not mentioned anywhere in the description. With 0% schema description coverage, the description must compensate and explain this parameter, but it completely omits it. The parenthetical list refers to output fields, not input parameters, so no semantic value is added.
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 'List' paired with a clear resource 'shared drives', and enumerates the returned fields (id, name, accessibleRange, permissionType, masters). This clearly distinguishes it from siblings like works_drive_get (singular get) and works_files_list.
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?
The description implies usage as the tool for listing shared drives, but it provides no explicit guidance on when to use it over alternatives, nor any exclusions. The name and verb alone make the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure, but it only reveals a 2-step metadata+PUT flow. It does not mention needed permissions, overwrite behavior, partial-failure handling, or the response format.
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?
The description is a single, front-loaded sentence with no redundancy. The parenthetical '2-step metadata+PUT flow' efficiently adds useful behavioral context without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an upload tool with no annotations, no output schema, and 0% schema description coverage, one sentence is insufficient. Missing are prerequisites, error conditions, permission requirements, and any information about return values or success/failure indicators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description partially maps 'local file' to file_path and 'My Drive folder' to parent_folder_id. However, the name and user parameters are left undocumented, and the description does not fully compensate for the low schema coverage.
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 'Upload' with a clear resource 'a local file into a My Drive folder', distinguishing it from siblings like works_file_download. The phrase '2-step metadata+PUT flow' adds technical specificity without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 on prerequisites such as target folder existence or file accessibility. The only context is the action itself; there are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The verb 'Get' implies a read operation, but it does not explicitly state safety, permissions, side effects, or return format. It adds context about the settings fields but fails to disclose important behavior for a tool with no 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?
The description is a single concise sentence, front-loaded with the verb and resource, containing no filler or redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description should explain return values and parameter effects. It lists the settings fields but does not state that the response is a settings object or how `user` influences the request, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the `user` parameter or the format of `sharedrive_id`, only vaguely implying an identifier via 'one shared drive'. This is insufficient given the lack of schema descriptions.
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 the specific verb 'Get' and names the resource 'one shared drive's settings', clearly distinguishing it from sibling tools like works_drives_list (which lists drives). It also enumerates the settings (accessibleRange, permissionType), 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving settings of a single shared drive, and the word 'one' contrasts with list tools. However, it does not explicitly state when to prefer this over alternatives or provide any exclusions, relying only on implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states the action is 'List', which implies a read-only operation, but it does not mention return value, authentication needs, or any side effects. Beyond indicating scope, it offers no additional behavioral context.
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?
The description is a single, concise sentence that front-loads the purpose and includes a key modifier ('with folder_id') in a parenthetical. Every word contributes meaning, with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description gives a clear overview and covers the folder_id nuance. However, it omits any mention of the 'user' parameter's role, and without an output schema, a brief return-value description would improve completeness. It is minimally adequate but has clear gaps.
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?
There are three parameters with zero schema descriptions. The description adds meaning for 'folder_id' by indicating it changes the behavior to folder-level, and implies that omitting it means drive-level. However, it does not explain 'user' or 'sharedrive_id' beyond their names, leaving some semantics implicit.
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 clearly states the tool's function: listing permissions. It specifies the scope ('drive-level or, with folder_id, folder-level'), which distinguishes it from sibling list tools for drives, files, and shared folders. The verb 'List' is specific and matches the resource type.
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?
The description implies when to use this tool (when you need to list permissions) and mentions the folder_id condition for folder-level permissions. However, it does not explicitly name alternatives or exclusions, leaving the usage context to inference from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that the tool 'follows the storage redirect with auth,' which is useful. However, it omits other important behaviors such as whether existing files are overwritten, required permissions, or the return format on success/error.
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?
The description is a single, front-loaded sentence: 'Download a file to a local path' followed by a useful parenthetical about auth redirect. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and performs a side effect (writing to a local path), the description is under-specified. It does not mention what the tool returns, whether it overwrites files, how optional parameters (user, sharedrive_id) affect the operation, or any error conditions. The note about auth redirect is the only extra context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain any of the four parameters (file_id, out_path, user, sharedrive_id) or their roles in the download. The parameter names are somewhat self-explanatory, but the description adds no explicit meaning beyond 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 description clearly states the action: 'Download a file to a local path' with a specific verb and resource. It distinguishes from sibling tools like works_file_upload and works_files_list by focusing on the download operation, which no other sibling provides.
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?
The description gives clear context for when to use the tool (when a file needs to be downloaded to a local path) and mentions the auth redirect behavior, which is a relevant usage consideration. It does not explicitly mention alternatives or exclusions, but since there is no alternative download tool among the siblings, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adds context about the delegated user's My Drive and the root-if-no-parent behavior, which is useful. However, it does not disclose potential side effects, permissions, or what happens when the user parameter is null, leaving gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, then adds the key scoping detail. Every word earns its place; it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with no annotations and no output schema, the description provides the core purpose and a key location behavior. However, it omits return value information, prerequisites, and edge-case behavior, making it less complete for an agent that must invoke it correctly without additional context.
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?
With 0% schema description coverage, the description must compensate. It clarifies parent_folder_id via 'root if no parent' and references the user parameter via 'delegated user's My Drive', but it does not explain the name parameter or the optional nature of user beyond the schema default.
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 ('Create') and resource ('folder'), and adds the scoping detail 'in the delegated user's My Drive (root if no parent)'. This clearly identifies the tool's function and distinguishes it from sibling tools like folder_enable/disable.
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?
The description implies usage by stating the target location and the parent-folder behavior, but it does not explicitly say when to use this tool versus alternatives or provide any exclusions. It gives clear context but no alternative guidance, so it falls short of a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the need for confirm=true and the inability to bulk delete, which is useful behavioral information. However, it does not explain what happens when confirm is false, required prerequisites, or potential errors, leaving some ambiguity for a destructive operation.
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?
The description is three short sentences, front-loaded with the primary action, and contains no unnecessary words. Every sentence adds meaningful information about the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is too sparse. It omits the role of sharedrive_id, user, and folder_id, and does not clarify return values or failure modes, making it incomplete for an agent to safely invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must explain all parameters, but only perm_id and target_email are mentioned. The required sharedrive_id parameter is not described, and user, folder_id, and confirm (beyond 'required') lack semantic detail. This is insufficient for a 6-parameter tool.
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 clearly states the verb 'Delete' and the resource 'permission', specifying the two identifier methods (perm_id or target_email). This unambiguously distinguishes it from sibling tools like works_perm_grant and works_perms_list.
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 practical usage context by stating that bulk delete is unsupported and that confirm=true is required, which helps the agent know constraints. It does not explicitly mention alternatives or when not to use this tool, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden of behavioral disclosure. It effectively warns that enabling folder-level permissions breaks inheritance and results in a 'masters-only' state until grants are made. This is significant, useful context. It does not mention reversibility or the fate of existing permissions, but the core side effect is clearly disclosed.
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?
The description is extremely concise, consisting of two sentences that deliver the core purpose, a critical warning, and a required parameter. There is no filler or redundancy, and the most important information is front-loaded.
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?
Given the tool's complexity (4 parameters, no output schema) and the lack of annotations, the description covers the most critical aspects: the action, the warning about inheritance, and the confirm requirement. It does not describe return values or fully elaborate on the 'masters-only' state, but it is sufficient for an agent to understand the basic behavior and risk.
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?
The input schema provides no descriptions (0% coverage), so the description must compensate. It does add crucial semantics for the 'confirm' parameter by stating it must be true. The other parameters (sharedrive_id, folder_id, user) are not explained, but their names and roles are reasonably self-explanatory from 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?
The description clearly states the action ('Enable folder-level permissions') with a specific verb and resource. It implies a distinction from siblings like works_folder_disable, but does not explicitly differentiate itself from similar permission-related tools such as works_perm_grant.
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?
The description includes a prerequisite ('Requires confirm=true') and a cautionary warning ('breaks inheritance'), which provide some usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions that would make it inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the effect (appears in 'shared with me'), scope (My Drive only), and a requirement (confirm=true). But it omits side effects, return value, and how parameters like perm_type and notify affect behavior, leaving some transparency gaps.
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?
The description is three concise sentences, each adding value: the effect, the scope limitation, and the confirm prerequisite. It is front-loaded with the most critical information and contains no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description provides only the core purpose and two constraints. It fails to explain parameter relationships, when to prefer this over similar siblings, or expected outcomes, leaving significant contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only hints at confirm=true and that a My Drive folder is shared, leaving most parameters (file_id, owner_email, to_email, perm_type, notify) semantically unexplained. This is inadequate for a 6-parameter tool.
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 the specific verb 'Share' with the resource 'My Drive folder' and clearly states the outcome (appears in the recipient's 'shared with me'). It also differentiates from siblings by scoping to My Drive only and explicitly excluding shared drives.
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?
The description gives clear context for when to use (sharing My Drive folders) and an exclusion (not shared drives), plus a prerequisite (confirm=true). However, it does not explicitly name alternative sibling tools like works_perm_grant, so it lacks the full when-to-use vs. alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the safety requirement 'Requires confirm=true' and clarifies the two scope modes. But with no annotations, it does not mention whether the grant is additive, if existing permissions are overwritten, or what the response looks like, leaving room for ambiguity.
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?
One concise sentence that is front-loaded with the core action and includes the critical confirm requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no annotations, and no output schema, so the description should be more comprehensive. It covers the action and the confirm flag but omits side effects, return value, and idempotency, leaving the agent with partial understanding.
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?
With 0% schema description coverage, the description helps interpret key parameters: folder_id (folder-level), perm_type (READ/WRITE), and confirm (must be true). However, it does not explain user, sharedrive_id, or target_email beyond their obvious meanings, so it partially compensates.
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 'Grant' and identifies the resource as 'READ/WRITE to a member', clearly distinguishing drive-level vs folder-level scope. This differentiates it from sibling tools like works_perm_revoke and works_perms_list.
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 clearly implies the use case: granting permissions to a member, with the optional folder_id for folder-level grants. However, it does not explicitly name alternatives or state when not to use it, so it stays at clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It does disclose the delegated user requirement, which is useful auth/behavioral context. However, it does not describe response format, pagination, or error behavior, leaving gaps for a read operation without 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?
The description is a single, clear sentence that immediately conveys the tool's purpose and key requirement. No unnecessary words or redundancy.
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 simple list tool with one parameter, the description covers the essential purpose and the delegated-user prerequisite. While there is no output schema, the return type (list of folders) is reasonably implied, but no explicit mention of return details prevents a 5.
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?
The schema provides only a bare 'user' parameter with no description. The description clarifies that the user must be a member and must be a delegated user, adding meaning that compensates for the 0% schema coverage.
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 clearly states the tool lists a member's 'shared with me' folders, specifying the resource type (shared folders) and scope (member's). This distinguishes it from sibling tools like works_drives_list (which presumably lists all drives) and works_files_list (which lists files).
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?
The description mentions the prerequisite that the member must be a delegated user, providing some usage context. However, it does not explicitly compare with alternatives or state when not to use this tool, so usage is implied rather than clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It explicitly warns that the action 'drops folder grants, restores inheritance' and requires `confirm=true`, revealing a destructive and potentially irreversible effect. This goes well beyond what the schema alone indicates (confirm parameter exists, but its mandatory nature is not obvious) and is genuinely helpful.
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?
The description is extremely concise and well-structured. It front-loads the purpose, then delivers a warning, and finally states the confirmation requirement. Every sentence adds distinct value, with no filler or repetition.
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?
Given the tool's complexity (no annotations, no output schema, 4 parameters), the description covers the core details: purpose, destructive warning, and confirmation requirement. It does not explain the `user` parameter's role or potential reversibility, but for a focused permission-disabling action, the provided context is mostly sufficient. Slight room for improvement in addressing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, so the description must compensate. It explains only `confirm` (must be true) but leaves `sharedrive_id`, `folder_id`, and `user` without added meaning beyond their names. For instance, `user` is optional and could be interpreted as a filter, but no clarification is provided. This is a significant gap for a tool with multiple parameters.
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 specific verb plus resource: 'Disable folder-level permissions.' It clearly distinguishes from the sibling tool `works_folder_enable` by stating the opposite action. The additional detail on dropping grants and restoring inheritance further clarifies the exact scope.
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?
The description implies when to use the tool (to disable folder-level permissions) but provides no explicit exclusions or alternatives. For instance, it does not contrast with `works_perm_revoke` for revoking specific user grants. The requirement to set `confirm=true` is a prerequisite, not a usage guideline, so guidance is limited to implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![worksmobile-mcp MCP server](https://glama.ai/mcp/servers/z0nam/worksmobile-mcp/badges/card.svg)](https://glama.ai/mcp/servers/z0nam/worksmobile-mcp)

Score Badge

Copy to your README.md:

[![worksmobile-mcp MCP server](https://glama.ai/mcp/servers/z0nam/worksmobile-mcp/badges/score.svg)](https://glama.ai/mcp/servers/z0nam/worksmobile-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/z0nam/worksmobile-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server