Skip to main content
Glama

Report Get Crosstab

report_get_crosstab
Read-onlyIdempotent

Cross-tabulate two numeric questions of a survey. Both must be rating, opinion_scale, slider or numeric questions (ids from survey_get); any other type, such as a multiple choice question, is rejected: to break a measure down by a choice question, read the answers with responses_read and group them yourself. It takes no filters and covers all responses, real and synthetic. Report each group's base (n) alongside percentages.

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>",
      "rowQuestionId": "<rowQuestionId>",
      "colQuestionId": "<colQuestionId>"
    },
    "name": "report_get_crosstab"
  }
}

Input Schema

NameRequiredDescriptionDefault
surveyIdYesSurvey ID (from survey_list)
colQuestionIdYesQuestion ID for columns (from survey_get): a rating, opinion_scale, slider or numeric question
rowQuestionIdYesQuestion ID for rows (from survey_get): a rating, opinion_scale, slider or numeric question

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the read-only and idempotent annotations, the description adds important behavior: no filters are applied, all real and synthetic responses are included, and unsupported question types are rejected. It does not cover every operational detail such as performance or error formatting, but the annotations already carry the safety profile.

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?

The description is front-loaded with the core operation and then layers constraints, alternatives, and coverage scope without wasted wording. Every sentence contributes either invocation guidance or result-interpretation advice.

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?

For a read-only report tool with an output schema and rich annotations, the description covers the remaining essentials: eligible question types, rejection behavior, alternative tooling, and data scope. An agent has enough information to decide whether to call it and how to interpret the coverage.

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%, and the schema already documents each parameter's source and allowed question types. The description reinforces the row/column question constraints and survey question ID source, but adds little parameter-level meaning beyond the schema.

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?

The description states a specific verb and resource: cross-tabulate two numeric survey questions. It also clarifies the eligible question types and distinguishes the tool from alternatives by explicitly routing choice-question breakdowns to responses_read.

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?

It gives clear when-to-use scope by requiring both questions to be rating, opinion_scale, slider, or numeric. It also states the when-not case, that other types are rejected, and names the alternative workflow using responses_read for choice questions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources