Skip to main content
Glama
Sign In

AccountHub

by ai.accounthub
OverviewDiscussionsAdmin

search_drive_files

Read-only

Search the user's Google Drive (read-only, metadata only) across all connected Google accounts and return reference links — file name, type, modified time, and webViewLink. No file contents are read. text keywords match file names AND full text; set name_only=true to match names only; filter by mime_type (aliases: folder/document/spreadsheet/presentation/pdf) and modified_after (ISO 8601). Advanced: pass raw_query to run a native Drive q expression instead. Results include shared drives and files shared with the user, sorted by modifiedTime desc, limit per account (default 10, max 50). Accounts without the Drive scope are skipped and reported in errors with a reconnect hint. Call list_accounts to learn account labels. Each call fetches ONE page only — it never walks pages automatically. A next_page_token in the response means more results exist; fetch the next page yourself by passing it back as page_token together with the SAME single accounts: [label] (paging only works narrowed to exactly one account — a cross-account search never returns a page token).

Input Schema

NameRequiredDescriptionDefault
textNoKeywords (space-separated, AND) matched against file names and full text.
limitNoMax files PER account (default 10).
accountsNoAccount labels to search (see list_accounts). Omit for all Drive-enabled Google accounts.
mime_typeNoExact mimeType, or alias: folder / document / spreadsheet / presentation / pdf.
name_onlyNotrue = match file names only (skip fullText).
raw_queryNoAdvanced: native Drive `q` expression — overrides the structured fields above.
page_tokenNoContinue from a previous call's next_page_token to fetch the next page. Only valid when `accounts` names exactly ONE account — narrow to a single account to page through its results; cross-account searches are always single-page. Never fetch pages automatically in a loop — the caller decides whether another page is needed.
modified_afterNoOnly files modified after this instant (ISO 8601).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare only readOnlyHint=true, so the description carries most of the behavioral burden and does so well: no contents are read, limit is per-account, shared drives/files are included, results are sorted by modifiedTime desc, scope-less accounts are skipped and reported in errors, and it never auto-paginates. It stops short of describing rate limits or error shapes in detail, but is far richer than the annotation.

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?

Front-loaded with purpose and scope, then progressively deeper detail. It is long and dense but nearly every clause carries actionable information; only the final paging explanation is slightly repetitive.

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 no output schema, the description compensates by naming returned fields (name, type, modified time, webViewLink), describing sort order, next_page_token semantics, and error reporting. An agent has everything needed to invoke and page 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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: mime_type aliases, limit default/max and per-account semantics, and the critical page_token constraint that paging only works with a single-account scope. The overall search semantics (AND of keywords, text matches names AND full text) also add 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?

States a specific verb (search) and resource (Google Drive files) plus explicit scope: read-only, metadata only, across all connected accounts. This clearly distinguishes it from siblings like read_file_content, download_file_content, and get_file_metadata.

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?

Names the alternative paths explicitly: set name_only=true for name-only matching, use raw_query for native Drive expressions, call list_accounts to learn labels, and only page when narrowed to a single account. It states both when to use structured fields and when raw_query overrides them.

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

All AccountHub toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources