Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

bbb_scamtracker_detail

Retrieve a Better Business Bureau Scam Tracker report by ID to view scam details like description, financial loss, contact info, and date reported.

Instructions

Get a Better Business Bureau Scam Tracker report. Returns one BBB Scam Tracker consumer scam report: description, dollars lost, targeted person's location, scammer location/email/phone/URL (when known), scam type, business name used, and date reported. If BBB no longer shows the report and serves its search page at that address, the endpoint returns a permanent 404; do not retry it.

Input Schema

NameRequiredDescriptionDefault
idYesBBB Scam Tracker report id, from a bbb-scamtracker-search result's id or url

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.16.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it delivers the most important behavioral trait: a permanent 404 when BBB removes the report, with an explicit 'do not retry' instruction. It also lists returned fields (valuable since there is no output schema). It omits auth/rate-limit context, keeping it short of a 5.

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?

Three sentences, front-loaded with the action, then the return shape, then the error caveat. The field enumeration is somewhat long but earns its place because no output schema exists.

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 single-param read tool with no annotations and no output schema, the description covers purpose, input provenance, return contents, and failure behavior. Nothing an agent needs to call it correctly is missing.

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 'id' parameter and its provenance are already fully documented in the schema. The description adds no syntax or format detail beyond that, making the baseline 3 appropriate.

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 ('Get a Better Business Bureau Scam Tracker report') and enumerates the fields it returns, which lets an agent distinguish it from the sibling search/stats endpoints without opening a schema.

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 id parameter's origin ('from a bbb-scamtracker-search result') implies the search-then-detail workflow, and the description explicitly warns that a missing report yields a permanent 404 and should not be retried. It stops short of naming the search sibling as a prerequisite in prose, but the routing context is clear.

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