Skip to main content
Glama

flowforge_get_call

Read-onlyIdempotent

Fetch a call by ID and include its transcript, recordings, metrics, or events in one request, avoiding separate API calls.

Instructions

Fetch one call and, in the same step, any of its transcript, recordings, metrics, or events.

This consolidates what would otherwise be several API calls: pass include=['transcript','metrics'] to get the call status plus those sub-resources together.

Args: params: call_id and optional include list.

Returns: JSON/Markdown with a call object and one key per requested include (e.g. transcript, recordings, metrics, events). If an include fails, its key holds an {"error": ...} note instead of failing the whole request.

Error Handling: Returns "Error: Resource not found..." if the call_id is wrong.

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": {
      "params": "<params>"
    },
    "name": "flowforge_get_call"
  }
}

Input Schema

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the read-only, idempotent, and non-destructive annotations, it discloses per-include partial failure, where an error object is returned without failing the whole request, and the not-found response for an incorrect call_id. These details materially affect how an agent interprets partial results and handles errors.

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 purpose is front-loaded, and the short Args, Returns, and Error Handling sections are easy to scan. There is mild repetition of the nested input schema and output schema, but the example and failure semantics keep the description focused and useful.

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 single-resource fetch with a rich nested input schema and an output schema, the description supplies the important composition, partial-success, and not-found behavior needed to invoke and interpret it correctly. Explicit call-ID discovery guidance would help, but its absence is not a significant completeness gap for this relatively simple tool.

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?

Despite the low top-level coverage signal, the description identifies call_id and the optional include list and adds a concrete include=['transcript','metrics'] example showing their combined effect. It does not explain where to obtain an ID and only implicitly covers response_format through the JSON/Markdown return discussion, leaving some semantics schema-dependent.

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

Purpose4/5

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

The opening uses a specific verb and resource—"Fetch one call"—and precisely scopes the optional transcript, recordings, metrics, and events. The single-call scope hints at differentiation from flowforge_list_calls, but the description never explicitly distinguishes that sibling, campaign call listings, or the generic API request tool.

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?

It gives a concrete reason to choose the tool: retrieve call status and selected sub-resources together rather than make several API calls, supported by an include example. It does not explain when to use a list tool to discover a call_id or when another sibling is preferable, so the guidance is clear but not exhaustive.

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