drive-mcp

Overview Schema Source Related Servers Discussions Admin

search_files

Search Google Drive files by name, content, type, folder, or modification date. Returns metadata only; use read_file_content or download_file for file contents.

Instructions

Search Drive by name, full text, type, folder and modification date. All constraints are ANDed. Returns metadata only; use read_file_content or download_file for contents. Trashed files are excluded unless includeTrashed is true.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_files"
  }
}

Input Schema

Name	Required	Description
`name`	No	Substring of the file name (case-insensitive).
`type`	No	Friendly type filter.
`orderBy`	No	e.g. "modifiedTime desc" (default), "name", "createdTime desc", "viewedByMeTime desc".
`folderId`	No	Only direct children of this folder. "root" is My Drive.
`fullText`	No	Words that must appear in the content, title or description.
`mimeType`	No	Exact MIME type filter, for when `type` is not specific enough.
`ownedByMe`	No	Only files the account owns.
`pageToken`	No	From a previous result to fetch the next page.
`maxResults`	No	Default 25, max 100.
`modifiedAfter`	No	RFC 3339 timestamp; only files modified after it.
`includeTrashed`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations present the description carries the full burden, and it does disclose meaningful behavioral traits: results are metadata only, filters are ANDed (not ORed), and trashed files are excluded unless includeTrashed is true. It omits permission/auth requirements and pagination mechanics beyond the schema's pageToken, which keeps it short of a 5 for an annotation-free 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?

Three sentences, each doing distinct work: capability statement, filter-combination rule, and result-scope/routing note. The most decision-relevant information is front-loaded and there is no filler.

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 an 11-parameter, no-required-args search tool with no output schema, the description covers what is returned (metadata only) and the key default behavior (trash exclusion), which is enough to call it correctly. It leaves pagination and ordering expectations to the schema, which is acceptable but not fully self-contained.

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 91%, so the baseline is 3, but the description adds genuine semantics the schema lacks: the AND-combination rule across all constraints, and the meaning of includeTrashed (which has no schema description at all). It still doesn't elaborate on ordering defaults or page token usage beyond the schema text.

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 (Search) and resource (Drive files) and enumerates the filter axes (name, full text, type, folder, modification date) in the first sentence. It also names the sibling tools (read_file_content, download_file) that handle the content-retrieval use case this tool deliberately does not cover, so the agent can distinguish it from neighbors without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear routing guidance: use read_file_content or download_file when you need file contents rather than metadata, and it explains that filters combine with AND. It does not address when to prefer list_folder, list_recent_files, or get_file_metadata over this tool, so the sibling boundaries are only partially drawn.

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

Deploy Server