DeepChamp for Agents

Fair value (no margin)

calc_fair_value

Read-onlyIdempotent

No-margin fair probability from one or two of your own prices. Arithmetic on your own numbers only: nothing is stored and no outside data is read. Research intelligence (probabilities, factors, context), not winning picks. Price: Free, no signup. Research and information, not betting advice. No outcomes are guaranteed. Adults 21+ only, where legal. Problem gambling help: 1-800-MY-RESET.

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": {
      "price": "<price>"
    },
    "name": "calc_fair_value"
  }
}

Input Schema

Name	Required	Description
`price`	Yes	Your own price from your own source: give exactly one of american or decimal odds.
`method`	No	How the margin is removed. Default proportional.
`visual`	No	Optional. How to present the result: auto (default, chosen by client), image (picture and link), text (terminal chart), none (data only).
`harness`	No	Optional display hint. It changes the output format only, never access, price or limits.
`opposite_price`	No	Optional price of the other side of the same market. With it the market margin is removed.

Output Schema

Name	Required	Description
`data`	No
`meta`	No
`error`	No	Failure only: code, message, request_id, billable (always false).
`visual`	No
`billing`	No	Always free for the calculators: status free, price_micros 0.
`rest_url`	No
`compliance`	No
`continue_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description reinforces this with 'nothing is stored and no outside data is read', which is genuinely useful confirmation for a calculation tool. Beyond that the remaining text is legal/compliance boilerplate (free, 21+, gambling helpline) rather than behavioural detail such as how a single price behaves without a margin to remove.

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 first sentence is well front-loaded and carries the core meaning; the second reinforces the no-storage guarantee. However, roughly half the text is repeated disclaimer boilerplate ('Research and information, not betting advice. No outcomes are guaranteed. Adults 21+ only... 1-800-MY-RESET') that adds no tool-selection value, diluting an otherwise tight definition.

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?

With full schema coverage, rich annotations and an output schema, most of the burden is already handled structurally, and the description correctly avoids restating return values. The remaining gap is behavioural: it does not explain what changes when only one price is supplied (no market margin available) or when to prefer one method over the other, which matters for a 'no-margin' tool.

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 explains american/decimal formats, method, visual and harness. The description adds only a small amount of meaning: that you supply 'one or two of your own prices', linking price and opposite_price conceptually, and clarifying the inputs are your own numbers. Baseline 3 applies when the schema does the heavy lifting.

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 opening sentence states a concrete operation and resource: 'No-margin fair probability from one or two of your own prices.' Combined with the title 'Fair value (no margin)', an agent can tell this is a de-vigging/implied-probability calculator rather than a price lookup. It does not name a sibling such as calc_best_price or calc_ev_scan, so the differentiation from neighbouring calc_* tools is only implicit.

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?

Usage is implied rather than spelled out: 'from one or two of your own prices' and 'Arithmetic on your own numbers only' signal when this applies (you already have odds and want a fair probability without vig). There is no explicit when-not condition or named alternative for scenarios like scanning prices or comparing books, so the agent must infer the boundary from sibling names alone.

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

All DeepChamp for Agents 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?