Verified fight records for AI assistants: look up a fighter or fight card, cite the pxl8.io page.
Scored across 7 tools
Several tools overlap in retrieving the same records: search and find_subject/find_fighter both resolve names, while fetch and get_subject/get_fighter_record can read the same person/fighter records via different id, handle, or slug paths. The detailed descriptions help distinguish intent, but the boundaries are not crisp enough to prevent misselection.
All names use snake_case, but verbs are mixed: bare fetch/search, find_*, and get_*. There is a partial find_/get_ pairing pattern, yet no single predictable verb_noun convention.
Seven tools is well within the 3-15 range and each covers a distinct retrieval operation for a read-only lookup server. Even with some redundancy, the count is appropriate for the scope.
The surface covers name resolution, full-record retrieval, event cards, and cross-source search for fighters and subjects, but it lacks list/browse or search operations for the many other entity types fetch supports (parcels, providers, sanctions, recalls, etc.). Agents also have no way to discover event-card slugs except from other records, which is a notable gap.
Read one record by the id search returned (person:, organization:, fighter:, parcel:/, provider:, au_company:, chrb_ruling:, cpsc_recall:, eu_sanction:, eu_tender_notice:, fdic_institution:, legal_entity:, jp_corporation:, khrc_ruling:, vehicle_manufacturer:, exclusion:, fda_device_recall:, sg_entity:, company:, uk_contracts_finder_notice:, uk_tender_notice:, uk_sanction:, significant_control:, facility:, motor_carrier:, contract_notice: or restricted_party:). Answers { id, title, text, url, metadata } as one JSON document; metadata carries kind, recordStatus, citeAs and lastReviewed. The text presents facts in three separate grades, each its own list; a fact stated by the subject is the subject's own statement; a disputed fact remains present, marked Disputed. The url and the citeAs line in metadata identify the page for attribution. Each result carries its url and the citeAs attribution line in metadata; a disputed fact remains in the answer, marked with the word Disputed. This is the lookup tier that needs no key (rate-limited per client and in total); keyed partner access with higher limits exists.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, au_company:<subject_key>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, eu_tender_notice:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, jp_corporation:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, sg_entity:<subject_key>, company:<subject_key>, uk_contracts_finder_notice:<subject_key>, uk_tender_notice:<subject_key>, uk_sanction:<subject_key>, significant_control:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key>, contract_notice:<subject_key> or restricted_party:<subject_key> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuine behavioral context beyond them: rate limits per client and in total, plus a keyed partner tier with higher limits. It also discloses the response shape and the disputed-fact handling, though the fact-grade explanation is repetitive and slightly muddled.
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 long id-prefix enumeration is copy-pasted from the schema, front-loading bloat before any behavioral information. The url/citeAs attribution and the Disputed-fact rule are each stated twice, which is pure redundancy in an already lengthy description.
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 return contract and does so: { id, title, text, url, metadata } with metadata fields (kind, recordStatus, citeAs, lastReviewed). An agent has enough to call it, though error/not-found behavior for an unknown id is unstated.
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?
Only one parameter, and schema description coverage is 100%, so the schema already documents the id fully. The description reproduces the same prefix list verbatim rather than adding new meaning (no examples of real ids, no resolution/failure behavior), so it stays at the baseline.
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?
Clear specific verb+resource: 'Read one record by the id search returned,' and it explains the id format comprehensively. It implicitly routes from search but does not explicitly distinguish itself from overlapping siblings like get_subject or get_fighter_record, which appear to cover id kinds also listed here.
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?
'By the id search returned' implies the retrieve-after-search workflow, giving usable but implicit guidance. There is no explicit when-not-to-use or naming of alternative siblings, and the partner-access note describes an access tier rather than a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, its canonical page URL and its slug. The name must be at least 3 characters. Every result carries its canonical page URL (canonicalUrl) and a citeAs attribution 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 lookup tier that needs no key (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?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses meaningful behavior: max 5 candidates, bout counts are not career records, results are as published by commissions, and every result includes canonicalUrl and citeAs. It also exposes rate-limit characteristics. No contradiction with 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?
The description is front-loaded with the core purpose and is information-dense. It is slightly repetitive about canonical URLs and bouts on file, but each sentence contributes meaningful operational detail.
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 lookup tool with no output schema, the description adequately explains return contents, attribution, data source, validation, and rate-limit context. An agent has enough to invoke it correctly and interpret results.
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 description coverage is 100%, so baseline is 3. The description adds value by imposing a minimum name length of 3 characters (schema only says minLength 1) and by clarifying the optional role of place and discipline for narrowing matches.
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 uses a specific verb ('Resolve ... to candidate fighter pages') and names the resource (fighter pages on pxl8.io), the optional qualifiers (place, discipline), and the output shape (up to 5 candidates, confidence band, URL, slug). It clearly distinguishes this as the name-resolution lookup tier from sibling tools like 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 description gives clear context: this is the no-key lookup tier, rate-limited per client and in total, with keyed partner access mentioned as a higher-limit alternative. It does not explicitly name sibling tools or state when not to use them, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the name of a person or an organization to published records on https://pansofica.com — records whose subject proved who they are and reviewed what is said about them. Answers at most 5 candidates (the name must be at least 3 characters), each carrying its handle and kind. This is a lookup, not a list. The facts come in three separate grades, each its own list, never one merged list or count: facts from a registry document, facts from the open web, and facts stated by the subject. A fact stated by the subject is the subject's own statement, not a confirmation; a disputed fact remains in the answer, marked Disputed, with no reason attached. This is the lookup tier that needs no key (rate-limited per client and in total); keyed partner access with higher limits exists.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Narrow to people or to organizations | |
| name | Yes | The person's or the organization's name, or the first characters of it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state read-only, idempotent, and non-destructive behavior, so the description does not need to repeat safety signals. It adds substantial behavioral detail: at most 5 candidates, the 3-character minimum name, three separate fact-grade lists, the meaning of "stated by the subject," and the Disputed marker with no attached reason. This gives the agent meaningful expectations beyond the 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?
The description is longer than minimal, but nearly every sentence carries meaningful operational detail—candidate limit, fact-grade semantics, disputed handling, and rate-limit/auth context. It is front-loaded with the core purpose and lookup distinction. Slightly dense in the middle, but not wasteful.
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 does the necessary work of explaining the returned data: up to 5 candidates, handle and kind per candidate, and three separate fact lists with a Disputed marker. It also covers auth requirements (no key, rate-limited; partner access exists) and operational constraints. An agent has enough to call this tool and interpret its response correctly.
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 input schema already describes both parameters fully (name and kind enum), so the baseline is 3. The description adds value by clarifying the effective minimum name length (3 characters, despite schema minLength 1) and by explaining that kind narrows the resolution. This goes beyond a mere restatement of 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 clearly states a specific action: "Resolve the name of a person or an organization to published records" on pansofica.com MAG. It reinforces the purpose with "This is a lookup, not a list," which separates it from list/listing tools. The result shape (up to 5 candidates with handle and kind) is also stated, making the tool's role unambiguous.
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: use this when you need to resolve a name into handles/kinds, and it explicitly says "not a list," which steers away from bulk listing. It also mentions the unkeyed lookup tier and rate limits, but it does not explicitly name sibling alternatives such as get_subject or search, so when-to-use versus those specific tools is left implied.
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. Every result carries its canonical page URL (canonicalUrl) and a citeAs attribution 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 lookup tier that needs no key (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?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds substantial behavioral context: it clarifies that bout counts are not career records, states that results are as published by athletic commissions/federations, discloses rate limits and auth requirements, and lists output attributes like canonicalUrl and citeAs. This gives the agent a clear picture of what to expect without contradicting the 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?
The description is moderately long but each sentence contributes value: it front-loads the core resource definition, then adds output details, a caveat about bout counts, data provenance, and access tier info. It is well-structured with no filler, though it could be slightly tighter by merging related sentences.
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 simple lookup tool with one parameter and no output schema, the description is thorough: it enumerates the return fields, clarifies data semantics, mentions authentication and rate limits, and sets expectations about the source. Nothing an agent needs to decide whether to call this tool and interpret its result is missing.
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 input schema already fully describes the single slug parameter with its meaning and format. The description adds a URL template (https://pxl8.io/event/<slug>) which reinforces the schema but does not significantly expand its meaning. Given 100% schema coverage, the baseline of 3 is appropriate.
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 clearly identifies the resource as a published event card and enumerates its contents: promotion, date, venue, status, and bouts with corner names and fighter pages. The URL pattern and specific field list make it unambiguous what this tool returns, and the resource type is distinct from siblings like get_fighter_record or find_subject.
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 provides contextual information about the access tier (no key required, rate-limited) and mentions that keyed partner access exists, but it does not explicitly state when to use this tool versus alternatives or give conditions for exclusion. It implies usage for event card lookups but does not reference any sibling tool by name.
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. Every result carries its canonical page URL (canonicalUrl) and a citeAs attribution 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 lookup tier that needs no key (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 signal readOnly, idempotent, and non-destructive behavior, and the description adds substantial context beyond that: statuses, disputed bouts remaining in the list, the separate grade list never added to the tally, the counting definition, canonicalUrl/citeAs, and source attribution. No contradiction with 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?
The description is dense but every sentence contributes essential behavioral or contextual information. The primary purpose is front-loaded, and subsequent sentences clarify exceptions, status semantics, counting caveats, and access tiers without 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?
For a one-parameter lookup with no output schema, the description is remarkably complete: it explains what is returned, how counts should be interpreted, the meaning of statuses, the source of results, and access/rate-limit context. An agent has enough information to call the tool correctly and interpret the result.
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 description coverage is 100%, so the schema already fully documents the single `slug` parameter. The description reinforces that the slug corresponds to a pxl8.io page URL and canonical URL, but it does not add significant new meaning 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 opens with a specific verb and resource: it retrieves the verified fighter record for one fighter page, exactly as the public page states it. It also scopes the tool to a fighter page via slug and distinguishes it from broader search or event-card tools by emphasizing 'one fighter page' and 'verified 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 description gives clear context for when to use this tool: public, keyless lookup of a single fighter's verified record by slug. It also contrasts with keyed partner access by noting this tier needs no key and is rate-limited, but it does not explicitly name sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One published record (https://pansofica.com/ for a person, https://pansofica.com/org/ for an organization), exactly as its public page states it: the facts in three separate lists by grade, each fact with its field, value, sources and status, plus the record status and when it was last reviewed. A fact from a registry document or from the open web carries a status (verified, reported, confirmed by the subject, or disputed); a fact stated by the subject carries NO status — it is a statement, not a confirmation. The facts come in three separate grades, each its own list, never one merged list or count: facts from a registry document, facts from the open web, and facts stated by the subject. A fact stated by the subject is the subject's own statement, not a confirmation; a disputed fact remains in the answer, marked Disputed, with no reason attached. This is the lookup tier that needs no key (rate-limited per client and in total); keyed partner access with higher limits exists.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | person or organization | |
| handle | Yes | The record's handle — the last part of its page URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description discloses important behavior: facts are grouped into three separate grade lists, subject-stated facts carry no status, disputed facts are returned marked Disputed without a reason, and facts from registries or the open web carry statuses. No contradiction with the annotations exists.
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 dense and detailed, which is appropriate for a tool with no output schema. However, it repeats the point about three separate lists and the 'statement, not confirmation' distinction, so it is slightly less concise than it could be.
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 two-parameter tool with no output schema, this description is highly complete: it explains the URL, the returned structure, status semantics, grading, edge cases like disputed facts, and rate-limit context. An agent has enough information to call it correctly and interpret the result.
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%, so the baseline is 3. The description adds meaning by showing URL patterns for person and organization records and clarifying that handle is the last part of the page URL, which goes beyond the schema's simple property descriptions.
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 names a specific action (get the record), a specific resource (a person or organization by handle), and the exact public-page semantics. It also distinguishes itself from likely siblings like find_subject by focusing on a single published record addressed by handle and kind.
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 clearly positions this as the no-key lookup tier and mentions rate limits and the existence of keyed partner access, which tells an agent when this tool is appropriate. It does not explicitly name alternative tools or conditions for selecting them, but it gives enough context for correct placement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Pansofica records of people and organizations and pxl8.io fighter records by name. Each result carries an id in the form the fetch tool reads, and its url. Answers { results: [{ id, title, url }] } as one JSON document: at most 5 person or organization records first, then at most 5 fighter records; a query under 3 characters answers an empty list. A notice member says when one of the two sources could not be searched. This is a lookup, not a list. Each result carries its url and the citeAs attribution line in metadata; a disputed fact remains in the answer, marked with the word Disputed. This is the lookup tier that needs no key (rate-limited per client and in total); keyed partner access with higher limits exists.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A person's, an organization's or a fighter's name, or the first characters of it (at most 200 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses return shape, result ordering and limits, empty results for short queries, a notice when a source fails, citeAs metadata, disputed-fact handling, and rate limiting. This is rich behavioral context with no contradiction against 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?
The description is front-loaded with purpose and scope, and nearly every sentence carries operational value. It is slightly long and somewhat repetitive around result URLs and metadata, but it remains dense and useful rather than padded.
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 one parameter and no output schema, the description fully compensates: it specifies the JSON response shape, maximum result counts, ordering, edge cases, attribution metadata, failure notices, and authentication tiers. An agent has everything it needs to invoke this correctly.
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 the only parameter, query, at 100% coverage, so baseline is 3. The description adds operational meaning: search by name or partial name, queries under 3 characters return empty, and results are limited per source. That extra guidance justifies a 4.
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 opens with a specific action and resource: searching Pansofica records of people/organizations and pxl8.io fighter records by name. It further distinguishes this from a list operation and connects results to the fetch tool, so an agent can tell it apart from the get_* and find_* siblings.
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 clearly frames this as a lookup, not a list, and explains the no-key rate-limited tier versus keyed partner access. It does not explicitly name sibling alternatives or say 'use find_fighter when...', so it falls short of full cross-tool routing guidance.
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.
fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, au_company:<subject_key>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, eu_tender_notice:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, sg_entity:<subject_key>, company:<subject_key>, uk_contracts_finder_notice:<subject_key>, uk_tender_notice:<subject_key>, uk_sanction:<subject_key>, significant_control:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key>, contract_notice:<subject_key> or restricted_party:<subject_key>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, au_company:<subject_key>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, eu_tender_notice:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, jp_corporation:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, sg_entity:<subject_key>, company:<subject_key>, uk_contracts_finder_notice:<subject_key>, uk_tender_notice:<subject_key>, uk_sanction:<subject_key>, significant_control:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key>, contract_notice:<subject_key> or restricted_party:<subject_key>"fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, eu_tender_notice:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, sg_entity:<subject_key>, company:<subject_key>, uk_contracts_finder_notice:<subject_key>, uk_tender_notice:<subject_key>, uk_sanction:<subject_key>, significant_control:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key>, contract_notice:<subject_key> or restricted_party:<subject_key>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, au_company:<subject_key>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, eu_tender_notice:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, sg_entity:<subject_key>, company:<subject_key>, uk_contracts_finder_notice:<subject_key>, uk_tender_notice:<subject_key>, uk_sanction:<subject_key>, significant_control:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key>, contract_notice:<subject_key> or restricted_party:<subject_key>"fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, eu_tender_notice:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, sg_entity:<subject_key>, company:<subject_key>, uk_contracts_finder_notice:<subject_key>, uk_tender_notice:<subject_key>, uk_sanction:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key>, contract_notice:<subject_key> or restricted_party:<subject_key>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, eu_tender_notice:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, sg_entity:<subject_key>, company:<subject_key>, uk_contracts_finder_notice:<subject_key>, uk_tender_notice:<subject_key>, uk_sanction:<subject_key>, significant_control:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key>, contract_notice:<subject_key> or restricted_party:<subject_key>"fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, company:<subject_key>, uk_sanction:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key> or restricted_party:<subject_key>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, eu_tender_notice:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, sg_entity:<subject_key>, company:<subject_key>, uk_contracts_finder_notice:<subject_key>, uk_tender_notice:<subject_key>, uk_sanction:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key>, contract_notice:<subject_key> or restricted_party:<subject_key>"fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, company:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key> or restricted_party:<subject_key>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, company:<subject_key>, uk_sanction:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key> or restricted_party:<subject_key>"fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, company:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key> or restricted_party:<subject_key>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, eu_sanction:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, company:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key> or restricted_party:<subject_key>"fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, fdic_institution:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, motor_carrier:<subject_key> or restricted_party:<subject_key>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, fdic_institution:<subject_key>, legal_entity:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, company:<subject_key>, facility:<subject_key>, motor_carrier:<subject_key> or restricted_party:<subject_key>"fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, fdic_institution:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key> or fda_device_recall:<subject_key>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, fdic_institution:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key>, fda_device_recall:<subject_key>, motor_carrier:<subject_key> or restricted_party:<subject_key>"fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, cpsc_recall:<subject_key>, fdic_institution:<subject_key>, vehicle_manufacturer:<subject_key> or fda_device_recall:<subject_key>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, provider:<npi>, chrb_ruling:<subject_key>, cpsc_recall:<subject_key>, fdic_institution:<subject_key>, khrc_ruling:<subject_key>, vehicle_manufacturer:<subject_key>, exclusion:<subject_key> or fda_device_recall:<subject_key>"fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle>, fighter:<slug> or parcel:<jurisdiction>/<apn>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug>, parcel:<jurisdiction>/<apn>, cpsc_recall:<subject_key>, fdic_institution:<subject_key>, vehicle_manufacturer:<subject_key> or fda_device_recall:<subject_key>"fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"An id from search: person:<handle>, organization:<handle> or fighter:<slug>"New value: +"An id from search: person:<handle>, organization:<handle>, fighter:<slug> or parcel:<jurisdiction>/<apn>"fetch1 field changedInput schema / properties / id / maxLengthPrevious value: -173New value: +257search2 fields changedInput schema / properties / query / descriptionPrevious value: -"A person's, an organization's or a fighter's name, or the first characters of it"New value: +"A person's, an organization's or a fighter's name, or the first characters of it (at most 200 characters)"Input schema / properties / query / maxLengthPrevious value: -200New value: +400fetchsearchfind_subjectget_subjectfind_fighterget_event_cardget_fighter_recordFight API MCP: UFC, PFL, BKFC, RIZIN, OKTAGON 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.
