Skip to main content
Glama
pghdma

CallRail MCP

by pghdma

spam_detector

Heuristically identify likely-spam calls and (optionally) tag them.

Instructions

Heuristically identify likely-spam calls and (optionally) tag them.

Spam scoring (additive): +2 if duration < 10 seconds +1 if not answered +1 if first_call AND duration < 30 seconds +1 if same caller appears >=3 times in window (likely auto-dialer) A call scoring >= 3 is flagged as likely spam.

Args: company_id: Restrict to one company (recommended). days: Lookback window (1-90; 90 is hard-capped to avoid memory blowup on high-volume clients: full call list is materialized for scoring before truncating the response). auto_tag: If True, ADD tag_name to each likely-spam call after the scan. Default False (preview only). Note: we deliberately do NOT mark calls as spam=True automatically: CallRail HIDES spam-flagged calls from default GET endpoints, so self-reviewing them later becomes painful. Tag first, manually spam-flag if confirmed. tag_name: The tag to add when auto_tag=True. Default 'auto_detected_spam'. Auto-creates the tag at company level if it doesn't exist (CallRail's behavior). account_id: Auto-resolves if omitted.

Returns: - score breakdown by call - histogram of caller phone numbers (so you can spot a single dialer hammering you) - if auto_tag: count tagged + failures

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo
auto_tagNo
tag_nameNoauto_detected_spam
account_idNo
company_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

With zero annotations, the description carries full burden and it delivers exceptionally. It discloses the memory blowup risk and hard cap on days, the deliberate decision NOT to auto-set spam=True (because CallRail hides spam-flagged calls from GET endpoints), and the side effect that auto_tag auto-creates the tag at company level. This is model behavioral transparency — it explains design rationale and side effects.

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 every sentence earns its place: the scoring heuristic is essential, the Args block maps to all 5 params, and the behavioral caveats (memory cap, hidden spam-flag side effect) are necessary for correct use. It is front-loaded with the purpose line, then structured by scoring, args, and returns.

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 tool with high complexity (heuristic scoring, side effects, memory constraints), 0% schema coverage, and no annotations, the description covers everything an agent needs: purpose, scoring rules, all parameter semantics, side effects, design rationale, and a Returns section that explains score breakdown, histogram, and tag counts. Nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 fully compensate — and it does. Every parameter gets meaning beyond the schema: company_id is 'recommended', days has a 1-90 range with hard cap rationale, auto_tag explains the preview-vs-mutation distinction, tag_name explains auto-creation behavior, and account_id auto-resolves if omitted. The scoring rule section also connects days and duration semantics.

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+resource ('Heuristically identify likely-spam calls and optionally tag them') and then gives the exact additive scoring heuristic. It clearly distinguishes itself from siblings like get_call (single-call retrieval), search_calls_by_number (number lookup), and call_summary — an agent can tell this is a bulk heuristic classifier, not a lookup or summary 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?

Provides clear operational context: recommends company_id for scoping, explains days lookback window bounds, and distinguishes preview mode (auto_tag=False) from mutation mode (auto_tag=True). However, it never explicitly names alternatives or says when NOT to use it versus siblings like list_calls or search_calls_by_number. The distinctiveness is implied by the heuristic description rather than stated as exclusions.

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