Skip to main content
Glama
CTMJSON

ctm-multi-mcp

Official
by CTMJSON

call_disposition_report

Aggregate call dispositions across sub-accounts with breakdowns by status, source, duration, and campaign, replacing manual paging through calls.

Instructions

Aggregate call outcomes/dispositions across sub-accounts in one call.

Only queries active sub-accounts by default. Pass account_status="archived", "canceled", "paused", or "all" to query other sub-accounts.

Paginates the calls-list endpoint server-side (concurrently, not one page at a time) and returns pre-aggregated counts — call_status/dial_status breakdown, the logged disposition breakdown (CTM's 'sale.name' outcome field, e.g. "wrong number", "no message", "offering services"), duration stats, top marketing sources (which doubles as "breakdown by source" for whatever duration range you asked for), top ad-platform campaigns and keywords (from CTM's per-call "paid" attribution object — real Google/Bing/Meta campaign & keyword data, distinct from the CTM tracking-source label used for "source" above), and call volume by day of week.

Note on campaign/keyword data: Google withholds keyword-level text for some Search traffic even when the call is clearly attributable, so "(not provided)" keywords are expected, not a bug. campaign_id is far more reliably populated than the human-readable campaign name — if campaign names come back mostly blank, use call_crosstab with rows="campaign_id" (or "ad_group_id") for a reliable grouping.

Pass min_duration/max_duration (seconds) to scope everything — including the source/disposition/status breakdowns — to calls in that duration range, e.g. min_duration=60 for "calls over a minute by source". This replaces manually paging through search_calls and grouping raw records by hand.

Pass status (matches call_status/status/dial_status, exact, case-insensitive) and/or source (substring match against the marketing source name, case-insensitive) to scope the whole report further, e.g. status="answered", source="Google". NOTE: like search_calls, this is applied client-side after fetching — the CTM calls-list API's own status filter does not reliably work, so filtering happens here instead, on the full fetched set (not just one page), which is more reliable than filtering via search_calls.

Use this instead of paging through search_calls or looping get_call — this is the tool to reach for when asked to analyze calls/dispositions over a date range; it replaces what would otherwise take one get_call round-trip per call, or a full manual page-by-page scan for a duration/source/status cut.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
top_nNo
sourceNo
statusNo
end_dateNo
max_callsNo
start_dateNo
account_idsNo
max_durationNo
min_durationNo
account_statusNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: it queries only active sub-accounts by default, paginates concurrently server-side, applies status/source filtering client-side because the API's status filter is unreliable, and explains caveats like Google withholding keyword-level data. This is exceptionally transparent.

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 long but each sentence earns its place. It is front-loaded with the primary purpose and organized into clear paragraphs for caveats, duration scoping, and client-side filtering. No filler or redundancy.

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?

Despite having 10 parameters, no annotations, and no schema descriptions, the description covers return values, edge cases (e.g., '(not provided)' keywords), filtering behavior, and alternatives. It is a complete usage guide that leaves little ambiguity for the agent.

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 meaningfully explains account_status, min_duration/max_duration, status, and source semantics. However, not all 10 parameters are explicitly addressed (e.g., top_n, max_calls, account_ids, start_date/end_date), though some are inferable from context. It still adds significant value beyond the bare 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 opens with 'Aggregate call outcomes/dispositions across sub-accounts in one call' — a specific verb+resource+scope. It clearly distinguishes itself from sibling tools like search_calls and get_call, which retrieve raw records rather than aggregated reports.

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?

The description explicitly states when to use this tool: 'Use this instead of paging through search_calls or looping get_call — this is the tool to reach for when asked to analyze calls/dispositions over a date range.' It also names an alternative (call_crosstab) for campaign grouping, providing both when-to-use and when-to-avoid guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CTMJSON/ctm-multi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server