What can you do with this server?

This server provides read-only access to multiple Google Drive accounts through the Model Context Protocol (MCP), offering comprehensive file management and content extraction capabilities. Account Management: * List, add, and remove multiple Google Drive accounts using service account JSON authentication File Operations: * List files with filtering by drive, folder, modification date, MIME type, and pagination support * Search files by name within specific drives * Recursive scanning to traverse folder hierarchies up to specified depths with optional filters * Extract content from Google Docs (plain text), Google Sheets (CSV), Google Slides, and text files (TXT, Markdown) Key Features: * Read-only operations using Google Drive API with drive.readonly scope * Secure authentication via optional API key (query parameter or X-API-Key header) * Modern StreamableHTTP transport with stateless architecture for multiple concurrent clients * Docker-ready deployment with configurable ports for VPS environments * Access to comprehensive metadata including file IDs, names, MIME types, modification dates, sizes, and web links

Which integrations are available for this server?

Uses Google Cloud Console for service account creation and Google Drive API authentication to enable secure multi-account Drive access Allows reading and exporting Google Docs content as plain text through the Google Drive integration Provides read-only access to Google Drive with multi-account support, enabling file listing, searching, content extraction, and management of Google Workspace documents across multiple Drive accounts Enables access to Google Sheets data with CSV export functionality through the Google Drive integration Provides access to Google Slides presentations through the Google Drive integration

How do I use Google Drive MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Google Drive MCP Server search for 'Q4 report' in my work drive" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Google Drive MCP Server

by andresfrei

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Hybrid

Google Drive MCP Server

Servidor MCP (Model Context Protocol) modernizado para gestión de múltiples cuentas de Google Drive con acceso de solo lectura.

🎯 Características

✅ StreamableHTTP Transport: Arquitectura stateless HTTP moderna (reemplaza SSE deprecado)
✅ MCP SDK v1.19.1: Usando McpServer high-level API con validación automática
✅ Multi-cliente: Múltiples clientes pueden conectarse simultáneamente (stateless)
✅ Puerto configurable: Ideal para VPS con múltiples servicios MCP
✅ Multi-cuenta: Gestiona múltiples cuentas de Google Drive simultáneamente
✅ 7 Herramientas MCP: Incluyendo listado recursivo de carpetas
✅ Arquitectura modular: Tools organizadas en módulos independientes
✅ Autenticación segura: Query parameter o header API key
✅ Operaciones de archivos: Listar, buscar, recursivo y obtener contenido
✅ Soporta Google Workspace: Docs, Sheets, Slides
✅ Archivos de texto: TXT, Markdown
✅ Logging estructurado: Winston con múltiples niveles
✅ Validación robusta: Zod schemas en todas las herramientas
✅ Path alias @/: Imports absolutos desde src/
✅ Oxlint + Prettier: Linting ultrarrápido y formato consistente
✅ Docker-ready: Configuración lista para deployment en VPS

Related MCP server: Google Drive MCP Server

📁 Estructura del Proyecto

src/
  config/
    config-loader.ts    # Gestión de configuración de Drives
    types.ts            # Tipos y esquemas Zod

  services/
    drive-service.ts    # Servicio de Google Drive API (incluye recursivo)

  utils/
    logger.ts           # Sistema de logging con Winston

  mcp/
    auth.ts             # Autenticación de requests MCP
    server.ts           # Configuración del servidor MCP (33 líneas)
    tools/              # 🆕 Herramientas modularizadas
      index.ts          # Exportador central
      list-drives.ts    # Listar cuentas configuradas
      add-drive.ts      # Agregar cuenta
      remove-drive.ts   # Eliminar cuenta
      list-files.ts     # Listar archivos con filtros
      list-files-recursive.ts  # 🆕 Listado recursivo
      get-file-content.ts      # Obtener contenido
      search-files.ts          # Buscar por nombre

  index.ts              # Entry point del servidor

tests/
  test-mcp-client.ts    # Test de conexión general
  test-recursive.ts     # Test de listado recursivo
  test-drive.ts         # Test de API de Drive
  README.md             # Documentación de tests

🚀 Instalación y Deployment

Desarrollo Local

# Clonar repositorio
git clone https://github.com/andresfrei/mcp-google-drive-server.git
cd mcp-google-drive-server

# Instalar dependencias
pnpm install

# Configurar environment
cp .env.example .env
nano .env

# Desarrollo (con hot reload)
pnpm dev

# El servidor estará disponible en http://localhost:3001

Producción con Docker

# Build y run con docker-compose
docker-compose up -d

# Ver logs
docker-compose logs -f mcp-drive

# Detener
docker-compose down

VPS con Múltiples MCPs

