Skip to main content
Glama
debanjanbasu

grr

by debanjanbasu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

forms.forms.responses.get

Retrieves a single form response by form ID and response ID, returning its details as JSON for inspection or processing.

Instructions

Get one response from the form [HTTP GET]. Returns the requested resource as JSON — request bodies are built from the typed parameters (typed flags win over the params map), or read whole from body_file Siblings over the same resource: list.

Input Schema

NameRequiredDescriptionDefault
queryNoExtra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
formIdYes[URL path segment] Required. The form ID.
paramsNoParameter map merged into the request; typed parameters win.
dry_runNoReturn the request that would be sent, without sending it.
body_fileNoRead the request body from this file ('-' for stdin) instead of building one from the parameters.
responseIdYes[URL path segment] Required. The response ID within the form.

Output Schema

NameRequiredDescriptionDefault
formIdNo
answersNo
createTimeNo
responseIdNo
totalScoreNo
respondentEmailNo
lastSubmittedTimeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / formId / description
      Previous value: -"Required. The form ID."New value: +"[URL path segment] Required. The form ID."
    • changedInput schema / properties / responseId / description
      Previous value: -"Required. The response ID within the form."New value: +"[URL path segment] Required. The response ID within the form."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "answers": {
+      "type": "object"
+    },
+    "createTime": {
+      "type": "string"
+    },
+    "formId": {
+      "type": "string"
+    },
+    "lastSubmittedTime": {
+      "type": "string"
+    },
+    "respondentEmail": {
+      "type": "string"
+    },
+    "responseId": {
+      "type": "string"
+    },
+    "totalScore": {
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
  2. First observed

TDQS

B3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden, yet it spends most of its text on request-body construction ('typed flags win over the params map', 'read whole from body_file') that is meaningless for an HTTP GET with two path parameters. It does confirm [HTTP GET] and JSON return, but discloses nothing about permissions, missing-response errors, or whether submissions are redacted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The purpose is front-loaded in the first clause, but the majority of the remaining words are generic transport boilerplate about request bodies that does not apply to this read operation. Roughly two-thirds of the description does not earn its place for this specific tool.

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 explained, and all six parameters are documented in the schema. However, the description offers no error semantics or auth context for a read that can fail on a bad responseId, and the body-building text adds noise rather than completeness.

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 formId, responseId, query, params, dry_run, and body_file. The description re-explains the params/typed-parameter precedence and body_file behavior, which duplicates schema text rather than adding new meaning (e.g., what query keys the responses endpoint accepts). Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause names a specific verb and resource: 'Get one response from the form.' That is enough to distinguish it from forms.forms.responses.list, which is also named as the sibling over the same resource. It stops short of a 5 because the sibling is only listed, not contrasted by scope.

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

Usage Guidelines3/5

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

The phrase 'Siblings over the same resource: list' signals that an alternative exists, but it never states the condition that selects one over the other (single response by ID vs. enumerate all responses in a form). Usage is implied by the required formId/responseId path params rather than described.

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