Verified fight records for AI assistants: look up a fighter or fight card, cite the pxl8.io page.
Scored across 3 tools
Each tool targets a distinct resource: finding fighters, retrieving event cards, and getting fighter records. No overlap or ambiguity in purpose.
All tools follow a consistent verb_noun pattern (find_fighter, get_event_card, get_fighter_record), which is clear and predictable.
Three tools fully cover the server's stated scope of verified fight record lookups, neither sparse nor bloated.
The tool surface covers the essential workflows: searching for a fighter, accessing their detailed record, and viewing event cards. No obvious gaps for a read-only lookup service.
Resolve a fighter's name (optionally with a hometown or region and a discipline) to candidate fighter pages on https://pxl8.io. Answers at most 5 candidates, each with a confidence band, the bouts on file and its canonical page URL; then call get_fighter_record with the chosen slug. The name must be at least 3 characters. When you use a result, link the canonical page URL it returns (canonicalUrl) and quote its citeAs line. A tally or bout count is a count of bouts on file from the earliest date on file — it is NOT a career record. Results are as published by the named athletic commissions and federations. This is the free lookup tier (rate-limited per client and in total); keyed partner access with higher limits exists.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The fighter's name, or the first characters of it | |
| place | No | A hometown city, state/region or country to narrow the match | |
| discipline | No | Narrow to one discipline |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly/idempotent behavior, but the description goes well beyond them: it discloses the at-most-5 result cap, confidence bands, canonical URL/citeAs attribution requirements, the crucial caveat that bout counts are not career records, data provenance, and rate limits. This is exactly the behavioral context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds a needed fact: core resolution, output shape, follow-up instruction, validation floor, attribution rule, semantic warning, data provenance, and limits. The action is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values and constraints, and it does so thoroughly: candidate limit, per-candidate fields, canonical URL/citeAs usage, the tally-vs-record caveat, data source, and rate limits. Only minor details such as empty-result handling are left out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters, so the baseline is 3. The description adds value by stating the effective minimum name length (3 characters, stricter than the schema's minLength 1) and by paraphrasing place/discipline in natural language, but it does not add examples or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Resolve a fighter's name ... to candidate fighter pages') and enumerates what a result contains, which distinguishes it from the sibling tools. It names the output resource (pxl8.io candidate pages) and the optional filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It spells out the follow-up call ('then call get_fighter_record with the chosen slug') and gives context such as rate limits and partner access. It does not explicitly say when not to use it versus get_event_card, but the intended workflow is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A published event card (https://pxl8.io/event/): promotion, date, venue, status and the bouts in order, with each corner's name and fighter page where one exists. When you use a result, link the canonical page URL it returns (canonicalUrl) and quote its citeAs line. A tally or bout count is a count of bouts on file from the earliest date on file — it is NOT a career record. Results are as published by the named athletic commissions and federations. This is the free lookup tier (rate-limited per client and in total); keyed partner access with higher limits exists.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The event page's slug — the last part of its canonical URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, and the description adds meaningful behavior: the free-tier rate limiting, the requirement to link canonicalUrl and quote citeAs, the warning that tallies are NOT career records, and the provenance statement about athletic commissions. This goes well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, each earning its place: the resource definition, citation instructions, interpretation caveat, and rate-limit/tier context. The core content is front-loaded, with caveats following logically. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema, the description covers what the result contains, how to cite it, a critical interpretation trap (tally vs career record), and operational constraints. An agent has enough to call the tool correctly and use the response appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents slug, so baseline is 3. The description adds value by explaining slug as 'the last part of its canonical URL' and giving the URL pattern (https://pxl8.io/event/<slug>), which tells an agent how to derive the parameter from a real-world page.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource ('published event card') and its contents: promotion, date, venue, status, and ordered bouts with corner names and fighter page links where available. This clearly distinguishes it from sibling tools that target fighters (find_fighter, get_fighter_record).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the resource description and practical guidance on linking results, but there is no explicit statement of when to choose this tool over the siblings (e.g., 'for fighter records use get_fighter_record'). The context is clear, but exclusions and alternative routing are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The verified record for one fighter page (https://pxl8.io/), exactly as the public page states it: every bout on file with its date, result, method, the commission that published it and the sha256 of that document, plus a tally labelled "on file from ". Where the reported grade is released, it is returned as a SEPARATE list that is never added to the verified tally. The record and every bout carry a record status (verified, confirmed by the athlete, corrected at the athlete's request, or disputed) with the date it was last reviewed; a disputed bout stays in the list — the status says only that it is disputed, never why. When you use a result, link the canonical page URL it returns (canonicalUrl) and quote its citeAs line. A tally or bout count is a count of bouts on file from the earliest date on file — it is NOT a career record. Results are as published by the named athletic commissions and federations. This is the free lookup tier (rate-limited per client and in total); keyed partner access with higher limits exists.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The fighter page's slug — the last part of its canonical URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a read-only, idempotent, non-destructive operation. The description adds substantial behavioral context: the tally is 'on file' and NOT a career record, disputed bouts remain in the list, the grade is returned separately and never added to the tally, and results are exactly as published by commissions. It also discloses rate limiting without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, front-loading the core purpose before caveats. Every sentence adds necessary context around statuses, tally semantics, citation requirements, and rate limits; it could be slightly tighter, but it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the full burden of explaining return values. It covers bout details, tally semantics, record statuses, canonicalUrl, citeAs, and rate limits — enough for an agent to invoke the tool correctly and interpret results without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'slug' parameter already described as the last part of the canonical URL. The description reinforces this with the pxl8.io/<slug> pattern but does not add meaningful new param semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: fetching 'the verified record for one fighter page'. It clearly scopes the tool to a single fighter's record, which distinguishes it from siblings like get_event_card, and includes the exact URL pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use — it is the free lookup tier for a fighter's verified record, with rate limits and mention of higher-limit partner access. It does not explicitly name alternatives like find_fighter or get_event_card, but it provides enough context for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_fighterget_event_cardget_fighter_recordMMA fight data: UFC, PFL, OKTAGON, BKFC, RIZIN events, results, stats, rankings, judges scorecards.
Entity intelligence across AI surfaces. Read the verified record and submit corrections.
BJJ gym, coach, event, and city data for AI agents. Free base tools, x402-paid premium.
Live sports stats and pre-computed analysis for AI assistants across NBA, MLB, NFL, and NHL.
Add one secure layer between your agents and this server.
