Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fanduel_casino_category

Fetch and filter FanDuel Casino lobby games by category, region, provider, badge, or name, returning paginated game details, studio, badges, jackpot flag, and page links.

Instructions

FanDuel Casino category games. Returns a page of a casino category's games in the lobby's own order, with each game's slug, name, studio, badge (Exclusive, Jackpot), whether it is flagged as a site-wide jackpot game, and a link to its page. providers and badges count the whole category so the values the provider and badge filters accept are always visible; q matches every word against the game name. all-games, slots and double-your-bet-category hold the whole catalog (about 3,800 games) in one 30MB page, so their first call is slow and the parsed list is then cached for 15 minutes.

Input Schema

NameRequiredDescriptionDefault
qNoWords to find in the game name, such as `huff puff`; every word must match
badgeNoKeep only games with this badge, exactly as listed in the response `badges` (for example `Exclusive`, `Jackpot`)
limitNoGames per page, 1 to 200; default 50
offsetNoGames to skip; default 0
regionNoLobby: `mi` Michigan (default) or `on` Ontario
categoryYesCategory slug from the `categories` route for the same `region`. Michigan has `all-games`, `new`, `slots`, `double-your-bet-category`, `jackpots`, `daily-jackpots`, `hot-slots`, `classic-reels-category`, `bonus-buy-category`, `high-limit-category`, `spooky-slots-category`, `exclusives`, `pick-play`, `arcade`, `blackjack`, `baccarat`, `roulette`, `table`, `livecasino`, `online-casino-favorites`, `explore-videos`, `motorcity-favorites`; Ontario has the same list without `hot-slots`, `classic-reels-category`, `bonus-buy-category`, `online-casino-favorites` and `motorcity-favorites`, and adds `fallsview-favourites-category`, `the-wolf-den-category`, `sports-central`. A slug the lobby lacks returns `400`
providerNoKeep only games from this studio, exactly as listed in the response `providers` (for example `NYX`, `Evolution`, `IGT`); a value the category does not have returns `400`

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A3.8/5.0
Behavior4/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 well: it discloses lobby ordering, returned fields, whole-category provider/badge counts, and that large categories produce a slow 30MB first call before a 15-minute cache. It omits some operational details such as auth or rate limits, but the key behavioral traits are clearly surfaced.

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 dense but front-loaded: it starts with the tool's purpose, then return fields, filter behavior, and finally the important performance caveat for large categories. Every sentence provides useful information, though the single-paragraph format could be easier to scan if broken up.

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?

There is no output schema, so the description appropriately lists the returned game fields and ordering. Combined with the fully documented input schema, it gives enough context to call the tool correctly, with the main remaining gaps being operational details such as auth or rate limits rather than core invocation semantics.

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 already 100%, so the baseline is 3, but the description adds meaningful context beyond the schema: it explains why provider and badge filter values are always visible, clarifies q's every-word matching, and warns that three category slugs are exceptionally large. This adds useful semantics without attempting to duplicate all enum details.

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 clearly states that this tool returns a page of games for a casino category, with specific returned fields and lobby ordering. It implicitly distinguishes itself from category-listing and single-game siblings by focusing on a category's games, but it does not explicitly name sibling tools or routing alternatives.

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?

The description provides useful usage context: the category slug comes from the categories route, provider/badge values are visible from response counts, and q matches every word in the game name. However, it does not explicitly say when to use this tool versus `fanduel_casino_categories` or `fanduel_casino_game`, nor does it provide clear exclusions.

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