Skip to main content
Glama
r28ai

Chief of Staff

by r28ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

gforms_forms_responses_list

Read-onlyIdempotent

List Google Form submitted responses newest first, with optional timestamp filter and pagination up to 5000 per page. Use it to read responses arriving since a specific time.

Instructions

List a form's submitted responses, newest page first, up to 5000 per page. The only supported filter is on submission time: pass filter='timestamp >= 2026-01-01T00:00:00Z' to read what has arrived since a point in time. Answers come back keyed by questionId.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNoWhich form responses to return. Currently, the only supported filters are: `timestamp > N` which means to get all form responses submitted after (but not at) timestamp N, and `timestamp >= N` which means to get all form responses submitted at and after timestamp N. For both supported filters, timestamp must be formatted in RFC3339 UTC "Zulu" format. Examples: "2014-10-02T15:01:23Z" and "2014-10-02T15:01:23.045123456Z". The whole filter is one string, operator included: 'timestamp >= 2014-10-02T15:01:23Z'. There is no other filterable field — a question, an email or a score cannot be filtered here.
formIdYesRequired. ID of the Form whose responses to list.
pageSizeNoThe maximum number of responses to return. The service may return fewer than this value. If unspecified or zero, at most 5000 responses are returned.
pageTokenNoA page token returned by a previous list response. If this field is set, the form and the values of the filter must be the same as for the original request.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds behavior the annotations do not: newest-first ordering, the 5000-per-page ceiling, and that answers are keyed by questionId. It omits pagination semantics (that pageToken must repeat the same filter), which keeps it short of 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the resource and ordering, then the filter rule, then the return shape. Every sentence carries information an agent needs and nothing is padded.

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?

There is no output schema, and the description partially compensates by noting answers are keyed by questionId, plus it gives ordering and page limits. It stops short of describing the response envelope (e.g. nextPageToken, responseId) or how to continue paging, which is the remaining gap for a paginated list tool.

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 all four parameters including the full filter grammar, RFC3339 format and the pageToken consistency rule. The description's filter example and questionId note mostly restate that, so the baseline 3 applies.

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 ('List a form's submitted responses') plus ordering ('newest page first') and a hard cap ('up to 5000 per page'). No other Google Forms tool exists among the siblings, so there is nothing to disambiguate against, and the purpose is unambiguous on its own.

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?

Explains the operative constraint clearly: the only supported filter is on submission time, with a worked example that shows what the filter buys you ('read what has arrived since a point in time'). It does not state when *not* to use it or how pagination resumes, but for a single-purpose list tool the context given is adequate.

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

Deploy Server

Other Tools