Skip to main content
Glama

Best bonuses

best_bonuses
Read-onlyIdempotent

Current best crypto casino bonuses with the fine print decoded from the casino's own T&Cs: wagering requirement, max bonus, max cashout, free spins, min deposit, and a real-value score (headline % is a marketing metric — the decoded terms are what matter). Expired promos excluded. Use for "best crypto casino bonus", "deposit match with low wagering", "is the X welcome bonus worth it?". Example call: {"limit": 5} or {"casino": "BetUS"}.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "best_bonuses"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
casinoNoOptional: only bonuses from this casino

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive and openWorld, so the safety profile is free. The description adds real behavioral context: expired promos are filtered out and the headline % is flagged as a marketing metric while the decoded terms are authoritative. It omits ordering logic (how "best" is determined) and pagination/rate-limit behavior.

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 returned-field list and the marketing-vs-decoded caveat are front-loaded, and the example calls at the end are directly actionable. The parenthetical is a little dense but each clause carries information; nothing is padding.

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, the description correctly enumerates the fields a caller can expect back, which is the main thing an agent needs. The remaining gap is ranking semantics — what makes a bonus "best" — and result ordering/pagination, neither of which is stated.

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 50% (only `casino` is documented in the schema), and the description supplies example calls {"limit": 5} and {"casino": "BetUS"} rather than semantics. It never explains that `limit` caps the number of returned bonuses, its default of 10, or the maximum of 25 — details the agent must read out of the schema itself.

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 resource (current crypto casino bonuses) plus the differentiator that matters: wagering requirement, max bonus, max cashout, free spins, min deposit and a real-value score decoded from the casino's own T&Cs. This clearly separates it from siblings like top_casinos or list_casinos, which rank/list casinos rather than decode bonus terms.

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 concrete trigger queries ("best crypto casino bonus", "deposit match with low wagering", "is the X welcome bonus worth it?") and an exclusion rule (expired promos excluded), so the agent knows the intended context. It does not, however, name a sibling to use instead when the user wants casino rankings or side-by-side comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources