Skip to main content
Glama
Sign In

CallRail MCP by InsightfulPipe

by com.insightfulpipe
OverviewDiscussionsAdmin

CallRail Data Query

query_data
Read-only

Query CallRail data (Step 3 (FINAL) of workflow).

REQUIRED: Complete these steps first using query_contexts:

  1. request='accounts' - Get workspace_id, brand_id AND available_actions

  2. request='actions_details' with actions=['xxxxxx', 'xxxxxx', 'xxxxxx'] - Get detailed body structure for specific action(s) using actions from available_actions

IMPORTANT: Always call step 2 to see the exact body structure before querying.

Rely on info from steps 1-2 to construct the query body. 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": {
      "body": "<body>"
    },
    "name": "query_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the mutation-safety question is answered upstream; the description's real contribution is the failure-causing ordering constraint (steps 1-2 before querying) and the instruction to follow the schema exactly. It adds nothing about error responses, invalid-body handling, or pagination/limits on a tool whose body is entirely free-form.

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?

Numbered prerequisites with a front-loaded workflow label make this scannable and correctly ordered. Slight redundancy between "REQUIRED: Complete these steps first" and "IMPORTANT: Always call step 2," plus the literal "xxxxxx" placeholders, costs it the top mark.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generic passthrough-query tool with an output schema (so return values needn't be described) and an untyped body, the description gives the agent a complete protocol: where to get IDs, where to get body structure, then query. The delegation to query_contexts covers the biggest gap, though a note on what to do if the body is rejected would complete it.

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?

There is one parameter and schema coverage is 0% — body is an untyped object with additionalProperties:true, so the schema conveys literally no field semantics. The description partially compensates by telling the agent to derive the body shape from actions_details output, which is genuinely useful, but it supplies no field names, formats, or examples of its own.

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

Purpose3/5

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

"Query CallRail data" names a verb and a resource, and the workflow framing ("Step 3 (FINAL)") does separate it from query_contexts. But it never says what kinds of CallRail data or operations the body can express, so the actual scope of the tool stays opaque until the agent calls the prerequisite tools.

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

Usage Guidelines4/5

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

Strong prerequisite routing: it explicitly mandates calling query_contexts with request='accounts', then request='actions_details', and warns "Always call step 2." What's missing is guidance on when to reach for this versus the sibling execute_action, which is the one plausible alternative an agent would weigh.

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

All CallRail MCP by InsightfulPipe toolsInspect
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