Skip to main content
Glama
r28ai

support-inbox-mcp

by r28ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

gdrive_files_copy

Create a duplicate of a Google Drive file and apply updates like a new name or parent folder. This enables versioning or moving files without altering the original.

Instructions

Create a copy of a file and apply any requested updates with patch semantics. Typically send a new name and optionally parents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileYesThe file resource to apply on the copy, with patch semantics. Typically `name` and optionally `parents`. If `parents` is omitted, the copy inherits any discoverable parent of the source file.
fileIdYesThe ID of the file.
ocrLanguageNoA language hint for OCR processing during image import (ISO 639-1 code).
copyCommentsNoWhether to copy the comments associated with the file.
includeLabelsNoA comma-separated list of IDs of labels to include in the `labelInfo` part of the response.
supportsAllDrivesNoWhether the requesting application supports both My Drives and shared drives.
keepRevisionForeverNoWhether to set the `keepForever` field in the new head revision. This is only applicable to files with binary content in Google Drive. Only 200 revisions for the file can be kept forever. If the limit is reached, try deleting pinned revisions.
ignoreDefaultVisibilityNoWhether to ignore the domain's default visibility settings for the created file. Domain administrators can choose to make all uploaded files visible to the domain by default; this parameter bypasses that behavior for the request. Permissions are still inherited from parent folders.
includePermissionsForViewNoSpecifies which additional view's permissions to include in the response. Only `published` is supported.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the write/non-safe nature is covered structurally. The description adds 'patch semantics' and the inheritance rule for omitted parents, but says nothing about the copy's sharing/permission behavior, comment copying, or quota 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, zero filler, and the core action plus the common invocation pattern are front-loaded. Nothing here could be trimmed without losing meaning.

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?

With 9 parameters all documented in the schema and no output schema, the description covers the basics of what the tool does. However, it omits the behavioral context an agent needs for a mutation tool: whether the source is modified, what the response contains, and permission/quota implications.

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's note about name/parents largely restates what the `file` parameter description in the schema already says, adding no new syntax or format detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Create a copy of a file', which is plainly distinguishable from the sibling gdrive_files_create. It does not explicitly name or contrast the sibling, so it stops short of a 5.

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 sentence 'Typically send a new `name` and optionally `parents`' gives practical guidance on the common call shape, but there is no when-to-use/when-not-to-use framing, no prerequisite permissions, and no routing against alternatives like gdrive_files_create.

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

Deploy Server

Other Tools