Google Drive CRUD MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Multiple tools overlap in purpose, especially around permissions: manage_drive_access, set_drive_file_permissions, get_drive_file_permissions, and check_drive_file_public_access have unclear boundaries. Listing tools (search_files, list_recent_files, list_drive_items) are distinguishable but could be confused.
Naming Consistency3/5
Naming mixes verb_noun patterns (get_file_metadata, create_drive_folder) with reverse noun_verb patterns (spreadsheets_get, docs_batch_update). Inconsistent use of 'file' vs 'drive_file' and similar operations named differently (read_file_content vs download_file_content).
Tool Count4/5
25 tools is on the high end but reasonable for a server covering Google Drive plus Docs, Sheets, and Slides. Some redundancy (permission tools) makes it feel slightly heavy, but most tools serve distinct purposes.
Completeness2/5
The tool set includes create, read, and update operations but completely lacks delete or trash functionality, a fundamental gap for a 'CRUD' server. Also missing native creation for Sheets and Slides, relying on import/update only.
Average 4.1/5 across 25 of 25 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds no behavioral context, such as potential data loss from trashing or parent changes. It merely restates the tool's purpose without disclosing consequences beyond what the annotations already convey.
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 short sentence with no redundant words, and it is front-loaded with the verb 'Updates'. It is appropriately concise, though it could arguably include a bit more detail without becoming verbose.
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?
Despite having 12 parameters and an output schema, the description is very vague about the scope of updates (e.g., rename, trash, permissions, parent changes) and lacks any context for when to use this tool. The schema compensates with parameter descriptions, but the overall tool guidance is incomplete for an AI agent.
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 covers all 12 parameters with descriptions (100% coverage). The description adds no additional parameter semantics; the schema already provides details like 'Whether to move file to/from trash' for the trashed parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Updates') and resource ('Google Drive file'), clearly indicating it modifies file metadata and properties. However, it does not distinguish from sibling tools like 'set_drive_file_permissions' which also updates file properties, so it lacks explicit differentiation.
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 such as 'create_file', 'copy_drive_file', or 'manage_drive_access'. The description gives no context, prerequisites, or exclusions, leaving the agent to infer the appropriate usage scenario.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds shared-drive scope but no behavioral details like pagination or search operator caveats. The schema covers those constraints, so the description is not contradictory but offers minimal added 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?
Single sentence, front-loaded with the key action and scope, zero filler. It is as concise as possible while conveying the core purpose.
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 10 parameters and a rich schema with output schema, but the description lacks usage guidance and differentiation from siblings like list_drive_items. It is complete enough to identify the tool but leaves invocation semantics and comparative use entirely to schema and 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?
Schema covers 100% of parameters with detailed descriptions, including caveats about shared drive owner queries. The description itself adds no parameter semantics, but the schema carries the full burden adequately.
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 'Searches for files and folders within a user's Google Drive, including shared drives' – a clear verb+resource+scope. It distinguishes from list_recent_files by emphasizing query-based search, though it doesn't explicitly name alternatives.
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 on when to use search_files vs list_drive_items or list_recent_files. The description lacks any 'when to use' or 'use instead' language, leaving the agent to infer from the name and sibling context.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds the specific scope of 'including sharing permissions,' which clarifies the returned metadata. However, it does not add further behavioral context such as whether the operation requires prior authentication (though openWorldHint is true) or how permissions are represented, so it provides only marginal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the action and resource. It contains no redundant information and is appropriately sized for the tool's simplicity.
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 has only two parameters, a thorough output schema, and strong annotations (readOnly, idempotent, non-destructive), the description is largely complete for a straightforward read operation. The only gap is the lack of usage guidance, but that is captured under a separate dimension. The description sufficiently conveys what the tool does without needing to describe return values thanks to the output schema.
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 schema descriptions fully cover both parameters (file_id and user_google_email), so the description does not need to add much. It does not explain any additional meaning beyond the schema, such as how the parameters interact or any format expectations. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and identifies the resource ('detailed metadata about a Google Drive file including sharing permissions'). It clearly states the tool's function, though it does not explicitly distinguish it from sibling tools like get_file_metadata or check_drive_file_public_access, so it misses the top score for sibling differentiation.
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 any prerequisites, exclusions, or comparisons with sibling tools such as get_file_metadata or check_drive_file_public_access, leaving the agent without usage context.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no behavioral context beyond the obvious action, which is acceptable given the strong 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, straightforward sentence that directly states the tool's function. It is well-sized and immediately front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the combination of a 100% covered schema, strong annotations, and an output schema makes the description sufficient for an agent to understand invocation. A usage hint would be nice but isn't critical for correctness.
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 complete descriptions for both parameters (file_id and user_google_email), so the description doesn't need to elaborate. The phrase 'file or folder' reinforces file_id but adds no new semantics.
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 'Gets' and the resource 'shareable link', specifying file or folder scope. This distinguishes it from sibling tools like get_file_metadata or get_drive_file_permissions, though it doesn't explicitly name alternatives.
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. It doesn't mention scenarios or contrast with related tools like check_drive_file_public_access or manage_drive_access.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'single file by ID' scoping, which is useful, but does not describe authentication requirements, return format, or potential errors. Since annotations carry most of the burden, a 3 is appropriate.
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 with no filler. It directly states the action, target, and identifier, earning its place without waste.
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 metadata lookup with rich annotations and an output schema, the description is largely sufficient. However, the missing guidance on user_google_email and no explicit tie to sibling tools prevent a perfect score. Overall, it provides enough context for basic correct usage.
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 only 50% (fileId is described, user_google_email is not). The description mentions file ID but adds no further meaning for user_google_email. It does not compensate for the missing schema description, leaving parameter semantics incomplete.
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 a specific action ('Returns metadata') on a specific resource ('a single Google Drive file'), identified by ID. This distinguishes it from sibling tools like 'read_file_content' or 'download_file_content', which deal with file content rather than metadata.
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 fetching metadata when you have a file ID, but it does not explicitly state when to prefer this over alternatives or mention any exclusions. Given the simple scope, context is reasonably clear, but there is no direct guidance on alternate tools.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the core behavioral context—searching by name and checking public link sharing status—which is consistent with annotations. It does not elaborate on edge cases like multiple matches or file-not-found, but these may be covered by the output schema.
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, efficiently worded sentence with no filler. The main action and target are front-loaded, making it immediately clear what the tool does.
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 simple read-only nature of the tool, the presence of a rich output schema, and strong annotations, the one-sentence description is largely sufficient. It could be improved by noting differences from closely related siblings or handling ambiguous cases, but overall it covers the essential 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?
Schema description coverage is 100%, and every parameter (user_google_email, file_name, drive_id) already has a detailed schema description. The description only reiterates that the search is by name, adding no new meaning beyond what the schema provides, so the baseline score of 3 applies.
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 tool searches for a file by name and checks whether public link sharing is enabled. It uses specific verbs ('searches', 'checks') and names a concrete resource and condition, distinguishing it from permission or link-retrieval tools, though it does not explicitly name alternatives.
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: use this tool when you want to determine if a named Drive file has public link sharing enabled. However, it gives no explicit guidance on when to choose this over sibling tools like get_drive_shareable_link or get_drive_file_permissions, and no exclusions are stated.
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?
Annotations already disclose destructiveHint=true and readOnlyHint=false, so the description does not need to restate these. The description adds some context by naming destructive actions like 'revoking permissions' and 'transferring file ownership', but does not elaborate on side effects (e.g., emails sent, irreversibility) beyond what the schema's parameter descriptions provide. No contradiction with 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 two sentences long and front-loaded with the core purpose. It avoids unnecessary detail and clearly enumerates capabilities without fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 14 parameters and multiple actions, the description gives a solid high-level overview. The schema covers all parameter semantics and the output schema handles return values. The only minor gap is not mentioning authentication prerequisites or explicitly pointing to read-only sibling tools, but overall the context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level semantics; it only lists actions. However, each parameter is thoroughly described in the schema (e.g., 'used by grant_batch', 'Required for update and revoke'), so the description does not need to compensate.
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: 'Consolidated tool for managing Google Drive file and folder access permissions.' It enumerates specific actions (granting, batch-granting, updating, revoking, transferring ownership), which distinguishes it from sibling read-only tools like get_drive_file_permissions and check_drive_file_public_access.
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 any permission management task ('single entry point'), but it does not explicitly state when to use this tool versus alternatives, such as using get_drive_file_permissions for read-only access checks. No when-not-to-use guidance is provided, leaving usage rules implied rather than explicit.
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?
Annotations already indicate a non-read-only operation, so the description is not required to state mutation. It adds the shared drive support detail, which is a useful behavioral nuance. However, it does not disclose other traits like name conflict handling, auth requirements, or response format, so it provides only partial transparency.
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 that efficiently states the core purpose and the shared drive differentiation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete schema and output schema present, the description covers the essential purpose and shared drive support. It does not elaborate on edge cases or prerequisites, but the overall level is adequate for a straightforward folder creation tool, leaving minor 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?
The input schema covers 100% of the parameters with descriptions, including the shared drive note for parent_folder_id. The tool description does not add additional parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a new folder in Google Drive' which is a specific verb+resource+scope. It also adds the shared drive support, distinguishing it from sibling tools like create_file or copy_drive_file.
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 implies when to use by naming the resource (folder) and specifically notes support for shared drives, which gives context for the parent_folder_id use case. However, it does not explicitly state when not to use it or name alternatives like create_file for files.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds context about spanning all drives and excluding trashed items, which is useful. It does not mention pagination behavior or result size limits, but that's minor given 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?
Single, information-dense sentence. Front-loaded with the verb 'Lists' and clearly structured with scope and exclusion details.
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 output schema and annotations, the description covers the essential scope and exclusions. Minor omissions like ordering details and pagination are not critical since schema provides page_token semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers page_size and page_token with descriptions (67% coverage), but user_google_email lacks a description. The description's phrase 'the user' hints at the email parameter but does not fully compensate for the missing schema description. Moderate coverage, so description adds minimal semantic value.
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?
Description clearly states the tool lists recently modified files, specifies scope ('across all drives') and exclusions ('Excludes trashed items'). This distinguishes it from siblings like search_files and list_drive_items.
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?
Provides clear context that this is for recently modified files, but does not explicitly mention when to use it vs alternatives like search_files or list_drive_items. No exclusions or alternative guidance provided.
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?
Annotations already declare destructiveHint=true, readOnlyHint=false, so the agent knows this is a mutating operation. The description adds no extra behavioral context (e.g., what exactly gets destroyed, auth requirements, or side effects on existing permissions). With annotations covering the safety profile, this is acceptable but not enriched.
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 concise and well-structured. It front-loads the primary purpose in the first sentence, then clarifies scope and provides alternatives in the following sentences. No unnecessary information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and comprehensive parameter schema, so the description does not need to explain return values. The description covers purpose and usage clearly, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 5 parameters clearly documented. The description itself does not explain parameters but relies on the schema, which is fully sufficient. This meets the baseline for high 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's function with a specific verb and resource: 'Sets file-level sharing settings and controls link sharing for a Google Drive file or folder.' It also distinguishes from siblings by explicitly mentioning individual user/group permission management as separate.
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 provides explicit when-to-use guidance ('Use this to toggle "anyone with the link" access') and names alternatives ('use share_drive_file or update_drive_permission instead'). However, the referenced alternatives are not present in the given sibling-tools list, which may mislead an agent into calling unavailable tools.
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?
Annotations indicate readOnlyHint=false, confirming a write operation, but the description adds useful context: 'The copy maintains all formatting and content from the original file.' This goes beyond the annotations and explains a key behavioral trait. No contradictions with annotations are present.
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 concise, with three sentences that each add value: purpose, copying behavior, and preservation of formatting. It is front-loaded and avoids redundancy or fluff.
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?
The description covers the core behavior and mentions key options (new name, destination). An output schema exists (as indicated in context signals), so return value details are not required. It doesn't address permission inheritance or auth flow, but given the annotations and schema, the description is sufficiently complete for a copy operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are well-documented in the schema itself. The description mentions 'template document' and 'new location,' which loosely align with file_id and parent_folder_id, but it does not add significant semantic meaning beyond the schema's parameter 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 states 'Creates a copy of an existing Google Drive file' with a specific verb and resource, distinguishing it from sibling tools like create_file or update_drive_file. It also specifies that the copy goes 'to a new location with an optional new name,' which further clarifies its unique function.
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 implies the tool is for copying existing Drive files, with mention of 'template document' as a common use case. While it doesn't explicitly name alternative tools or state when not to use it, the context is clear enough for an agent to infer appropriate usage.
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?
Annotations already indicate a write operation (readOnlyHint: false) and non-destructive behavior (destructiveHint: false). The description adds valuable behavioral context: it supports creation within shared drives and accepts either direct content or a fileUrl for fetching content. This goes beyond the structured annotations and helps the agent understand key execution modes, though it could disclose more about side effects (e.g., auto-conversion 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 two sentences long, front-loaded with the primary action, and includes only essential details. There is no redundancy or filler, making it easy to parse and act upon.
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 that an output schema exists (so return values are defined) and annotations cover key safety hints, the description covers the main context: what the tool creates, where it can create, and how content is supplied. It does not address edge cases like precedence when both content and fileUrl are provided, but for a creation tool this is minor and leaves the overall description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, which is high, so the baseline is 3. The description adds relational meaning that the schema does not explicitly state: 'content' and 'fileUrl' are mutually exclusive alternatives for supplying file content. This clarifies the intended usage of the parameters and earns a point above baseline.
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 ('Creates a new file in Google Drive') and adds a distinguishing scope ('supporting creation within shared drives'). This differentiates it from siblings like create_drive_folder or copy_drive_file, which create or copy different entity types.
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: if you need to create a file in Drive, this is the tool. It mentions support for shared drives and content sources, but does not explicitly contrast with alternatives (e.g., when to use import_to_google_doc or create_resumable_upload_session). While the context is clear, exclusions or explicit alternative references are absent.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond that: it details what the returned body.content contains (index ranges for every paragraph/text run) and how to leverage that data. This is useful, non-redundant information that helps the agent use the tool correctly.
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 two sentences long, front-loads the core action, and each sentence earns its place. The first sentence states the purpose, and the second explains a practical use of the output. There is no filler, redundancy, or unnecessary detail.
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 output schema exists, the description doesn't need to enumerate return values. It adds contextual value by connecting this tool's output to docs_batch_update and docs_replace_all_text, which are sibling tools, and hints at the multi-tab caveat indirectly via includeTabsContent. It lacks explicit info about auth requirements, but openWorldHint suggests external auth is handled elsewhere. Overall, it is complete enough for an agent to invoke it correctly.
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 already provides descriptions for fields, documentId, and includeTabsContent, covering 75% of parameters. The description mentions the body.content structure but does not add new parameter-level semantics. It doesn't explain user_google_email, but the schema omits a description there too. Since the schema does most of the work, this falls at the baseline of 3.
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 states a specific verb ('Read'), a clear resource ('Google Doc's content and structure'), and identifies the underlying API ('documents.get'). This sets it apart from sibling tools like docs_batch_update or get_file_metadata, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains why this tool is valuable—to obtain startIndex/endIndex pairs needed for docs_batch_update requests and to verify edits. While it doesn't explicitly say 'use this instead of X', it clearly conveys the primary use case and the context in which this tool is necessary, which is more than minimal guidance.
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?
Beyond annotations indicating mutation, the description explains that it uses documents.batchUpdate with one replaceAllText request per item and preserves formatting, adding behavioral context not in annotations. This helps the agent understand 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function and followed by a key benefit. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary use case, behavior, and safety for templates. Given the output schema covers return values and annotations cover mutation flags, no major gaps exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 75% of parameters with descriptions; the description doesn't add parameter-specific details but ties the replacements to replaceAllText semantics. The user_google_email parameter remains undocumented, but the overall schema coverage makes up for it.
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 performs find-and-replace across a Google Doc, with a specific verb ('Replace') and resource. It also distinguishes it from broader tools like docs_batch_update by emphasizing placeholder-friendly behavior.
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 notes it preserves surrounding formatting and is the 'safest way to fill placeholders in a template document,' which gives a clear when-to-use context. It doesn't explicitly mention alternatives, but the context implies this over generic batch update.
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?
Annotations already declare this is a write operation (readOnlyHint=false). The description adds that it performs a batch of requests and gives examples of non-destructive operations, but does not discuss partial failure behavior, permissions, or reversibility. It adds modest context beyond 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?
Two sentences, front-loaded with the core action and method, followed by a focused use-case and helper-function pointer. No redundant words.
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?
The tool is complex, but the description covers the main use cases and provides a helper for building requests. It omits discussion of other request types and the purpose of user_google_email, but overall it is adequate given the presence of an output schema and annotations.
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 covers requests and spreadsheetId, but leaves user_google_email undefined. The description compensates for the complex requests parameter by referencing a builder function (build_batch_requests()) and giving examples. It does not clarify user_google_email, but the other two parameters are well-covered.
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 applies a batch of update requests to a Google Sheet, with explicit mention of the underlying API method (spreadsheets.batchUpdate). It distinguishes itself from siblings like docs_batch_update and presentations_batch_update by specifying Google Sheet, and provides concrete example operations (addChart, repeatCell).
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 indicates this is used by the QBR skill for adding charts and setting number formats, giving clear usage context. It does not explicitly name alternatives or exclusions, but the resource type (Google Sheet) clearly separates it from docs/presentations batch update tools.
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?
Annotations already indicate non-read-only, non-idempotent, non-destructive behavior. The description adds valuable behavioral context: the returned upload_url is used to PUT raw bytes directly to Google, only the short URL travels through MCP, and the bytes bypass MCP transport limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose, followed by concise operational detail. Every sentence earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the presence of an output schema, and annotations, the description is complete: it explains the two-phase upload flow, the reason for the resumable session, and how the returned URL is used. No significant gaps remain for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema already documents most parameters well. The description does not add parameter-level meaning beyond the schema, but it does explain the overall flow with upload_url. This meets the baseline for high schema coverage without compensating for the undocumented user_google_email.
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+resource statement: 'Creates a Google Drive resumable upload session and returns the upload URL.' This clearly distinguishes it from sibling tools like create_file or import_to_google_doc by focusing on the resumable session and the returned upload_url.
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 explicitly states the intended caller (a skill in claude.ai's sandbox) and explains that this tool should be used to bypass MCP transport limits for large content. It gives clear context on when to invoke it, though it does not explicitly name alternative tools or provide when-not-to-use exclusions.
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?
Beyond the annotations (readOnlyHint:false, etc.), the description reveals that this is a legacy OAuth 2.0 tool disabled in OAuth 2.1, that it manually initiates the auth flow, and that the system already handles auth automatically, so using it is an exception. This adds meaningful behavioral context about when it applies and why.
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 about 100 words, front-loaded with the action, followed by a clear note and bullet guidelines. Every part is useful and formatted for scannability.
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?
The description covers purpose, usage conditions, and legacy status well. However, it omits parameter semantics (noted above) and doesn't mention what actually happens after initiation (e.g., user prompt, return value), though an output schema exists. Overall it's solid but not fully complete.
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?
Neither 'service_name' nor 'user_google_email' is described in the description or schema (coverage 0%). The description gives no hints about what values to use, leaving the agent to guess. This is a significant gap for a required parameter.
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 'Manually initiate Google OAuth authentication flow', a specific verb and resource. It also distinguishes itself from sibling Google Workspace tools as an auth utility and notes its legacy status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three conditions for use ('Only use this tool if...') and advises that in most cases users should 'simply try calling the Google Workspace tool you need' because authentication is automatic. This is explicit when-to-use and when-not-to-use guidance with an alternative.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description goes beyond that by explaining how to use the fields parameter for partial responses and the revision guard, adding valuable behavioral nuance.
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 concise and well-structured: a single sentence stating the core purpose, followed by a tight bullet list of field mask use cases. Every line earns its place without unnecessary fluff.
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 moderate complexity and the presence of an output schema, the description covers the essential usage. It explains the fields parameter in detail and the revision guard, but does not explicitly state behavior when fields is omitted (e.g., returns full presentation). This is a minor gap but not critical.
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 basic descriptions for fields and presentationId, but the description enhances understanding significantly by explaining the structure and purpose of the fields mask (e.g., slides(objectId,pageElements(...))). This compensates for the 67% schema coverage and adds practical value.
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 explicitly states 'Read a Google Slides presentation (presentations.get)', which is a specific verb (read) and resource (presentation). It clearly distinguishes from sibling tools like presentations_batch_update, which handles modifications.
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?
Clear context for when to use the tool (reading a presentation) is provided, but it does not explicitly mention when not to use it or name alternatives like presentations_batch_update. The field mask use cases (slot resolution, embed verification, revision guard) add practical guidance.
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?
The description discloses detailed behavioral traits beyond annotations: how each file type is processed (e.g., PDFs via pypdf, images as base64), including fallback to a download hint for scanned PDFs and binary note for unreadable files. This adds substantial context beyond the readOnlyHint/idempotentHint 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 well-structured with a clear lead sentence followed by bullet points separated by file type. Every bullet adds specific behavioral detail, and there is no filler or redundancy. The format makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are already defined. The description covers all major file categories, fallback behaviors, and special cases (images, binary), making it complete enough for an agent to anticipate behavior. It does not need to detail error cases.
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 input schema covers only 50% of parameters (fileId only, and minimally). The description fails to compensate: it does not explain user_google_email, which has no schema description, nor does it add meaning about parameter usage beyond implying fileId is needed. This leaves a critical parameter opaque.
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 states a specific action ('Retrieves the content of a specific Google Drive file by ID') and distinguishes itself from the sibling tool download_file_content by emphasizing content extraction with format-specific conversion. It also mentions support for shared drives, clarifying scope.
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 by enumerating supported file types and fallback behaviors, which implies when to use this tool. However, it does not explicitly contrast with alternatives like download_file_content or docs_get, so it lacks explicit exclusions or named alternatives.
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?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context about the API call type and specific use cases for the fields mask, such as retrieving sheet IDs and chart specs, without contradicting 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 compact two sentences. The first sentence states the primary purpose, and the second provides actionable advice on the fields mask. No filler 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?
Given the output schema, annotations, and simple parameter set, the description provides enough context for correct invocation. It could mention alternatives (e.g., for cell data use read_file_content) but is sufficiently complete for a metadata read tool.
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 already describes fields and spreadsheetId, covering 67% of parameters. The description adds concrete examples of how to use the fields mask with specific field paths, exceeding the schema's generic 'field mask' note, which helps the agent construct correct requests.
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 reads Google Sheet metadata via the specific API method spreadsheets.get, distinguishing it from sibling tools that read file content or update spreadsheets. It also specifies concrete sub-uses: resolving sheet IDs and verifying charts.
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 provides clear context for when to use this tool (reading metadata, resolving sheet IDs, verifying charts) but does not explicitly name alternatives or state when not to use it. It offers practical parameter guidance, which supports usage decisions.
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?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that Google Drive automatically converts the file to native format and preserves formatting, and it warns about memory/time limits with file_path. This adds meaningful behavioral context without contradicting 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 concise, with a clear first sentence stating the main purpose, followed by a useful detail on conversion behavior and a practical usage tip. Every sentence contributes meaning, and the text is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters, the presence of a schema covering them, the output schema, and annotations, the description adds appropriate context about formats, conversion, and memory considerations. It is complete enough for an agent to use the tool correctly without needing additional information.
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 covers all 7 parameters with descriptions, so the baseline is 3. The description adds extra value by explaining the trade-off between content and file_path, specifically recommending file_path for batch operations to reduce context load, which is not fully captured in the schema alone.
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 imports files in several formats (Markdown, DOCX, TXT, HTML, RTF, ODT) into Google Docs format with automatic conversion. It specifies the action and resource, and the mention of conversion distinguishes it from sibling tools like create_file or docs_batch_update.
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 provides clear context that this tool is for importing files and converting them to Google Docs, and it gives practical guidance by recommending file_path for batch operations to avoid loading content into context. It does not explicitly name alternative tools, but the purpose is distinct enough that usage is well-understood.
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?
Beyond the annotations, the description discloses important behavioral details: it retries transient Drive eventual-consistency failures with exponential backoff up to ~30s, and it recommends writeControl to guard against clobbering concurrent human edits. These add meaningful context beyond the readOnlyHint/destructiveHint 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 structured into three short paragraphs—purpose, usage instructions, and retry behavior—all of which directly support tool selection and invocation. Every sentence earns its place, with no filler or redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch update tool with a rich schema and output schema, the description covers purpose, invocation pattern, request construction, concurrency safety, and retry behavior. The reference to the helper function and the writeControl source provides the necessary context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers requests, writeControl, and presentationId at 75% coverage; the description adds practical meaning by specifying that requests should be built with build_link_requests() and that writeControl should contain a requiredRevisionId from presentations_get. The user_google_email parameter remains undescribed, but overall the description enhances parameter understanding.
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 'Apply a batch of update requests to a Google Slides presentation (presentations.batchUpdate)', which is a specific verb+resource that immediately identifies the tool's function. It explicitly names Google Slides and the exact API method, distinguishing it from sibling tools like spreadsheets_batch_update and docs_batch_update.
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 provides concrete usage context: 'Used by the QBR skill to delete chart placeholders and embed LINKED Sheets charts' and explains how to build requests and pass writeControl. It does not explicitly state when not to use the tool or mention alternatives, but the context is clear enough for correct selection.
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?
It discloses the critical, non-obvious behavior that 'Indexes shift... so order edits from the END' and warns that 'stale indexes edit the wrong ranges silently.' This goes well beyond the sparse annotations (readOnlyHint false, etc.) by explaining the failure mode and how to prevent it through writeControl.
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 four sentences, each adding substantive value: purpose, accepted types, ordering strategy, and concurrency control. It is front-loaded and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this complexity, the description covers all essential operational aspects: supported request types, index-shift ordering, the need to fetch current indexes, and optional writeControl for conflict detection. The output schema exists, so it need not describe return values. This is complete and actionable.
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 covers 75% of parameters, but the description adds meaningful semantic detail. It explains that the requests array can contain any Docs API request type, that indexes shift, and that writeControl should carry the revision id from docs_get. The only undocumented param, user_google_email, is self-explanatory by name.
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 'Apply a batch of edit requests to a Google Doc (documents.batchUpdate)', using a specific verb and resource. It also lists the accepted request types (insertText, deleteContentRange, etc.), which distinguishes it from sibling tools like docs_get or docs_replace_all_text.
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 usage context: 'Get current indexes from docs_get first' and 'order edits from the END of the document toward the start, or send one request per call.' It also explains when to use writeControl. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral detail about drive scoping, folder_id relationships, and the include_items_from_all_drives flag, which goes beyond the schema and annotations. No contradiction.
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 about four sentences, front-loaded with the core action, and each conditional clause adds necessary behavior. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and an existing output schema, the description covers the tool's main modes and edge cases (shared drives, root, all drives). It doesn't need to re-explain return values or every parameter's format because the schema covers those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by clarifying that folder_id is relative to drive_id and that drive_id can be used as folder_id for root, plus the effect of resource_type. This elevates it above baseline.
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 'Lists files/folders or shared drive containers,' giving a specific verb and resource, and further clarifies the two modes (folder contents vs shared drive containers). It distinguishes itself from siblings like search_files or list_recent_files through this explicit scoping.
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 provides explicit conditional usage: 'If drive_id is specified...', 'If drive_id is not specified...', and 'Set resource_type to "shared_drives"...'. This gives clear context for when to use each mode, though it does not name alternative tools directly.
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?
While annotations already indicate readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context beyond these flags. It discloses the size limit (DOWNLOAD_FILE_CONTENT_MAX_MB, default 25 MB), the error behavior for oversized files, and the default export formats for Docs/Sheets/Slides. This transparency helps the agent anticipate outcomes and plan fallbacks, going well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the core purpose in the first sentence, then using a bullet list for export formats, and a short paragraph for size limits. Every sentence adds value, but it is slightly longer than strictly necessary. The structure aids readability, but a more concise version could achieve the same clarity with fewer words. Overall, it is appropriately sized for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and several sibling tools, the description is remarkably complete. It explains the return format (base64 bytes), export format behavior for native files, the original format for other files, the size limit with its error handling, and the fallback to read_file_content or shareable links. No major gaps remain: the agent knows what to expect and how to handle edge cases, making the description sufficient even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with fileId and export_format having schema descriptions but user_google_email having none. The description enriches export_format semantics by specifying default export formats (e.g., Docs -> PDF/DOCX, Sheets -> XLSX/PDF/CSV, Slides -> PDF/PPTX), which the schema's simple options list does not provide. However, it does not add any information about user_google_email, leaving that parameter under-described. This is a good but not perfect compensation for the coverage gap.
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: 'Downloads a Google Drive file and returns its raw bytes as a base64-encoded blob.' It uses a specific verb ('downloads') and resource ('Google Drive file'), and further distinguishes itself by describing export behavior for native Google files and the fallback to read_file_content for large files. This makes it distinct from siblings like read_file_content which handles text extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. For large files, it states that an error 'pointing to read_file_content for text extraction, or a Drive shareable link as a fallback' is returned, directly indicating the alternative. It also explains the export format options for different Google native file types, helping users decide when to specify export_format.
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:

[![claude-gdrive-mcp MCP server](https://glama.ai/mcp/servers/adampaulwalker/claude-gdrive-mcp/badges/card.svg)](https://glama.ai/mcp/servers/adampaulwalker/claude-gdrive-mcp)

Score Badge

Copy to your README.md:

[![claude-gdrive-mcp MCP server](https://glama.ai/mcp/servers/adampaulwalker/claude-gdrive-mcp/badges/score.svg)](https://glama.ai/mcp/servers/adampaulwalker/claude-gdrive-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/adampaulwalker/claude-gdrive-mcp'

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