Skip to main content
Glama

driveactivity query activity

driveactivity_query_activity
Read-onlyIdempotent

Query Drive activity newest first for one file, a folder's contents, or the entire Drive; filter by time/action and consolidate related changes.

Instructions

Query Drive activity, newest first, for one file (item_id), everything under a folder (folder_id), or the whole Drive (neither).

filter uses the Drive Activity syntax, for example 'time >= "2026-10-01T00:00:00Z" AND detail.action_detail_case:(EDIT RENAME)'. consolidate=true groups related actions.

Input Schema

NameRequiredDescriptionDefault
filterNo
item_idNo
folder_idNo
page_tokenNo
consolidateNo
max_resultsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, open-world and non-destructive, so the safety bar is covered. The description adds real behavior beyond that: results arrive newest first, the filter uses Drive Activity syntax, and consolidate=true groups related actions. It omits pagination behavior for page_token/max_results, which keeps it from a 5.

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?

Three short blocks, front-loaded with purpose and scope, then filter syntax, then the consolidate flag. The inline example is long but earns its place by demonstrating the syntax an agent cannot infer from a bare string parameter.

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?

An output schema exists, so return values need not be described. However, for a paged query endpoint the absence of any statement about pagination, ordering across pages, or result limits leaves a meaningful operational gap for an agent that must call it repeatedly.

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 0%, so the description must carry parameter meaning. It does well for filter (syntax plus a concrete example), item_id, folder_id and consolidate, but page_token and max_results (default 25) get no guidance at all, leaving a pagination gap in a query tool.

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 and resource ('Query Drive activity') plus the exact three scoping modes keyed to parameter names (item_id, folder_id, neither). An agent can distinguish this from drive_search_files or drive_get_file immediately, since this returns activity history rather than file content.

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?

Explicitly tells the agent which parameter selects which scope, which is the primary selection decision for this tool. It does not name alternative sibling tools or state when-not to use activity history versus a file listing, so it falls short of a 5.

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