Skip to main content
Glama
Sign In
getodds-mcp

getodds-mcp

Official
by getoddsapi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Create a free GetOdds key by email

create_free_key

Generates a free-tier GETODDS API key for the user's email, enabling 1,000 requests per UTC day and 60 per minute without a card; store the one-time key as GETODDS_API_KEY.

Instructions

Create a free-tier key (1,000 requests a UTC day, 60 a minute, no card) for the user's own email address. Only call this when the user asked for a key and gave their email. The key is shown once: tell the user to store it as GETODDS_API_KEY. Depends on POST /api/v1/agent/signup.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "email": "<email>"
    },
    "name": "create_free_key"
  }
}

Input Schema

NameRequiredDescriptionDefault
emailYes
use_caseNo
agent_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false and openWorldHint=true; the description adds the critical behaviors: the key is revealed once and never again, the user must store it as GETODDS_API_KEY, and the tool depends on POST /api/v1/agent/signup. It does not say what happens if the email already has a key, which is the main residual gap for a non-idempotent signup.

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?

Three tight sentences: what it does, when to call it, then what to do with the result. No filler, and the quota facts are front-loaded where an agent will actually read them.

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?

For a mutation tool with no output schema, the description covers quota, one-time reveal, post-call user instruction, and upstream dependency — enough to call and handle it correctly. Only the two undocumented optional parameters and duplicate-email behavior are left open.

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 0%, so the description must carry parameter meaning. It clarifies that email must be the user's own address, which is genuinely useful, but says nothing about use_case or agent_name despite those being two of the three parameters.

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 (create a free-tier key) plus concrete scope: 1,000 requests per UTC day, 60 per minute, no card, tied to the user's own email. This is unmistakably different from every sibling, which are all odds/event read tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit positive precondition ('when the user asked for a key and gave their email') and an implicit exclusion ('only'), which is exactly the guard an agent needs before causing a signup side effect. No competing sibling performs key creation, so no alternative routing is required.

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