Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

bbb_news

Fetch BBB newsroom stories by country, state, city, or local chapter with optional topic and paging. Use canonical URLs to retrieve structured cards and compare local lists with the country newsroom.

Instructions

Get BBB newsroom stories. Returns one page of BBB newsroom cards from a canonical BBB newsroom URL. Three scopes are accepted, each with an optional topic: the US or Canada newsroom (/us/news), a state, province or city newsroom (/us/ca/news, /us/ca/san-francisco/news), and one local BBB chapter's own newsroom (/local-bbb//news, the news_url returned by bbb-local-bbbs and bbb-local-bbb). The list is whatever BBB shows on that page: a city or chapter whose local BBB publishes its own stories returns those, and other cities, other chapters and the state pages checked so far return the same list as the country newsroom, so compare total and the first items with the country newsroom before treating a list as local. A chapter URL also returns local_bbb_id and local_bbb_name. Items preserve BBB's type and include Article stories, events, and Near Me related-service cards when present. Near Me URLs are restricted to BBB's /near-me/ paths. Every page carries total_pages and has_more: request page + 1 while has_more is true and stop when it is false; a page past the end returns 404. Event dates and links are preserved when present.

Input Schema

NameRequiredDescriptionDefault
urlYesCanonical https://www.bbb.org newsroom URL: /us/news or /ca/news; /<country>/<state>/news or /<country>/<state>/<city>/news with country us or ca, the two-letter region code from bbb-regions and the city slug from a business profile URL; or a chapter's news_url from bbb-local-bbbs. Append a topic segment from bbb-news-topics to narrow it and ?page=N (1 to 1000) to page; no other query key is accepted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.12

TDQS

A4.1/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 burden and meets it: it discloses pagination semantics (total_pages, has_more, 404 past the end), the local_bbb_id/local_bbb_name extras on chapter URLs, the caveat that many scopes return the same list as the country newsroom, the Near Me URL restriction, and item types. This is unusually rich behavioral disclosure.

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 the core purpose, then progressively adds scope and behavioral detail. It is long and would benefit from structure, but each sentence carries substantive information (scopes, paging, local-vs-national caveat) rather than filler.

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?

No output schema exists, and the description compensates thoroughly by explaining return shape (newsroom cards, item types, local_bbb fields), pagination, and error behavior. An agent has everything needed to call and iterate this tool correctly.

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 coverage is 100% for the single url parameter, so the schema already documents the URL format, topic segment, and page query. The description restates the scopes but adds little syntax beyond the schema; the genuinely new information it provides is behavioral rather than parameter-level. Baseline 3 applies.

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?

States a specific verb and resource ("Get BBB newsroom stories", "Returns one page of BBB newsroom cards") and enumerates the three URL scopes it accepts. It does not explicitly distinguish itself from nearby siblings such as bbb_article or bbb_page, but the scope is specific enough for an agent to route correctly.

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?

Gives clear usage context: the three accepted scopes, the optional topic segment, and how to page via has_more. It also names the sibling tools that produce valid inputs (bbb-local-bbbs, bbb-local-bbb, bbb-regions, bbb-news-topics). It stops short of explicit when-not-to-use guidance, so not a 5.

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