Skip to main content
Glama

Search Files

search_files
Read-onlyIdempotent

Search for files by name, text content, type, or date range. Use this instead of list_files when the user has many files or is looking for something specific. Use content when the user remembers what a file says but not what it is called. All parameters are optional — combine them to narrow results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoFilter by file type. One of: document, spreadsheet, presentation, pdf, folder. Matched case-insensitively; any other value is REJECTED with an error rather than ignored, so a filter you set is always a filter that applied.
queryNoSearch by file name (partial match). Example: 'board deck' or 'Q3 financials'
contentNoSearch inside file text, not just names — finds files whose body contains these words, scoped to files ShareWatch can see. Word-based, not substring: 'quarterly revenue' matches files containing those words. Combine with query to require both.
modified_afterNoOnly files modified after this date (ISO 8601 e.g. '2026-01-01')
modified_beforeNoOnly files modified before this date (ISO 8601 e.g. '2026-04-01')

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYes
guidanceNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by noting all parameters are optional and can be combined to narrow results. It does not disclose behavior like pagination or result limits, but those are largely optional given the strong annotation coverage and 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 three sentences with no wasted words. It front-loads the core function, then provides usage guidance and parameter semantics. Every sentence earns its place.

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 available, all parameters documented at 100% coverage, and descriptions covering alternatives and use cases, nothing critical is missing. The tool is simple and the description plus schema fully equip 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?

Schema description coverage is 100%, so the schema fully documents each parameter's meaning and constraints. The description adds the useful general note that all parameters are optional and combinable, but it does not go beyond the schema for individual parameter semantics. Baseline 3 is appropriate.

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 ('files'), and enumerates search dimensions: name, text content, type, and date range. It explicitly differentiates from sibling list_files by positioning search_files as the tool to use when looking for something specific. This is clear and unambiguous.

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?

It explicitly says to use this tool instead of list_files when the user has many files or is looking for something specific. It also guides on choosing the content parameter when the user remembers content but not the name. This gives clear when-to-use and alternative-selection guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools target a distinct resource and action, and the detailed descriptions separate similar-sounding ones. A few pairs could still be confused: access_file_by_url vs request_file_access, and create_document vs format_document, but their trigger conditions are described clearly enough to avoid frequent misselection.

Naming Consistency4/5

The set mostly follows a verb_noun pattern with consistent snake_case, e.g. create_document, update_spreadsheet, delete_file. Minor deviations like build_presentation instead of create_presentation, and format_document alongside create_document, break the pattern slightly but remain readable and predictable.

Tool Count3/5

25 tools is at the heavy end of the scale, though the domain spans Drive, Docs, Sheets, and Slides, which justifies a large surface. Some consolidation is possible — access_file_by_url and request_file_access overlap, as do create_document and format_document — so the count feels slightly bloated rather than tightly scoped.

Completeness4/5

The server covers the core file lifecycle well: create, read, update, delete, move, list, search, upload, and access control across all major Google Workspace document types. Minor gaps exist, such as no rename, copy, export, or direct sharing tool, but agents can work around these without major failures.

Resources