Skip to main content
Glama
pghdma

CallRail MCP

spam_detector

Identify likely-spam calls using heuristic scoring based on short duration, unanswered calls, or frequent repeat callers. Optionally tag flagged calls for review.

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
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: the additive scoring logic, the memory blowup risk (hard-capped at 90 days), that the full call list is materialized, and the side effects of auto_tag (adding a tag, auto-creating if missing). It also reveals that spam-flagged calls are hidden from default GET endpoints, which is critical for the agent to know.

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 well-structured with sections (scoring, args, returns) and front-loads the purpose. However, it is somewhat lengthy due to detailed scoring logic and parameter explanations. While this is justified given the tool's complexity, a slightly more compact description could improve conciseness.

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 tool's complexity (5 optional params, return object with breakdown and histogram) and absence of annotations, the description is remarkably complete. It covers usage guidelines, behavioral side effects, parameter semantics, and return values. The output schema is not provided, but the description adequately describes what is returned.

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 coverage is 0%, so the description must compensate, and it does so comprehensively. Each parameter is explained with purpose, constraints (e.g., days hard-capped at 90, company_id recommended), default values, and behavior (e.g., tag auto-creation, auto-resolving account_id). This adds significant meaning beyond the raw 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 clearly states the tool's purpose: 'Heuristically identify likely-spam calls and (optionally) tag them.' It uses specific verbs ('identify', 'tag') and references to 'likely-spam calls', distinguishing it from sibling tools like add_call_tags (which tags arbitrary calls) and get_calls (which lists calls).

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 provides explicit guidance: it recommends using company_id, explains the lookback window (1-90 days), and details when auto_tag is appropriate. It also clearly states a when-not: 'we deliberately do NOT mark calls as spam=True automatically' and explains the rationale. Sibling tools are listed, and the description implicitly distinguishes spam detection from other call-related tools.

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/pghdma/callrail-mcp'

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