Para ejecutar varios servidores MCP en el mismo VPS, configura diferentes puertos:

# MCP Drive en puerto 3001
MCP_DRIVE_PORT=3001 docker-compose up -d

# En otro directorio, otro MCP en puerto 3002
cd ../otro-mcp && MCP_OTRO_PORT=3002 docker-compose up -d

⚙️ Configuración

1. Service Account de Google

Crear proyecto en Google Cloud Console
Habilitar Google Drive API
Crear Service Account y descargar JSON
Compartir carpetas/archivos de Drive con el email del Service Account
Guardar JSON en credentials/

2. Archivo de Configuración

El servidor usa drives-config.json para gestionar cuentas:

{
  "drives": {
    "personal": {
      "name": "Drive Personal",
      "description": "Mi Drive personal",
      "serviceAccountPath": "./credentials/personal-sa.json"
    },
    "work": {
      "name": "Drive Trabajo",
      "description": "Cuenta corporativa",
      "serviceAccountPath": "./credentials/work-sa.json"
    }
  }
}

Nota: El archivo se crea automáticamente vacío si no existe. Usa la herramienta add_drive para agregar cuentas.

3. Variables de Entorno

# Configuración del servidor HTTP
MCP_DRIVE_PORT=3001          # Puerto del servidor (default: 3001)
MCP_DRIVE_HOST=0.0.0.0       # Host de escucha (0.0.0.0 para Docker)

# Configuración de Drives
DRIVES_CONFIG_PATH=./drives-config.json

# Nivel de logging (debug, info, warn, error)
LOG_LEVEL=info

# API key para autenticación de requests MCP (opcional)
MCP_API_KEY=tu_api_key_seguro

🛠️ Herramientas MCP

El servidor expone 7 herramientas vía protocolo MCP:

Gestión de Drives

`list_drives`

Lista todas las cuentas de Google Drive configuradas.

Parámetros: Ninguno

Respuesta:

[
  {
    "id": "personal",
    "name": "Drive Personal",
    "description": "Mi Drive personal"
  }
]

`add_drive`

Agrega una nueva cuenta de Google Drive a la configuración.

Parámetros:

driveId (string, requerido): ID único (ej: 'personal', 'work')
name (string, requerido): Nombre descriptivo
description (string, opcional): Descripción de la cuenta
serviceAccountPath (string, requerido): Ruta al archivo JSON de Service Account

Ejemplo:

{
  "driveId": "personal",
  "name": "Drive Personal",
  "description": "Mi cuenta personal",
  "serviceAccountPath": "./credentials/personal-sa.json"
}

`remove_drive`

Elimina una cuenta de Drive de la configuración.

Parámetros:

driveId (string, requerido): ID del Drive a eliminar

Operaciones de Archivos

`list_files`

Lista archivos de Google Drive con filtros opcionales.

Parámetros:

driveId (string, opcional): ID del Drive (usa el primero si se omite)
folderId (string, opcional): ID de carpeta específica
modifiedAfter (string, opcional): Fecha ISO 8601
modifiedBefore (string, opcional): Fecha ISO 8601
mimeType (string, opcional): Tipo MIME específico
pageSize (number, opcional): Límite de resultados (default: 100)

Respuesta:

{
  "totalFiles": 5,
  "files": [
    {
      "id": "1abc...",
      "name": "Documento.docx",
      "mimeType": "application/vnd.google-apps.document",
      "modifiedTime": "2024-10-16T10:30:00Z",
      "size": "12345",
      "webViewLink": "https://drive.google.com/...",
      "parents": ["0BwwA4oUTeiV1TGRPeTVjaWRDY1E"]
    }
  ]
}

`get_file_content`

Obtiene el contenido de un archivo de Google Drive.

Soporta:

Google Docs → exporta como texto plano
Google Sheets → exporta como CSV
Archivos de texto (.txt, .md) → descarga directa

Parámetros:

fileId (string, requerido): ID del archivo
driveId (string, opcional): ID del Drive

Respuesta:

{
  "fileId": "1abc...",
  "fileName": "Documento.txt",
  "mimeType": "text/plain",
  "content": "Contenido del archivo...",
  "extractedAt": "2024-10-16T10:30:00Z"
}

`search_files`

Busca archivos por nombre en un Drive específico.

Parámetros:

driveId (string, requerido): ID del Drive donde buscar
query (string, requerido): Texto a buscar en nombres de archivo

Respuesta:

{
  "totalFiles": 3,
  "files": [
    {
      "id": "1abc...",
      "name": "Presupuesto 2024.xlsx",
      "mimeType": "application/vnd.google-apps.spreadsheet",
      "modifiedTime": "2024-10-16T10:30:00Z",
      "webViewLink": "https://drive.google.com/..."
    }
  ]
}

