Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

datasets_bbb_scamtracker_reports_search

Search the BBB Scam Tracker reports dataset. Searches the stored archive of public consumer scam reports from bbb.org/scamtracker (dataset id enum value bbb-scamtracker-reports), one record per report: narrative, scam type, reported…

Instructions

Search the BBB Scam Tracker reports dataset. Searches the stored archive of public consumer scam reports from bbb.org/scamtracker (dataset id enum value bbb-scamtracker-reports), one record per report: narrative, scam type, reported dollar loss, targeted and scammer locations, the business name used, and the report date. Unlike the live bbb-scamtracker-search endpoint, results are not cut off at BBB's 10,000-result limit and any date range can be read page by page. Reports are unreviewed consumer allegations; names and contact details in them are as reported, not verified. The archive is still being filled, so total is the number of stored reports matching the filters, not BBB's own count. country enum: USA, CAN. sort enum: relevance, reported_desc, reported_asc, loss_desc. Billing: this search costs 1 credit per record returned, with a minimum of 2 (an empty result costs 2, a full page of 100 costs 100); the item and facets endpoints cost 1.

Input Schema

NameRequiredDescriptionDefault
qNoFull-text match on the report narrative and the business name used, max 256 characters
pageNoPage number, defaults to 1
sortNoSort enum: relevance, reported_desc, reported_asc, loss_desc
stateNo2-letter state or province code of the targeted person, e.g. TX or QC
countryNoCountry of the targeted person. Enum: USA, CAN
date_toNoInclusive report-date ceiling, YYYY-MM-DD
max_lossNoCeiling against the reported dollar loss, 0 or greater; reports with an unknown loss are excluded
min_lossNoFloor against the reported dollar loss, 0 or greater; reports with an unknown loss are excluded
date_fromNoInclusive report-date floor, YYYY-MM-DD
page_sizeNoPage size, defaults to 20 and maxes at 100; page * page_size must be <= 10000
scam_typeNoExact scam type filter, e.g. Online Purchase. Use the values returned by facets?facet=scam_type

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.12

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses that reports are unreviewed consumer allegations with unverified names, that the archive is incomplete so `total` reflects stored records rather than BBB's count, the 10,000-result limit difference, and a precise cost model (1 credit per record, minimum 2). This is exactly the context annotations would otherwise supply.

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?

Front-loaded with purpose and record contents, then caveats, then billing. Every sentence carries information, though it redundantly restates the country and sort enums that the schema already documents, which is minor waste.

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 an 11-parameter, zero-required, no-annotation, no-output-schema tool, the description covers the data model, provenance caveats, result-limit behavior, total semantics, and billing. Nothing an agent needs to call it correctly or interpret results is missing.

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 coverage is 100%, so baseline is 3. The description adds genuine meaning beyond the schema by tying pagination to cost ('a full page of 100 costs 100', empty result costs 2), which directly informs how an agent sets `page_size`, plus the interpretation of `total`.

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?

States a specific verb and resource ('Search the BBB Scam Tracker reports dataset') and immediately enumerates the record contents (narrative, scam type, loss, locations, business name, date). It explicitly contrasts itself with the live bbb-scamtracker-search endpoint, so the agent can distinguish it from the sibling bbb_scamtracker_search.

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?

The comparison to the live endpoint ('results are not cut off at BBB's 10,000-result limit and any date range can be read page by page') tells the agent when this archive is preferable, and the billing note names the item and facets endpoints as cheaper alternatives. It stops short of explicit when-not-to-use guidance, but the routing context is strong.

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