QuestionPunk

Responses Export

responses_export

Read-onlyIdempotent

Get download links for a survey's responses as a spreadsheet: csvUrl and xlsxUrl (Excel). format 'wide' is one row per response; 'flat' is one row per answer. Give the user the link they need as a clickable absolute link: it downloads in a browser signed in to QuestionPunk (or with the connection's Bearer token), and is not a public share link. To analyze responses yourself, read them with responses_read instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "surveyId": "<surveyId>"
    },
    "name": "responses_export"
  }
}

Input Schema

Name	Required	Description
`format`	No	'wide' (default): one row per response; 'flat': one row per answer
`status`	No	completed, abandoned (left before the end) or in_progress. Omit for all.
`dateEnd`	No	Only responses started at/before this time, as Unix milliseconds (13 digits)
`surveyId`	Yes	Survey ID (from survey_list)
`timezone`	No	IANA timezone for dates in the file, e.g. "America/New_York"
`dateStart`	No	Only responses started at/after this time, as Unix milliseconds (13 digits; 2025-01-01T00:00Z is 1735689600000)
`answerFormat`	No	Choice answers as labels (default), 1-based numbers, or both
`responseType`	No	Real respondents or synthetic (AI) responses. Omit for both.
`suspiciousLevel`	No	Fraud-check filter. 'clean' excludes suspicious responses; 'flagged' is high + medium.
`surveyRevisionId`	No	Only responses collected on this published revision

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, yet the description adds genuinely non-obvious context: the link requires a browser session signed in to QuestionPunk or the connection's Bearer token, and is not a public share link. That auth-gated, non-shareable nature is the kind of detail an agent could otherwise miscommunicate to a user. It stops short of mentioning link expiry or rate limits, so not a full 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?

Roughly four sentences, all front-loaded: what it returns, what the formats mean, how to hand the link to the user, and which sibling to use instead. Every sentence carries distinct information, with no restatement of the tool name or filler.

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 present, the description needn't enumerate return values, and annotations already cover the safety profile. What remains — usage routing, the auth/non-public nature of the link, and format meaning — is all present, so an agent has everything needed to call it and to explain the result to a user.

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% and five parameters carry enums with their own descriptions, so the schema does the heavy lifting; the description's restatement of wide vs flat adds little beyond it. However, it does clarify the practical consequence of format choice (one row per response vs one row per answer) in usage terms, which slightly exceeds the schema wording. Baseline-plus 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?

States a specific verb and resource — get download links for a survey's responses as a spreadsheet — and names the concrete return fields (csvUrl, xlsxUrl). It also distinguishes itself from the closest sibling, responses_read, so an agent can route correctly without opening either schema.

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?

Explicitly gives the alternative and the condition that selects it: 'To analyze responses yourself, read them with responses_read instead.' It also implies when this tool applies (user wants a file/download) versus when in-tool reading applies, leaving nothing to inference.

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

All QuestionPunk tools Inspect

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

Need Help?