`list_files_recursive` 🆕

Lista recursivamente todos los archivos y subcarpetas dentro de una carpeta con filtros opcionales por fecha y tipo, ideal para escaneos diarios de documentos modificados.

Parámetros:

folderId (string, requerido): ID de la carpeta raíz desde donde iniciar
driveId (string, opcional): ID del Drive (usa el primero si se omite)
maxDepth (number, opcional): Profundidad máxima de recursión (default: 10)
modifiedAfter (string, opcional): Filtrar archivos modificados después de esta fecha (formato RFC 3339: 2024-10-17T08:00:00 o 2024-10-17T08:00:00Z para UTC)
mimeType (string, opcional): Filtrar por tipo MIME específico (ej: application/vnd.google-apps.document para Google Docs, application/pdf para PDFs)

Respuesta:

{
  "totalItems": 42,
  "filters": {
    "modifiedAfter": "2024-10-17T08:00:00",
    "mimeType": "application/vnd.google-apps.document"
  },
  "items": [
    {
      "id": "1abc...",
      "name": "Reporte Mensual.docx",
      "mimeType": "application/vnd.google-apps.document",
      "modifiedTime": "2024-10-17T10:30:00Z",
      "size": "12345",
      "webViewLink": "https://drive.google.com/...",
      "parents": ["0BwwA4oUTeiV1TGRPeTVjaWRDY1E"],
      "depth": 0,
      "path": "/CONTABILIDAD/Reporte Mensual.docx"
    },
    {
      "id": "2def...",
      "name": "Presupuesto.docx",
      "mimeType": "application/vnd.google-apps.document",
      "modifiedTime": "2024-10-17T14:20:00Z",
      "size": "470883",
      "webViewLink": "https://drive.google.com/...",
      "parents": ["1abc..."],
      "depth": 2,
      "path": "/CONTABILIDAD/DOCUMENTOS/Presupuesto.docx"
    }
  ]
}

Características:

✅ Filtros opcionales: Por fecha de modificación y tipo MIME
✅ Exploración completa: Las carpetas siempre se recorren, filtros aplican solo a archivos
✅ Búsqueda recursiva: DFS (Depth-First Search) en toda la jerarquía
✅ Metadatos completos: ID, nombre, ruta completa, fecha, tipo, tamaño
✅ Campo depth: Nivel de anidación (0 = raíz)
✅ Campo path: Ruta completa desde carpeta inicial
✅ Protección: Límite maxDepth previene recursión infinita
✅ Optimizado: Doble query para carpetas + archivos filtrados
✅ Google Drive API: Límite de 1000 items por nivel

Caso de uso típico (escaneo diario):

// Obtener todos los Google Docs modificados hoy después de las 8 AM
const result = await client.callTool({
  name: "list_files_recursive",
  arguments: {
    folderId: "carpeta-raiz-id",
    modifiedAfter: "2024-10-17T08:00:00",
    mimeType: "application/vnd.google-apps.document",
    maxDepth: 5,
  },
});
// Resultado: Solo Docs modificados hoy, con rutas completas para procesamiento LLM

🌐 Endpoints HTTP

El servidor expone los siguientes endpoints:

Health Check

GET http://localhost:3001/health

# Respuesta
{
  "status": "healthy",
  "timestamp": "2024-10-16T10:30:00.000Z"
}

Conexión MCP (StreamableHTTP)

GET http://localhost:3001/mcp?apiKey=tu-api-key-aqui

# Establece conexión StreamableHTTP para comunicación MCP
# Autenticación vía query parameter (recomendado) o header X-API-Key

Nota sobre SSE: El transporte SSE (Server-Sent Events) está deprecado en MCP SDK v1.19+. Use StreamableHTTP.

🔌 Conectar desde Cliente

Opción 1: StreamableHTTP (Recomendado) 🆕

Transport moderno stateless para cualquier aplicación:

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";

// Conectar con autenticación por query parameter
const transport = new StreamableHTTPClientTransport(
  new URL("http://localhost:3001/mcp?apiKey=tu-api-key-aqui")
);

const client = new Client(
  {
    name: "my-app",
    version: "1.0.0",
  },
  {
    capabilities: {},
  }
);

await client.connect(transport);

// Listar herramientas disponibles (7 tools)
const tools = await client.listTools();
console.log(`Tools disponibles: ${tools.tools.length}`);

// Ejecutar herramienta
const result = await client.callTool({
  name: "list_drives",
  arguments: {},
});

console.log(result);

