v12-dfs

betting_matchup

Matchup

GROUNDING — the real game for a team today: probable pitchers + the POSTED lineup (ACTUAL player names from MLB statsapi) + the market line + the CONTEXT a pro reasons with: home-plate UMPIRE (strike zone → totals/Ks), the INJURY report (who's OUT / Day-To-Day), and BULLPEN health (ERA / blown saves). Call this BEFORE naming any player or discussing a game. Name ONLY the players this returns — never a roster from memory (that is how the agent ends up naming players who aren't on the team).

Responses:

200: Successful Response (Success Response) Content-Type: application/json 422: Validation Error Content-Type: application/json

Example Response:

{
  "detail": [
    {
      "loc": [],
      "msg": "Message",
      "type": "Error Type",
      "ctx": {}
    }
  ]
}

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": {
      "team": "<team>"
    },
    "name": "betting_matchup"
  }
}

Input Schema

Name	Required	Description	Default
`date`	No
`team`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedJun 17, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden for behavioral transparency. It details what data is returned (probable pitchers, lineup, market line, umpire, injury report, bullpen health) and includes important usage behavior (must be called first, only use returned players). It does not mention side effects or authentication, but the provided context is strong.

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

Conciseness3/5

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

The description is lengthy and includes verbose emphasis (CAPS) and a generic error response example that is not helpful for successful calls. While it packs essential context, it could be more concise and front-loaded. The structure includes separate sections but some content is redundant.

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?

Given no annotations, output schema, or param descriptions, the description covers the tool's purpose and usage well but lacks details on the output format (only an error example) and does not explain parameter usage. It is partially complete but missing critical information for an agent to fully understand the tool's behavior and output.

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?

The input schema has two parameters (team required, date optional). The description does not explain these parameters; it mentions 'a team today' but does not clarify the date parameter or how to specify teams. With schema description coverage at 0%, the description fails to add meaning to the parameters beyond what the schema provides, missing key details like possible values or format.

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 the tool returns matchup data for a team's real game today, including probable pitchers, lineup, market line, umpire, injury report, and bullpen health. It distinguishes itself by specifying its grounding in actual data and the directive to call before mentioning players, differentiating it from sibling tools like betting_game_lines or betting_market.

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?

The description explicitly instructs when to use the tool: 'Call this BEFORE naming any player or discussing a game.' It also warns against using roster memory and states to 'Name ONLY the players this returns'. This provides clear guidance on when and how to use it versus alternatives.

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

All v12-dfs tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?