Boxerbook

Bout

bout

Read-onlyIdempotent

One bout in full by Boxerbook bout id: both boxers with records going in, status, result (winner, method, round, time), start_utc, venue, card, broadcasters, sources, Boxerbook forecast with its signals and the market consensus when known. Cite the url.

Input Schema

Name	Required	Description	Default
`id`	Yes	Boxerbook bout id (from a schedule, results, search or a /bouts/<id>/<slug> url)

Output Schema

Name	Required	Description
`a`	Yes
`b`	Yes
`id`	Yes
`url`	Yes
`city`	No
`date`	Yes
`time`	No
`as_of`	Yes
`event`	No
`round`	No
`venue`	No
`market`	No
`method`	No
`status`	Yes
`winner`	No
`country`	No
`partial`	No	true when part of the data could not be read this time; retry in a minute for the full answer
`signals`	No	signals of the latest forecast: a and b per side (age, age_precision, record, layoff_days, last5, ko_rate, home, travel_km, mu_delta_12m, div_shift, listed_first, short_notice_days, weight_lb, missed_weight, amateur, height_cm, reach_cm, stance, ...) and bout (title, rounds, main, division, lead_days, replaced, weigh_diff_lb)
`sources`	Yes
`weighin`	No	the official weigh-in, per side when known: a commission sheet before the press
`forecast`	No
`start_utc`	No
`broadcasts`	Yes
`exhibition`	No
`fight_week`	Yes	facts said in fight-week videos (press conference, weigh-in, face-off, open workout): only accepted ones, at most 24; no predictions or opinions
`title_text`	No
`attribution`	Yes
`merged_from`	No	present when the id asked was a duplicate merged into this bout (the id asked; id and url are this bout's)
`provisional`	No
`confirmation`	No
`scheduled_rounds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

addedOutput schema / properties / merged_from

Added value: +{
+  "description": "present when the id asked was a duplicate merged into this bout (the id asked; id and url are this bout's)",
+  "type": "integer"
+}

Changed1 schema field changedOct 23, 2026

changedInput schema / properties / id / description

Previous value: -"Boxerbook bout id (from a schedule, results, search or a /bouts/<id> url)"New value: +"Boxerbook bout id (from a schedule, results, search or a /bouts/<id>/<slug> url)"

First observedOct 23, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description adds genuinely new behavior: the response is exhaustive (records going in, result detail, card, broadcasters, sources), includes forecast signals plus market consensus 'when known', and imposes a citation requirement via 'Cite the url.' It does not mention missing/unknown bouts or error behavior.

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?

A single dense sentence that front-loads the purpose ('One bout in full by Boxerbook bout id') and then lists the payload, closing with the citation instruction. No filler sentences, nothing redundant.

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?

The description, combined with a 100%-covered single-param schema, full annotations, and an output schema, gives an agent everything needed to invoke correctly and to know how to present results. Minor gap: no statement about what happens when the id does not resolve.

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 100% and the id parameter is already documented as a 'Boxerbook bout id' with its origins. The description restates the same fact ('by Boxerbook bout id') without adding format, range, or failure semantics beyond the schema.

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?

States a specific resource and scope: 'One bout in full by Boxerbook bout id', then enumerates the contents so an agent knows this is a single-entity lookup rather than a list. It does not name a sibling, so the differentiation from boxing_results or next_fight is inferred rather than stated.

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: call it when you have a bout id and want the complete record. The description hints where ids come from ('from a schedule, results, search or a /bouts/<id>/<slug> url'), but there is no explicit when-to-use/when-not or named alternative for fetching bout data in bulk.

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

All Boxerbook 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.