// Listar recursivamente una carpeta
const recursiveResult = await client.callTool({
  name: "list_files_recursive",
  arguments: {
    folderId: "1AdO2achPP4Kgz4AGmKw2C4wKF49Ce-KC",
    driveId: "comnet-manuales",
    maxDepth: 5,
  },
});

await client.close();

Opción 2: Cliente NestJS (Orquestador)

Recomendado para aplicaciones que necesitan múltiples MCPs:

// src/mcp/mcp.config.ts (NestJS)
import { registerAs } from "@nestjs/config";

export default registerAs("mcp", () => ({
  servers: {
    googleDrive: {
      name: "google-drive-local",
      transport: {
        type: "streamableHttp", // 🆕 Cambio de "sse" a "streamableHttp"
        // Desarrollo: http://localhost:3001/mcp?apiKey=...
        // Producción Docker: http://mcp-drive:3001/mcp?apiKey=...
        url:
          process.env.MCP_DRIVE_URL ||
          `http://localhost:3001/mcp?apiKey=${process.env.MCP_DRIVE_API_KEY}`,
      },
      timeout: 30000,
    },
  },
}));

// src/mcp/mcp.service.ts
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";

const transport = new StreamableHTTPClientTransport(
  new URL(config.transport.url)
);

await client.connect(transport);

📚 Ver guía completa: docs/NESTJS-CLIENT.md

Características del Cliente

✅ CORS habilitado: Funciona desde cualquier dominio
✅ API Key dual: Via query parameter ?apiKey=... (recomendado) o header X-API-Key
✅ Stateless: No mantiene sesiones, ideal para Docker/Kubernetes
✅ Multi-cliente: Múltiples clientes pueden conectarse simultáneamente
✅ Retry automático: SDK maneja reconexiones

🔒 Seguridad

Solo lectura: Service Account con scope drive.readonly
Autenticación opcional: Soporta API key via header X-API-Key
CORS configurado: Permite conexiones desde clientes externos
Validación robusta: Esquemas Zod para todos los inputs
Logging seguro: No expone credenciales en logs

Autenticación con API Key

1. Configurar API key en servidor:

# .env
MCP_API_KEY=tu_api_key_super_secreto_aqui

2. Enviar desde cliente:

// Opción 1: Query parameter (recomendado para StreamableHTTP)
const transport = new StreamableHTTPClientTransport(
  new URL("http://localhost:3001/mcp?apiKey=tu_api_key_super_secreto_aqui")
);

// Opción 2: Header (alternativa)
const transport = new StreamableHTTPClientTransport(
  new URL("http://localhost:3001/mcp"),
  {
    headers: {
      "X-API-Key": "tu_api_key_super_secreto_aqui",
    },
  }
);

3. Comportamiento:

✅ Si MCP_API_KEY NO está configurado → Acceso libre (desarrollo)
🔒 Si MCP_API_KEY está configurado → Requiere header X-API-Key

Seguridad en Producción (VPS)

⚠️ Importante: Este servidor usa HTTP sin cifrado. Para producción:

Reverse Proxy con SSL (nginx/traefik)
Firewall: Restringir acceso por IP
Rate Limiting: Prevenir abuso
API Key: Habilitar autenticación

Ejemplo nginx con SSL:

upstream mcp_drive {
    server localhost:3001;
}

server {
    listen 443 ssl http2;
    server_name mcp-drive.tudominio.com;

    ssl_certificate /etc/letsencrypt/live/tudominio.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tudominio.com/privkey.pem;

    # Solo permitir IP del orquestador
    allow 192.168.1.100;
    deny all;

    location / {
        proxy_pass http://mcp_drive;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-API-Key $http_x_api_key;  # Pasar API key
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 86400;
    }
}

CORS en Producción

Por defecto, CORS permite cualquier origen (*). Para producción, restringe dominios:

// src/index.ts
app.use((req, res, next) => {
  res.setHeader(
    "Access-Control-Allow-Origin",
    "https://tu-app.com" // Solo tu dominio
  );
  // ... resto
});

📊 Logging

El servidor genera logs estructurados en JSON:

Consola: Formato colorizado para desarrollo
error.log: Solo errores críticos
combined.log: Todos los niveles

Configurar nivel via LOG_LEVEL env variable.

🐳 Docker

Docker Compose (Recomendado)

# Levantar servicio
docker-compose up -d

# Ver logs en tiempo real
docker-compose logs -f

# Detener servicio
docker-compose down

# Reconstruir después de cambios
docker-compose up -d --build

Docker Manual

# Build
docker build -t mcp-drive-server .

