Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fanduel_casino_game

Fetch FanDuel casino game details like category, bet limits, studio, volatility, themes, features, live player count, and play link identifiers using a game slug and optional region.

Instructions

FanDuel Casino game detail. Returns a casino game's detail page: category, minimum and maximum bet, studio, volatility, themes, features, how many players are in it right now, its badge and description, and the identifiers its play link carries (provider, provider reference, game id and the lobby region). Slugs come from the category route; an unknown game returns 404.

Input Schema

NameRequiredDescriptionDefault
gameYesGame slug from the `category` route (`games[].slug`), lower-case, such as `huff-n-even-more-puff-hard-hat-edition`
regionNoLobby of the game: `mi` Michigan (default) or `on` Ontario

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the burden, and it does disclose the operation's read-only shape, the 404 behavior on unknown slugs, and the fact that live participation counts are returned. It does not mention auth, rate limiting, or whether the live player count is cached/eventually consistent, which keeps it below a 5 for a zero-annotation tool.

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, then payload, then prerequisites and failure mode — a sensible order with no filler sentences. The field enumeration is long but earns its place because there is no output schema to describe the return. Slightly dense but not padded.

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 no output schema and no annotations, the description must explain the return payload and call preconditions; it covers both (field list, slug source, region, 404). An agent can call it correctly from this text alone. Only marginal items — freshness of the live-player figure, region edge cases — are unaddressed.

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% — both `game` and `region` already document their formats and the mi/on enum with the `mi` default. The description only reinforces the slug provenance and mentions the lobby region in passing, adding marginal semantics beyond the schema. Baseline 3 is 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?

Opens with a precise verb-resource statement ('Returns a casino game's detail page') and then enumerates the payload (category, bet limits, studio, volatility, themes, features, live player count, badge, description, play-link identifiers). That is far more specific than the sibling list, most of which are list/search routes; an agent can distinguish this as the single-game detail endpoint without opening the 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?

Explicitly points at the source of the identifier: 'Slugs come from the `category` route', which routes the agent through the fanduel_casino_category sibling first. It also sets the failure expectation ('an unknown game returns 404'). What is missing is any explicit when-not statement or mention of alternate lookups (there are none obvious among siblings), so it stops short of the full when/when-not standard.

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