Skip to main content
Glama
Sign In
getodds-mcp

getodds-mcp

Official
by getoddsapi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Keyless sandbox odds (no key)

get_sandbox_odds
Read-only

Read stored sports odds in a keyless sandbox to test request shapes before signing up. Rate-limited per IP; if sandbox endpoints are unavailable, it explains that and points to get_public_board.

Instructions

Keyless sandbox read of stored odds for trying request shapes before signing up. Rate-limited per IP. Depends on the /api/v1/sandbox endpoints; if they are not live yet the tool says so and suggests get_public_board.

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": "get_sandbox_odds"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
sportNo
marketNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, and the description adds substantive behavior: rate limiting per IP, a dependency on /api/v1/sandbox being live, and a graceful failure path that redirects to get_public_board. It does not describe the shape of returned odds payloads, but the failure-mode and rate-limit disclosure is genuinely useful context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with what the tool is and then the operational caveat. No filler, and the fallback advice sits where an agent will see it before calling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, rate limits, and dependency failure, which are the hard parts of this tool, but leaves the three parameters entirely to the schema and says nothing about what an odds record contains. Adequate for a low-risk read tool with self-documenting enums, but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, yet it never mentions sport, market, or limit. The enums and the limit default/min/max are self-explanatory in the schema, which limits the damage, but the description adds nothing about their semantics or defaults.

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 ('keyless sandbox read of stored odds') plus the differentiating qualifier: no signup, sandbox-only. An agent can tell this apart from get_odds and get_public_board without opening any 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?

Gives a clear use condition ('for trying request shapes before signing up'), which implicitly routes real-data needs elsewhere. It does not explicitly name a production alternative such as get_odds, but the sandbox-versus-live distinction is unambiguous.

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