# Run
docker run -d \
  --name mcp-drive \
  -p 3001:3000 \
  -e PORT=3000 \
  -e HOST=0.0.0.0 \
  -e LOG_LEVEL=info \
  -v $(pwd)/drives-config.json:/app/config/drives-config.json \
  -v $(pwd)/keys:/app/keys:ro \
  -v $(pwd)/logs:/app/logs \
  mcp-drive-server

# Ver logs
docker logs -f mcp-drive

Múltiples Instancias en VPS

# Instancia 1 - Drive Personal (puerto 3001)
docker run -d --name mcp-drive-personal \
  -p 3001:3000 \
  -v $(pwd)/config-personal:/app/config \
  mcp-drive-server

# Instancia 2 - Drive Trabajo (puerto 3002)
docker run -d --name mcp-drive-work \
  -p 3002:3000 \
  -v $(pwd)/config-work:/app/config \
  mcp-drive-server

🧪 Desarrollo y Testing

# Desarrollo local con hot reload
pnpm dev
# Servidor en http://localhost:3001

# Linting con oxlint (ultrarrápido)
pnpm lint
pnpm lint:fix

# Formateo con Prettier
pnpm format
pnpm format:check

# Verificación completa (lint + format)
pnpm check

# Build para producción
pnpm build

# Ejecutar versión compilada
pnpm start

# Tests
pnpm test:client      # Test de conexión y tools básicas
pnpm test:recursive   # Test de listado recursivo
pnpm test:drive       # Test de Google Drive API
pnpm test:all         # Ejecutar todos los tests

# Ver logs de Docker
docker-compose logs -f

# Reiniciar contenedor
docker-compose restart

# Reconstruir imagen
docker-compose up -d --build

Tests Disponibles

El proyecto incluye 3 tests completos en la carpeta tests/:

test-mcp-client.ts: Conexión general y herramientas básicas
test-recursive.ts: Validación de listado recursivo (166 items en estructura COMNET)
test-drive.ts: Pruebas directas con Google Drive API

📚 Ver documentación completa: tests/README.md

📊 Monitoreo

# Health check
curl http://localhost:3001/health

# Test de conexión MCP
pnpm test:client

# Logs en tiempo real
docker-compose logs -f mcp-drive

# Stats de recursos
docker stats mcp-drive

# Inspeccionar contenedor
docker inspect mcp-drive

🏗️ Arquitectura Técnica

Transport Layer

StreamableHTTP: Transport moderno stateless (HTTP-based)
Deprecado: SSE (Server-Sent Events) - removido en v2.0.0
Ventajas: Sin estado, escalable, compatible con proxies/load balancers

MCP SDK

Version: 1.19.1
API: McpServer high-level (reemplaza Server low-level)
Validación: Zod schemas automáticos en inputSchema/outputSchema
Registro: server.registerTool(name, config, handler)

Herramientas Modularizadas

// src/mcp/tools/list-drives.ts
export const listDrivesTool = {
  name: "list_drives",
  config: { title, description, inputSchema, outputSchema },
  handler: async (params) => {
    /* ... */
  },
};

// src/mcp/server.ts (33 líneas)
const toolList = Object.values(tools);
toolList.forEach((tool) => {
  server.registerTool(tool.name, tool.config, tool.handler);
});

Path Aliases

// tsconfig.json
"baseUrl": ".",
"paths": {
  "@/*": ["src/*"]
}

// En código
import { logger } from "@/utils/logger.js";
import { googleDriveService } from "@/services/drive-service.js";

Nota: Los imports usan extensión .js aunque los archivos sean .ts (requisito de TypeScript ESM con "module": "NodeNext")

📝 Tipos MIME Soportados

Google Workspace

application/vnd.google-apps.document - Google Docs
application/vnd.google-apps.spreadsheet - Google Sheets
application/vnd.google-apps.presentation - Google Slides

Archivos de Texto

text/plain - Texto plano
text/markdown - Markdown

Formatos de Exportación

text/plain - Docs exportados
text/csv - Sheets exportados

🤝 Contribuir

Fork el repositorio
Crea una rama para tu feature (git checkout -b feature/amazing-feature)
Commit tus cambios (git commit -m 'Add amazing feature')
Push a la rama (git push origin feature/amazing-feature)
Abre un Pull Request

📄 Licencia

Este proyecto está bajo licencia MIT.

🆘 Troubleshooting

Servidor no inicia

# Verificar que el puerto no esté en uso
netstat -ano | findstr :3000  # Windows
lsof -i :3000                 # Linux/Mac

# Cambiar puerto si está ocupado
PORT=3001 pnpm dev

Error: "Service account file not found"

Verifica que el archivo JSON existe en la ruta especificada
En Docker, asegúrate de montar el volumen correctamente:
```
-v $(pwd)/keys:/app/keys:ro
```

