Insightful Pipe

Data Query

query_data

Read-only

Query and read data from any platform (read-only operations).

Runs read actions from the InsightfulPipe raw actions API; the query_contexts helper documents each action's exact request schema.

Use for fetching reports, analytics, metrics, and listings. For write operations, use execute_action instead.

REQUIRED: Complete these steps first using query_contexts:

request='accounts' platform='' - Get workspace_id, brand_id, and source identifiers
request='available_actions' platform='' - Get list of all available actions
request='actions_details' platform='' actions=['xxxx'] - Get detailed body structure

Always call step 3 to see the exact body structure before querying. Follow the schema exactly.

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": {
      "platform": "<platform>",
      "body": "<body>"
    },
    "name": "query_data"
  }
}

Input Schema

Name	Required	Description	Default
`body`	Yes
`platform`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.6/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the description does not need to re-argue safety. It adds useful behavioral context by identifying the raw actions API, the role of query_contexts, and the mandatory steps to obtain identifiers and exact body structure before executing a query.

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

Conciseness4/5

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

The description is front-loaded with purpose and alternatives, then gives a clear numbered prerequisite workflow. It is somewhat long, but the length is justified by the dynamic request-body API and the need to prevent incorrect queries.

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?

Given the open-world platform, dynamic body object, 0% schema coverage, and existing output schema, the description provides the missing operational context: where to get workspace identifiers, where to list actions, and where to obtain exact request schemas. An agent has enough information to avoid calling this tool incorrectly.

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 description coverage is 0%, so the description must compensate. It does so by explaining that platform is used with query_contexts requests and that the body structure must be obtained from actions_details before querying, which is substantial guidance for otherwise opaque parameters.

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 uses a specific verb and resource: 'Query and read data from any platform' and lists concrete outputs such as reports, analytics, metrics, and listings. It also distinguishes this read tool from the write sibling by explicitly naming execute_action for write operations.

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 explicitly states when to use this tool ('fetching reports, analytics, metrics, and listings') and when not to use it ('For write operations, use execute_action instead'). It also prescribes a required prerequisite workflow through query_contexts before querying.

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

All Insightful Pipe 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?