QuestionPunk

Report Get

report_get

Read-onlyIdempotent

Read a survey's aggregated results: answer distributions and statistics per question. Use it for "what did people answer" summaries; for one question broken down by another use report_get_crosstab, and for open-text answers use responses_read. By default it counts every response (real and synthetic, any status); scope it with the filters, e.g. responseType 'real' and suspiciousLevel 'clean', and give the same filters to responses_get_counts so the denominators match.

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": "report_get"
  }
}

Input Schema

Name	Required	Description
`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)
`dateStart`	No	Only responses started at/after this time, as Unix milliseconds (13 digits; 2025-01-01T00:00Z is 1735689600000)
`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 readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: the default includes real AND synthetic responses regardless of status, and filtering must be mirrored in responses_get_counts. It does not discuss cost/latency or pagination of large result sets, 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 tight sentences: purpose, sibling routing, then default-and-filter guidance. The most surprising fact (default counts everything) arrives before the filter advice, so nothing important is buried.

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, return shape need not be described. Purpose, alternatives, default scoping, and filter-matching with responses_get_counts cover everything an agent needs to invoke this correctly.

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%, so the baseline is 3, but the description adds real semantic value: it explains what the default (no filters) means for the aggregate and gives a concrete example filter pairing (responseType 'real' plus suspiciousLevel 'clean'). That goes beyond the per-parameter enum documentation.

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 ("Read a survey's aggregated results: answer distributions and statistics per question") and immediately distinguishes itself from two named siblings, report_get_crosstab and responses_read. An agent can pick this tool without opening any 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 names when to use this tool ("what did people answer" summaries), when to use alternatives (crosstab for cross-tabulation, responses_read for open text), and adds a cross-tool consistency instruction to pass identical filters to responses_get_counts so denominators match.

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?