Error: "Unauthorized: Invalid API key"

Verifica que MCP_API_KEY esté configurado en el servidor
El API key debe enviarse en el header X-API-Key (no en _meta.apiKey)
Formato correcto:
```
headers: { "X-API-Key": "tu-api-key" }
```

No se pueden leer archivos

Verifica que el Service Account tenga acceso (compartido con su email)
Confirma que el scope sea drive.readonly
Revisa permisos de la carpeta/archivo en Drive

Cliente no puede conectar (VPS)

# Verificar que el puerto esté expuesto
docker ps | grep mcp-drive

# Verificar firewall
sudo ufw status
sudo ufw allow 3001/tcp

# Test de conectividad
curl http://vps-ip:3001/health

Logs no aparecen

Configura LOG_LEVEL=debug para ver más detalles
Verifica permisos de escritura en la carpeta del proyecto
En Docker: docker-compose logs -f mcp-drive

Alto uso de memoria

Ajusta límites en docker-compose.yml:

deploy:
  resources:
    limits:
      memory: 256M

Available Tools

6 tools

add_driveC

Add a new Google Drive account to the configuration

ParametersJSON Schema

Name	Required	Description
`description`	No	Optional description
`driveId`	Yes	Unique ID for this drive (e.g., 'personal', 'work')
`name`	Yes	Display name for the drive
`serviceAccountPath`	Yes	Path to Service Account JSON file (e.g., './credentials/personal-sa.json')

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Add' implies a write/mutation operation but doesn't cover critical aspects like whether this requires admin permissions, if it's idempotent, what happens on duplicate driveId, or error handling. For a configuration tool with zero annotation coverage, this leaves significant gaps in understanding its 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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.

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 complexity of adding a Google Drive account (involving authentication via service accounts) and the absence of both annotations and an output schema, the description is insufficient. It doesn't explain what 'configuration' means, what the tool returns (e.g., success confirmation or error), or how it integrates with sibling tools. For a mutation tool with no structured support, more context is needed.

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 input schema fully documents all parameters (driveId, name, serviceAccountPath, description). The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when the schema does all the work.

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 ('Add') and resource ('new Google Drive account to the configuration'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_drives' or 'remove_drive', which would require mentioning it's for configuration setup rather than data operations.

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 like 'list_drives' for viewing existing drives or 'remove_drive' for deletion. The description lacks context about prerequisites (e.g., needing a service account file) or typical scenarios (e.g., initial setup vs. adding multiple drives).

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

get_file_contentC

Get content from a Google Drive file (Docs, Sheets, TXT, MD)

ParametersJSON Schema

Name	Required	Description	Default
`driveId`	No
`fileId`	Yes

TDQS

C2.7/5.0

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 mentions the action ('Get content') and supported file types, but lacks critical details such as authentication requirements, rate limits, error handling (e.g., for unsupported formats), or what the output looks like (e.g., raw text, structured data). For a read operation with no annotation coverage, 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, efficient sentence that front-loads the core purpose ('Get content from a Google Drive file') and adds specific details (file types). There's no wasted verbiage, making it appropriately concise for the tool's complexity.

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 (2 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and file types but misses essential context: parameter explanations, behavioral traits (e.g., read-only nature, potential errors), and output details. Without annotations or output schema, the description should do more to guide the agent.

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 for undocumented parameters. It doesn't explain the meaning or usage of 'driveId' and 'fileId' parameters (e.g., how to obtain them, their format, or that 'driveId' is optional). The mention of file types implies some parameter context but doesn't directly address the input schema, leaving key semantics unclear.

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 verb ('Get content') and resource ('from a Google Drive file'), making the purpose understandable. It also specifies supported file types (Docs, Sheets, TXT, MD), which adds useful detail. However, it doesn't explicitly differentiate from sibling tools like 'list_files' or 'search_files', which might also involve file content access.

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 doesn't mention prerequisites (e.g., needing file permissions), exclusions (e.g., unsupported file types beyond those listed), or comparisons to siblings like 'search_files' for content-based queries. This leaves the agent with minimal context for tool selection.

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

list_drivesB

List all configured Google Drive accounts

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

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 states it lists drives but doesn't cover aspects like authentication requirements, rate limits, pagination, or what 'configured' entails. This leaves significant gaps for a tool that likely interacts with external services.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured.

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 has 0 parameters and no output schema, the description is minimally adequate but incomplete. It lacks details on behavioral aspects like authentication or return format, which are important for a tool listing external resources. The absence of annotations increases the need for more context.

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 tool has 0 parameters, and the schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could slightly clarify the scope of 'configured' (e.g., user-specific vs. system-wide).

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 verb ('List') and resource ('Google Drive accounts') with the scope modifier 'all configured', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_files' or 'search_files', which might also involve listing operations.

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 like 'list_files' or 'search_files', nor does it mention prerequisites such as needing configured drives first. It lacks explicit context or exclusions, leaving usage ambiguous.

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

list_filesC

List files from Google Drive with optional filters (driveId, folderId, modifiedAfter/Before, mimeType)

ParametersJSON Schema

Name	Required	Description	Default
`driveId`	No
`folderId`	No
`mimeType`	No
`modifiedAfter`	No
`modifiedBefore`	No
`pageSize`	No

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions optional filters but doesn't describe key behaviors: whether this is a read-only operation, how pagination works (though 'pageSize' is in schema), what the return format looks like, or any rate limits/permissions needed. For a tool with 6 parameters and no annotations, this leaves significant gaps in understanding its 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, efficient sentence that front-loads the core purpose ('List files from Google Drive') and then enumerates optional filters. There is zero wasted language, and every word contributes directly to understanding the tool's functionality.

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 6 parameters with 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, pagination behavior, error conditions, or how filters interact. For a listing tool with multiple filters, more context is needed to use it effectively.

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 description lists 5 of the 6 parameters (driveId, folderId, mimeType, modifiedAfter/Before) as optional filters, adding meaning beyond the schema which has 0% description coverage. However, it omits 'pageSize' entirely, and doesn't explain parameter formats (e.g., date format for modifiedAfter) or relationships between parameters. With low schema coverage, it partially compensates but not fully.

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 verb 'List' and resource 'files from Google Drive', making the purpose unambiguous. It distinguishes from siblings like 'search_files' by specifying it's a listing operation rather than a search, though it doesn't explicitly contrast them. The description avoids tautology by not just repeating the name.

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 like 'search_files' or 'list_drives'. It mentions optional filters but doesn't explain scenarios where filtering is appropriate or when other tools might be better suited. There are no explicit when/when-not instructions or named alternatives.

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

remove_driveC

Remove a Google Drive account from the configuration

ParametersJSON Schema

Name	Required	Description	Default
`driveId`	Yes	ID of the drive to remove

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if removal is destructive, reversible, requires specific permissions, affects associated data, or has side effects like rate limits, which is inadequate 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, direct sentence with zero wasted words, front-loading the core action and resource. It's appropriately sized for a simple tool, making it easy to parse quickly.

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 a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context like what 'remove' entails (e.g., permanent deletion, configuration update), success/failure behavior, or error handling, leaving significant gaps for agent 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?

Schema description coverage is 100%, so the schema already documents the 'driveId' parameter fully. The description adds no additional meaning beyond implying the parameter identifies the drive to remove, meeting the baseline for high schema coverage without extra value.

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') and resource ('Google Drive account from the configuration'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_drive' beyond the obvious verb contrast, missing explicit scope or relationship context.

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 prerequisites (e.g., needing an existing drive), exclusions, or how it relates to siblings like 'list_drives' for selection or 'add_drive' for reversal, leaving usage context implied at best.

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

search_filesC

Search files by name in a Google Drive

ParametersJSON Schema

Name	Required	Description	Default
`driveId`	Yes
`query`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'search' implies a read-only operation, it doesn't specify whether this requires authentication, what happens with no results, whether there are rate limits, or how results are returned. The description mentions the scope ('in a Google Drive') but lacks other critical behavioral context for a tool with no annotation coverage.

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, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a basic search tool and gets straight to the point with no wasted language.

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 a search tool with 2 required parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how results are structured, whether there are limitations on search scope, or how to interpret the parameters. The description provides only basic purpose information without the necessary context for effective tool 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?

With 0% schema description coverage for both parameters, the description provides no information about what 'driveId' and 'query' represent, their formats, or constraints. The description mentions 'search files by name' which hints that 'query' might be a filename search, but doesn't clarify if it supports partial matches, wildcards, or other search operators. This doesn't adequately compensate for the complete lack of schema documentation.

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 ('search files by name') and resource ('in a Google Drive'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'list_files', but the 'search by name' specification provides some differentiation from a generic listing operation.

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 like 'list_files' or 'get_file_content'. It doesn't mention prerequisites, limitations, or specific scenarios where this search function is appropriate versus other file-related operations.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv1.0.0Oct 16, 2025
- First observedadd_drive
- First observedget_file_content
- First observedlist_drives
- First observedlist_files
- First observedremove_drive
- First observedsearch_files

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Scored 2026-04-18 08:25 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no ambiguity: account management (add_drive, list_drives, remove_drive), file listing (list_files), file searching (search_files), and content retrieval (get_file_content). The descriptions reinforce these distinct roles, making tool selection straightforward for an agent.

Naming Consistency5/5

All tools follow a consistent verb_noun naming pattern with snake_case throughout (e.g., add_drive, get_file_content, list_drives). This predictability enhances usability and reduces cognitive load when scanning the toolset.

Tool Count5/5

With 6 tools, this server is well-scoped for Google Drive operations, covering account configuration, file listing, searching, and content access. Each tool earns its place without bloat, aligning with typical MCP server sizes of 3-15 tools.

Completeness3/5

The toolset covers basic read and configuration operations well but has notable gaps in file lifecycle management. There are no tools for creating, updating, deleting, or moving files, which limits agents from performing full CRUD workflows in Google Drive.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

google-workspaceOAuth
com.proscendia
Permissioned access to Gmail, Drive and Calendar via the user's own Google account
Email Cloud Storage Calendar Management
1
ShareWatch AOAuth
ai.sharewatch
Give Claude only the Google Drive files you choose. Every action logged.
Cloud Storage File Systems Workplace & Productivity
251
Grounders MCPOAuth
io.github.ItsBreeze
Multiple Google accounts (Gmail, Calendar, Drive, Contacts, Tasks) in one Claude connector.
Email Calendar Management Cloud Storage
1
developer-tools A
goog.workspace-developer
Provides tools for searching Google Workspace documentation and much more.
Developer Tools Documentation Access Search
22

Related MCP Servers

Google Drive MCP Server
Cloud Storage File Systems Developer Tools
felores
A
license
Not graded
quality
D
maintenance
Enables integration with Google Drive for listing, reading, and searching over files, supporting various file types with automatic export for Google Workspace files.
Updated 10 months ago (2025-11-07 11:04 UTC)
3,241
72
MIT
Google Drive MCP Server
Cloud Storage File Systems
w-jeon
A
license
Not graded
quality
D
maintenance
Integrates with Google Drive to enable listing, reading, and searching over files, with automatic export of Google Workspace documents to appropriate formats.
Updated a year ago (2025-03-12 04:07 UTC)
3,241
MIT
Google Drive MCP Server
Cloud Storage File Systems
matty-v
A
license
Not graded
quality
D
maintenance
Enables searching, retrieving, and managing files in Google Drive using a service account. Supports file search with query syntax, metadata retrieval, folder operations, file moving, and folder creation.
Updated 8 months ago (2026-01-10 22:00 UTC)
238
MIT
Google Workspace MCP
Workplace & Productivity Content Management Systems File Systems
NgoQuocViet2001
F
license
B
quality
D
maintenance
Enables reading and extracting structured data from Google Docs and Sheets, including text, tables, formulas, and images. It supports advanced image handling and multiple authentication methods for interacting with private and public workspace files.
Updated 5 months ago (2026-04-09 03:23 UTC)
11
3
-

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/andresfrei/mcp-google-drive-server'

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

Google Drive MCP Server

🎯 Características

📁 Estructura del Proyecto

🚀 Instalación y Deployment

Desarrollo Local

Producción con Docker

VPS con Múltiples MCPs

⚙️ Configuración

1. Service Account de Google

2. Archivo de Configuración

3. Variables de Entorno

🛠️ Herramientas MCP

Gestión de Drives

list_drives

add_drive

remove_drive

Operaciones de Archivos

list_files

get_file_content

search_files

list_files_recursive 🆕

🌐 Endpoints HTTP

Health Check

Conexión MCP (StreamableHTTP)

🔌 Conectar desde Cliente

Opción 1: StreamableHTTP (Recomendado) 🆕

Opción 2: Cliente NestJS (Orquestador)

Características del Cliente

🔒 Seguridad

Autenticación con API Key

Seguridad en Producción (VPS)

CORS en Producción

📊 Logging

🐳 Docker

Docker Compose (Recomendado)

Docker Manual

Múltiples Instancias en VPS

🧪 Desarrollo y Testing

Tests Disponibles

📊 Monitoreo

🏗️ Arquitectura Técnica

Transport Layer

MCP SDK

Herramientas Modularizadas

Path Aliases

📝 Tipos MIME Soportados

Google Workspace

Archivos de Texto

Formatos de Exportación

🤝 Contribuir

📄 Licencia

🆘 Troubleshooting

Servidor no inicia

Error: "Service account file not found"

Error: "Unauthorized: Invalid API key"

No se pueden leer archivos

Cliente no puede conectar (VPS)

Logs no aparecen

Alto uso de memoria

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`list_drives`

`add_drive`

`remove_drive`

`list_files`

`get_file_content`

`search_files`

`list_files_recursive` 🆕