Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

bbb_scamtracker_state_stats

Retrieve BBB Scam Tracker aggregate stats by US state or Canadian province: report counts, dollar losses, per-capita rates, year-over-year change, and top scam types for a selected period.

Instructions

Get Better Business Bureau Scam Tracker state/province aggregate stats. Returns aggregate scam-report stats per US state and Canadian province for a given time window: report counts, dollar losses, per-capita rates, year-over-year change, and top scam-type breakdown.

Input Schema

NameRequiredDescriptionDefault
periodNoAggregation window, default 90

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / period / enum
      Added value: +[
+  "30",
+  "90",
+  "365",
+  "all"
+]
  2. Addedv1.16.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the shape of the response (counts, losses, per-capita rates, YoY change, scam-type breakdown), which matters because there is no output schema, but it says nothing about read-only nature, auth, rate limits, or whether records are exhaustive.

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?

Two sentences, zero filler, and the resource/scope is front-loaded before the returned-metric list. Nothing redundant and every clause earns its place.

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?

With one optional enum param fully covered by the schema and the return fields enumerated in prose, an agent has what it needs to call the tool. The only gap is routing guidance against the many bbb_scamtracker/report siblings.

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?

Schema description coverage is 100%, so the single 'period' enum is fully documented in the schema. The description only alludes to 'a given time window' and adds no format, default, or semantics beyond what the schema already provides — baseline 3.

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 description uses a specific verb+resource (BBB Scam Tracker state/province aggregate stats) and enumerates the returned metrics, which distinguishes it from granular report-level siblings like bbb_scamtracker_search. However, it never names those alternatives, so the differentiation is implicit rather than explicit.

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

Usage Guidelines3/5

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

Usage is only implied: 'for a given time window' and 'aggregate stats' suggest this is for summary-level questions rather than individual report lookups. There is no stated when-to-use/when-not, no mention of the sibling bbb_scamtracker_search/detail tools, and no prerequisites.

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

Deploy Server

Other Tools