Skip to main content
Glama
Sign In

sportiq-mcp

by io.github.Ninjabeam20
OverviewDiscussionsAdmin

cross_sport_build_accumulator

Read-onlyIdempotent

Model the joint probability of multiple outcomes across football and cricket.

Args: legs: Total legs across both sports (2-8). Default 3. min_edge: Minimum edge per leg. Default 0.05.

Returns: data: same shape as football_build_accumulator, with sport field per leg. meta.estimated: true.

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

Input Schema

NameRequiredDescriptionDefault
legsNoTotal legs across both sports (2-8). Default 3.
min_edgeNoMinimum edge per leg. Default 0.05.

Output Schema

NameRequiredDescriptionDefault
dataNo
metaNo
errorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful behavioral context: return data has the same shape as football_build_accumulator with a per-leg sport field, and meta.estimated is true. This goes beyond the annotations and helps the agent understand the output before invoking.

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 description is short and front-loaded with the purpose, followed by a clean Args/Returns structure. The Args section is redundant with the schema, which slightly reduces efficiency, but overall there is no fluff and it remains easy to scan.

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 an output schema present and annotations describing the tool as read-only, idempotent, and non-destructive, the description is mostly complete. It clarifies the return shape and the estimated flag, which are not in the annotations. A small gap is that it relies on knowledge of football_build_accumulator's shape, but that is acceptable given the output schema exists.

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 description coverage is 100%, so the schema already documents both parameters with defaults and constraints. The description's Args section repeats this information without adding new meaning. The parameter semantics are adequately covered by the schema, and the description adds no extra value here.

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 the tool models joint probability of outcomes across football and cricket, which distinguishes it from single-sport siblings like football_build_accumulator. The verb 'model' is somewhat abstract, but the resource and scope are explicit. It does not explicitly name an alternative, but the cross-sport scope is clear.

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

Usage Guidelines3/5

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

The phrase 'across football and cricket' implies this is for multi-sport accumulators, and referencing football_build_accumulator's shape hints at a relationship. However, it never explicitly says when to use this tool versus a single-sport alternative, nor does it state any exclusions or prerequisites. Usage context is implied, not clearly directed.

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

All sportiq-mcp toolsInspect
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