UFCalendar Fight API — MMA MCP server

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the burden is lower. The description adds useful behavioral context: it aggregates both fighters, conditionally returns a booked bout 'if one exists', and includes model-generated win probability, which conveys that the result is a computed comparison rather than a static record.

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 a single information-dense sentence with the core verb and resource front-loaded ('Head-to-head in one call'). Every clause corresponds to a distinct output category, and the final 'tale-of-the-tape tool' metaphor is short and memorable without padding.

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 serves as the return contract, and it is thorough: it covers bios, career statistics, strike/position data, win streaks, previous meetings, common opponents, bout status, model probability, and ratings. Combined with the fully documented parameters, an agent has everything needed to invoke the tool 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?

Schema description coverage is 100%, with both a and b documented as fighter slugs or numeric ids and b constrained to differ from a. The description adds no additional parameter semantics, but it does not need to because the schema already carries the full meaning.

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 'Head-to-head in one call', making the comparison function explicit, and enumerates the exact resources returned (bios, stats, meetings, common opponents, bout, probability, ratings). The closing 'tale-of-the-tape tool' reinforces its distinct identity versus single-fighter getters like get_fighter.

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 phrase 'Head-to-head in one call' makes the intended use case clear: use this when both fighters need to be compared in a single request. It does not explicitly name alternatives or state when not to use it, but the context is sufficient to avoid confusion with get_fighter or search_fighters.

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

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

Annotations provide idempotentHint and destructiveHint, but the description adds critical operational detail: the signing secret is returned only once and must be stored before the reply is discarded, and there is a hard cap of 3 active endpoints. It also clarifies the 'odds moved' trigger precisely and notes the information is not betting advice. This goes well beyond annotations without contradicting them.

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 a single, dense sentence that packs purpose, event list, trigger definition, secret handling, and endpoint limit. It is front-loaded with the action and scope. While long, every clause adds value and there is no filler. Slightly less concise than ideal but still well structured.

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 registration tool with no output schema, the description covers the essential operational facts: what it does, what events are available, the one-time secret, and the account limit. It does not detail authentication or the exact request format, but those are typically handled by the schema or external docs. Overall, it is sufficiently complete for an agent to call it 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?

Schema coverage is 100%, so both parameters (url and events) are already documented in the schema. The description does not add extra meaning beyond what the schema provides; it merely reiterates the event types in narrative form. Baseline of 3 is appropriate since the schema carries the semantic load.

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 the action ('Register an https endpoint') and the resource (webhooks), enumerates the specific event types with a precise definition of 'odds moved'. It is immediately distinguishable from sibling tools like delete_webhook_endpoint and list_webhook_endpoints by its unique verb and 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 implies the use case (setting up a new webhook endpoint) and even states an operational limit (at most 3 active endpoints), but it does not explicitly contrast with alternatives or state when to prefer delete_webhook_endpoint or list_webhook_endpoints. The guidance is adequate but not explicit.

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

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

Beyond the destructiveHint annotation, the description adds critical behavioral detail: removal is permanent, deliveries stop, and delivery history is dropped. This fully warns the agent about the consequences and scope before invocation.

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?

Two short sentences convey purpose, scope, side effects, and irreversibility with no filler. The most important qualifier ('permanently') is front-loaded.

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 destructive tool with annotations, the description covers what, scope, and consequences. The only minor omission is the response shape (e.g., success status or deleted endpoint), but this is not essential for a simple delete invocation.

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 only parameter, endpoint_id, is already described in the schema with source, type, and format. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies because schema coverage is 100%.

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?

Description names a specific verb ('remove') and resource ('one webhook endpoint') and adds that it is permanent and scoped to the calling account. This clearly distinguishes deletion from sibling tools like create_webhook_endpoint, list_webhook_endpoints, and rotate_webhook_secret.

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 apparent: call this when you need to stop deliveries and permanently delete an endpoint. It doesn't explicitly list alternatives or exclusions, but the destructive, one-shot purpose is clearly conveyed and no other sibling tool provides this capability.

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

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

Annotations already carry readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral traits: newest-first default ordering, a mandatory narrowing filter, a 25-row page size, and critically a 10-page depth cap (250-row ceiling). Disclosing the depth cap is exactly the kind of trait that prevents an agent from naively paging forever.

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 sentences, each earning its place: positioning statement, filter inventory, motivating example, and operational constraints. The most decision-relevant fact (last/first/most-recent niche) is front-loaded, and the pagination/filter constraints close the description efficiently with zero 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 12-parameter search tool with no output schema, the description covers intent, all search dimensions, default ordering, the required-filter rule, and pagination limits — enough to call it correctly. The main gap is the cryptic scope phrase 'UFCalendar's launch promotions,' which is unexplained and could confuse an agent about what data corpus is being searched.

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 descriptions on all 12 parameters and documented enums (method's ko/sub/dec/finish meanings are already in the schema), so the baseline of 3 applies. The description's filter list maps to but does not enrich individual parameters; the only added semantic is the cross-parameter 'at least one narrowing filter required' rule, which is already credited under usage guidelines.

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?

Names a specific verb and resource ('search completed bouts') plus every filter dimension (method, division, fighter, winner, title/main-event only, date range), and stakes out a distinct niche: 'THE tool for last/first/most-recent questions.' That positioning clearly separates it from siblings like get_fight (single bout) or list_events (schedule).

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?

Gives an explicit when-to-use via a concrete query ('the last title fight to end by knockout') and an explicit when-not-to-alternative ('never page the schedule for it'), plus the operational constraint that at least one narrowing filter is required. It stops short of a full 5 because no sibling tool is named by name — the agent has to infer the exact alternatives (list_events, get_event_card) from 'the schedule.'

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

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

The description adds substantial behavior beyond annotations: it discloses Markdown formatting, stripping of client widgets, language fallback to English, and the betting-editorial exclusion. Since the annotations already mark it read-only/idempotent/non-destructive, this extra context gives a clear picture of what the call will return and transform.

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?

A single dense sentence communicates the resource, key fields, output format, localization behavior, and an important content exclusion with no filler. The betting-editorial note earns its place and does not bloat the definition.

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?

Despite having no output schema, the description enumerates the expected content fields and transformations, which is sufficient for most agents to understand the return shape. It does not detail error/not-found behavior or exact property names, but this is a low-complexity, two-parameter tool and the description is still quite complete.

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%, with slug documented as coming from search_articles and locale fully enumerated. The tool description adds only general context ('by slug', language fallback) rather than parameter-specific meaning, so the schema carries the load and baseline 3 applies.

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?

States the exact resource ('One UFCalendar article') and retrieval key ('by slug'), then enumerates the returned fields and localization behavior. This is specific enough to distinguish from sibling search_articles, which is a search-oriented lookup.

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 implies the tool is for fetching a single article once a slug is known, and the slug parameter's schema says it comes from search_articles. However, it never explicitly states when to choose this tool over alternatives, nor does it spell out when-not scenarios beyond the betting-editorial exclusion.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds a useful behavioral detail: country filtering includes the worldwide row in the result. 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?

Two compact sentences with the core behavior front-loaded and no filler. Every word earns its place.

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 read-only lookup tool with rich schema and annotations, the description is nearly complete: it names the return fields and the special worldwide-row behavior. It does not explain the org parameter, but that is fully documented in the schema.

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 documents all three parameters. The description repeats country behavior but adds no new meaning beyond the schema, so baseline 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 states what the tool returns ('who airs one promotion in each country: provider, kind and link') and how to scope it. It is more specific than the title, but it does not explicitly differentiate from the sibling how_to_watch tool.

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 gives clear usage context: pass a country code to narrow to that market plus the worldwide row. It does not state when to prefer this over alternatives, but the input schema's series note hints at how_to_watch for single events.

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

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

Annotations already mark the operation as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it returns URL templates only, never the caller's credential, and requires a human to paste the finished URL into a calendar app. This supplements the annotation profile without contradicting it.

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?

Two dense sentences with no wasted words. The core output and the API-key placeholder behavior are front-loaded, and the credential-safety note earns its place.

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 read-only tool, the description fully explains what is returned and the crucial detail that credentials are not exposed. The annotations cover safety, and the description covers output semantics, so nothing essential is missing despite the lack of an output schema.

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% and the single 'org' parameter is fully documented with an enum. The description adds only the context that the URLs are for one promotion and that the API key placeholder appears in the templates, providing minimal new parameter-level 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?

States a specific verb ('get'), resource ('ICS calendar feed URL templates'), and scope ('for one promotion'), and enumerates the three granularities (per event, per card section, per bout). This clearly distinguishes it from other get_* tools even without reading their schemas.

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 implies usage by identifying the resource and promotion scope, but it does not explicitly say when to choose this tool over a sibling like get_bulk_snapshot_url, nor does it offer exclusions. Usage guidance is present but only implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral context by specifying that the response includes the division and the snapshot date the board was published, and that omitting filters returns all promotions. This goes beyond the schema and annotations, giving an agent a clearer expectation of the output—though it does not cover pagination 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundant words. The purpose is front-loaded, followed by a concise parameter note. Every sentence earns its place with 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?

For a simple read-only tool with two optional parameters and no output schema, the description is largely sufficient. It states what data is returned (champions, division, snapshot date) and how to filter. It does not mention pagination, limits, or error cases, but for this scope those are minor omissions. The lack of an output schema makes the return description valuable, and it is present.

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 enhances the parameters by providing concrete examples ('ufc', 'lightweight') and clarifying the optionality and 'and/or' combination logic. It also explains the effect of omitting filters ('narrow it'), which is not explicitly stated in the schema descriptions. This adds value 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 exactly what the tool returns: 'Every current champion across the promotions the API covers, with the division and the snapshot date the board was published.' This is a specific verb-resource pair that clearly distinguishes it from siblings like get_rankings or get_division, which cover different data.

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 parameter usage guidance ('Pass org ... and/or division ... to narrow it') but never explains when to choose this tool over alternatives. It does not mention any exclusions or conditions that would route an agent to a sibling like get_rankings or get_division. The usage context is implied by the tool name, but explicit guidance is absent.

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

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

Beyond the readOnly/idempotent/destructive annotations, the description adds useful behavioral context: rankings appear only when the promotion publishes them, and the roster is ordered by recency. It also clarifies that bouts, results, and roster are included in one response, though it does not describe response structure or pagination.

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 two sentences, front-loads the core scope, and then compactly lists the returned components. Every phrase earns its place, and the closing sentence usefully frames the tool as the one-call division-page answer.

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 read-only getter with two enum-constrained parameters, the description tells the caller what content to expect and in what general shape. Without an output schema, a slightly more explicit statement about response structure or ordering would make it fully complete, but nothing essential for invoking it 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?

Both parameters already have full schema descriptions and enums, so the schema carries most of the semantic weight. The description adds only the conceptual framing of “one promotion” and “one weight class,” which reinforces the params but provides no new syntax or constraints.

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 single promotion/weight-class division page and enumerates its contents: rankings, upcoming bouts, recent results, and active roster. It is easy to distinguish from granular tools like get_rankings or get_fight, though it lacks an explicit verb in the body and relies on the title for the action.

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 phrase “The division-page answer in one call” implies this is the aggregate endpoint for a division overview, and the enumerated components suggest when it should be used. However, there is no explicit when-to-use or when-not-to-use guidance and no named alternative tool.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds valuable behavioral context: results are included only 'when the card has been fought,' estimated start times are 'estimates, not a schedule' and 're-anchored on each completed bout,' and odds are 'information only, not betting advice.' These caveats go beyond the annotations and help the agent set expectations.

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?

Two sentences with no filler. The primary purpose and return details are front-loaded, and the include options are explained efficiently. Every word contributes value.

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 adequately enumerates all expected response components and the conditional inclusion of results. The conditional behavior and the include parameter effects are covered. For a single-event read tool with safe annotations, nothing an agent needs to invoke it correctly 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?

Schema coverage is 100%, so both parameters are documented in the schema. The description adds extra nuance by explaining what the include values do in plain language and clarifying the default return payload ('complete bout order, both corners, venue, broadcast listings and results'). This enriches understanding beyond the schema's bare descriptions, justifying a score above the baseline 3.

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 the verb 'Fetch' and the resource 'one event by slug or id' and enumerates the full card contents: 'complete bout order, both corners, venue, broadcast listings and results.' This distinguishes it from sibling tools like get_fight, get_event_odds, and get_event_live, which target narrower aspects.

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 implies when to use the tool (to get a comprehensive event card) and explains the include parameter options, but it does not explicitly name alternatives or provide when-not-to-use conditions. The context is clear enough, but no exclusions are stated, 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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: results are newest-first and the log covers changes like bouts added, opponents swapped, and fighter profiles merged.

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 a single, well-structured sentence with no filler. The core concept is front-loaded ('audit trail'), and the em-dash list efficiently communicates scope without over-specifying.

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?

The tool is simple: one required parameter, read-only behavior, and rich annotations. The description provides enough context for selection and invocation, though it omits details about the response shape and any pagination or history-retention limits.

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%, and the schema already explains that 'event' accepts an event slug or numeric id. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.

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: retrieving an event's audit trail/change log. It distinguishes itself from siblings like get_event_card by focusing on historical changes rather than current state, and even enumerates example change types.

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 phrase 'audit trail' implies when to use the tool, but there is no explicit statement of when to prefer it over alternatives such as get_event_card. The usage context is clear but left to inference.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds meaningful context: it discloses that unpriced bouts return nulls, book identities are never exposed, and it lists the exact data points (current, opening, closing lines and market movement with book counts). This goes beyond the annotation hints and helps the agent set expectations.

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 a single, information-dense sentence (plus a short disclaimer). It front-loads the core purpose and then lists the key output components. There is no redundancy or wasted words, though it could be slightly tighter by trimming 'Information only, not betting advice' into the same sentence, but it is still efficient.

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 must explain what the agent will receive, and it does: current/opening/closing lines, market movement, book counts, nulls for unpriced bouts, and the policy on book identities. It also includes a usage disclaimer. For a single-parameter read-only tool, this is complete enough for an agent to invoke it 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?

Schema description coverage is 100% for the single 'event' parameter, which already explains it accepts a slug or numeric id. The tool description does not elaborate on the parameter or add syntax details, so it adds no extra meaning. Baseline 3 is appropriate given the schema fully documents the parameter.

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: 'consensus odds line for every bout on one card.' It clearly distinguishes itself from sibling tools like get_fight_odds (single bout) and get_odds_history (history) by focusing on the card-level consensus line in card order.

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 implies usage for obtaining odds across an entire card, and it adds a caution that it is 'Information only, not betting advice.' However, it does not explicitly name alternatives or state when not to use it (e.g., for a single fight, use get_fight_odds). The scope is clear, but explicit routing to siblings is missing.

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

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

Annotations already mark the tool as read-only and idempotent. The description adds useful behavioral context by stating the storylines are computed from the record and detailing what categories are included, which helps the agent set expectations about the output beyond the annotation flags.

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 then enumerates concrete storyline types. It is one long sentence but every clause adds meaningful content, with no redundant 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 one well-documented parameter and no output schema, the description does a good job of explaining what the response will contain. It could be slightly more explicit about the exact return shape, such as whether it is a list of strings, but the outlined categories make the expected content clear.

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 single parameter is already fully documented in the schema as an event slug or numeric id, so the description does not need to repeat it. The description adds no additional parameter-level detail, but the schema coverage is 100%, so the baseline of 3 applies.

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 the tool returns the talking points for one event card, computed from the record. It enumerates specific storyline categories, which makes the tool's purpose concrete and distinguishes it from siblings like get_event_card or get_event_live.

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 use case is implied: call this when you need narrative or storyline context for a card, rather than the card itself. However, there is no explicit guidance about when not to use it or how it differs from sibling tools, so the agent must infer this.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral detail beyond the schema, such as the odds being the UFCalendar consensus line and the closing line once settled, plus an information-only disclaimer.

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?

Single sentence, front-loaded with the core verb and resource, then a compact enumeration of optional includes. Every phrase earns its place, including the parenthetical odds clarification, with no filler or repetition.

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 by-id fetch with one required parameter and optional include blocks, the description covers what the tool returns and the meaning of each include. It does not describe error behavior or explicitly mention that multiple includes can be combined, but the schema already communicates the parameter structure.

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, but the description adds real meaning by explaining what each include value returns: stats as per-fight totals, rounds as round-by-round statistics, scorecards as official judges' cards, and odds as the consensus line. This goes beyond the enum names in 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?

Description states a precise action: 'Fetch one bout by id,' identifying both the resource (bout/fight) and the lookup mechanism. This clearly distinguishes it from sibling search tools like find_fights and from event-level tools like get_event_card.

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 makes it clear this is the tool to use when you already have a bout id and want the bout record plus optional related blocks. It does not explicitly exclude alternatives such as find_fights or get_fight_odds, but the by-id framing gives sufficient contextual guidance for a simple retrieval tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond that: it discloses that the response always carries next_fight and last_fight, explains what each include block returns (e.g., bonuses = UFC bonus ledger, credentials = sourced/confidence-graded pedigree), and mentions 'freely licensed portraits'. This goes beyond a simple read-only claim.

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 definition is compact: a front-loaded first sentence states the core action and default content, and a second sentence lists include options. The second sentence is a bit dense with several comma-separated options, but each clause adds necessary semantics. No wasted words; a clean bulleted list would be slightly more scannable, hence not a 5.

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?

Given the tool's simplicity (3 params, no output schema), the description adequately covers how to call it: the fighter parameter, all include options, and the history_limit are described or implied. It also tells the agent what the response will always contain (next_fight/last_fight) and default fields. Missing pieces are explicit differentiation from sibling tools and any details about pagination or response format, but these are minor for a read-only fetch.

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%: fighter, include, and history_limit are all described. The description adds extra meaning to the include array by explaining what each enum value returns (e.g., history = full multi-promotion career timeline, credentials = pedigree/gyms/coaches with sources), which the schema does not fully capture. Since coverage is high, the baseline is 3, and this extra context 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?

Description states a specific verb ('Fetch') and resource ('one fighter'), with query mechanism (slug or id), and lists what is returned (bio, record, career statistics, portraits). It clearly conveys the scope but does not explicitly distinguish itself from siblings like search_fighters or get_fight, so it falls short of a 5.

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 implies when to use this tool (when you have a fighter slug or id) by describing the required fighter parameter. However, it provides no explicit guidance about alternatives, such as using search_fighters when the slug/id is unknown or compare_fighters for head-to-head comparison. No when-not-to-use context is given.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavior beyond this: it guarantees 'Book identities are never exposed', states the data lifecycle (opening, current, closing once settled), and disclaims 'Information only, not betting advice.' It does not cover auth requirements or rate limits, but with annotations covering safety, this adds substantial context.

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?

One dense sentence, front-loaded with the core resource, and each clause adds concrete information. There is no filler or redundancy; every part earns its place.

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 read-only tool with no output schema, the description explains what the output contains: current, opening, closing lines, movement, and per-point price/probability details. It also provides the source of fight_id via schema. This is complete enough for an agent to call and interpret the result 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?

Schema coverage is 100%, and the schema already describes fight_id as a bout id from an event card. The description does not add any further parameter-specific semantics, so a baseline 3 applies.

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?

States the resource (consensus odds line), scope (one bout), and enumerates the data elements included. It distinguishes itself from sibling tools like get_event_odds by explicitly saying 'for one bout', so an agent can tell it apart without opening schemas.

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 implies usage for a single bout's odds, but it does not explicitly name alternatives or exclusion conditions. An agent must infer when to use get_event_odds or get_odds_history based on sibling names; no explicit when-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by specifying the aggregation scope (career totals, date range, promotions worked) and the relationship to list_judges rows, which is useful 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 a single dense sentence that front-loads the core purpose, enumerates the data points, and ends with the sibling routing. Every clause earns its place with 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?

For a single-parameter read-only tool with full schema coverage and clear sibling routing, the description is complete. The output shape is clarified by the list_judges row reference, and the alternative tool is named for the detailed cards.

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% and the schema already describes judge_id as 'Judge id, from list_judges. Integer or numeric string.' The description reinforces the source of the id by mentioning list_judges, which adds a small amount of context 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 ('aggregates') and resource ('one official's career') and enumerates the exact data points returned. It also distinguishes itself from the sibling get_judge_scorecards by explicitly saying to use that tool for the cards themselves.

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 explicitly says 'use get_judge_scorecards for the cards themselves,' which is a clear when-not-to-use and alternative routing. It also notes the output shape matches list_judges rows, giving the agent a clear expectation of the result format.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat those. It adds valuable behavioral context: ordering ('newest first'), output fields (per-round points, totals, deductions, flags for dissents/split panels, colleague totals), and scope ('Commission records only'). This goes beyond annotations and informs the caller about what to expect. No contradiction found.

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 three concise sentences, front-loaded with the core purpose. It wastes no words and packs relevant detail about output contents. It is slightly dense but remains readable. A minor improvement could be to separate the output fields from the scope note, but overall it is well-structured and efficient.

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 read-only list endpoint with no output schema, the description provides a fairly complete picture of the response (per-round points, totals, decision type, deductions, flags, colleague totals). It also covers ordering and scope. However, it does not explicitly mention pagination or how limit/cursor affect results, which could be considered standard but are not clarified. Given the annotations and the tool's simplicity, this is adequately complete, though a brief note on pagination would push it to 5.

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 only 33%: the description explains judge_id ('from list_judges') but omits any explanation for the limit and cursor parameters. These are not self-evident to a generic agent (cursor especially), and the description does not compensate for the low coverage. The description adds value only for the required parameter, leaving two optional parameters undefined. Given the low coverage, a more thorough explanation was needed.

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 the specific resource (a judge's official scorecards) and the exact content (per-round points, totals, decision type, deductions). It also adds critical scope ('Commission records only') and distinguishes from siblings like get_judge (judge metadata) and list_judges (list of judges) by describing unique fields and flags. The verb 'get' plus resource makes the purpose 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 implies when to use (when you need a specific judge's scorecards) but does not explicitly compare with alternatives or state when not to use. It mentions 'From list_judges' for the judge_id parameter, hinting at a workflow, but lacks explicit guidance like 'For judge profiles use get_judge instead.' The usage context is partially implied but not fully spelled out.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds behavioral context beyond that: it is per-promotion, ranked, and includes the sample size behind each value, which helps the agent understand what the response represents.

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 a single tightly packed sentence that front-loads the core purpose and then adds filters and output behavior efficiently. Every phrase adds information, and the 'and more' avoids an unwieldy metric list.

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?

The description, combined with a fully documented schema, gives the agent enough to call the tool correctly: what it returns, how it is scoped, and what filters narrow it. There is no output schema, but mentioning ranking and sample size covers the most important response characteristics.

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 documents all parameters. The description adds some grouping context—'optionally narrowed to a division, a country or active fighters'—but does not materially extend the meaning of org, metric, limit, or enums beyond what the schema provides.

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 verb and resource: getting 'one statistical leaderboard for one promotion' from UFCalendar's Record Book rollup. It enumerates board types and metric examples, so the tool is clearly distinguishable from siblings like get_record_book or get_rankings without opening the schema.

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 provides clear context: use this when you need a ranked, single-metric leaderboard for a promotion, optionally filtered by division, country, or active fighters. It does not explicitly name alternatives or when-not-to-use conditions, but the context is strong enough for an agent to route correctly.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context: the engine relies on rankings, Power Index, and form, and omits the website's Fight DNA factor, which explains why scores may differ. This goes beyond 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?

Three sentences, each earning its place: what the board is, what it is not, and a caveat about score differences. It is slightly wordy but still focused and front-loaded with the core purpose.

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?

Given the simple parameter set and full schema coverage, the description gives enough conceptual context for an agent to invoke the tool correctly. There is no output schema, so a bit more detail about the returned structure could improve completeness, but the core behavior is clear.

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 documents org, limit, and division thoroughly. The description adds minimal parameter-specific meaning beyond 'per division or across the roster,' which aligns with division, but does not materially compensate for anything missing.

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?

States a specific verb and resource: it returns the 'matchmaker board' — fights worth making, scored on explicit criteria. It also differentiates itself from booked-fight lists, which distinguishes it from siblings like find_fights.

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 establishes clear context: this is for hypothetical matchups within one promotion, per division or across the roster. It includes a negative boundary ('not a list of booked bouts') but stops short of naming alternative tools or explicit when-to-use/when-not-to-use conditions.

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

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

Annotations already cover read-only, idempotent, non-destructive. The description adds valuable specifics: the 'next' definition (soonest not finished), the skip_series default behavior with specific series names, and that include_card adds bout list in the same metered call (cost implication). No contradiction, and it enriches 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?

Two sentences. The first defines the core function and scoping; the second explains the UFC-specific exception and the optional flag. Efficient, front-loaded with the primary purpose, and every detail is relevant. 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?

Given no output schema, the description explains what changes with include_card (bout order, venue, broadcasts) and clarifies the default behavior of skip_series. The sibling list includes get_event_card which it references. This gives an agent all it needs to call correctly without further lookups.

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 covers all three parameters at 100%. The description clarifies the behavior of skip_series (which series are skipped and when) and include_card (returns full bout order, venue, broadcasts). While org is clear in schema, the description specifies omitting it for cross-promotion. This adds meaning beyond the schema 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 clearly states the tool returns the single next upcoming card (soonest unfinished event), with an optional scope (one promotion or all). It explicitly distinguishes from siblings like get_event_card (full bout list) and list_events (listing multiple events), making it unambiguous which tool to use.

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 explicit conditions: when to omit org (across all promotions), how to handle UFC developmental series (skip by default, include with skip_series=false), and when to use include_card for the full bout list. It also implicitly tells when not to use this tool—when you need a specific event or list, use alternatives like get_event_card or list_events.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavioral context: points are stored only when the line moves, and it includes an 'information only, not betting advice' disclaimer. 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?

Three sentences, zero waste. The primary result (line-movement series, oldest first, bookmaker counts) is front-loaded, followed by data-sparsity and usage notes. Every sentence earns its place.

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 read-only, paginated list tool with no output schema, the description covers the core return shape, ordering, filtering, pagination, data-sparsity behavior, and plan requirement. Nothing essential is missing for correct invocation.

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 all five parameters are documented. The description references from/to and cursor but does not add meaning beyond what the schema provides. The baseline of 3 applies because the schema already handles parameter meaning.

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 the tool returns every UFCalendar consensus odds point for one bout, oldest first, with the number of sportsbooks backing each point. This distinguishes it from siblings like get_fight_odds, which presumably return current odds, by focusing on the historical line-movement series.

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 mentions narrowing with from/to dates and cursor pagination, which guides invocation. It also notes 'Pro plans and up' as a prerequisite. However, it does not explicitly contrast with current-odds tools or state when to avoid using it, so the usage context is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is well covered. The description adds meaningful context beyond that: the returned capability flags, the note that odds are information only and not betting advice, and the credential distinction relative to list_orgs.

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?

One dense sentence front-loads the action, resource, and parameter, then lists the output fields and the key caveat. No filler or redundant phrasing is present.

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, read-only tool with rich annotations and no output schema, the description covers the return fields, the capability flags, the odds caveat, and the relationship to list_orgs. Nothing an agent needs to invoke it correctly 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 schema fully documents the single parameter with an enum and 'Promotion slug' as its description, so coverage is 100%. The description repeats the enum values but does not add semantic meaning beyond what the schema already provides, which matches the baseline of 3.

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: 'Fetch one promotion by slug,' and enumerates the exact fields returned. It also names the sibling list_orgs for contrast, making the tool's purpose easy to distinguish.

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 explicitly references list_orgs and notes that it returns the same rows for every promotion without a credential, giving useful context about when the broader endpoint might be appropriate. It stops short of an explicit 'use X when / use Y when' rule, but the guidance is clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by clarifying the data source (own pick'em game, not external market or forecast) and the output layout (card order), which is 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?

The description is two sentences with no filler. The core purpose is front-loaded in the first sentence, and the second sentence adds a clarifying distinction about the data source. Every word earns its place.

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 read-only, single-parameter tool with no output schema, the description fully covers what an agent needs: it explains what data is returned (picks, totals, percentages, card order) and its provenance. No critical information is missing for correct invocation.

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% and the sole parameter `event` is described as 'Event slug (preferred) or numeric id.' The description does not add any additional parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.

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: retrieving UFCalendar community pick'em splits for each bout on a card, with picks for each corner, total, and percentage, in card order. It explicitly contrasts with markets and forecasts, distinguishing it from sibling prediction tools like get_predictions_upcoming.

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 implies when to use the tool (when you need community pick'em sentiment) and provides exclusions ('not a market and not a forecast'), but it does not explicitly name alternative tools or conditions for choosing them over this one. It gives context but lacks direct guidance on alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating no credential is required and enumerating the specific content (quotas, limits, trial terms), but it does not go further into response format or data source details.

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?

Two concise sentences with no filler. The main action and content list are front-loaded, and the practical use-case statement ('answers what does this cost without a credential') adds value without redundancy.

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 parameterless, read-only, idempotent tool, the description fully covers what the agent needs to know: what the tool lists, the quota-related content, and that no credential is required. No output schema exists, but the described return content is simple enough to infer.

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 tool has zero parameters, so the schema is already complete and there is no parameter ambiguity. The description further clarifies that no credential is needed, which effectively communicates the absence of auth-related inputs.

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 verb ('List') and a specific resource (UFCalendar Fight API plans), and details exactly what is returned: monthly request quotas, per-minute limits, and no-card trial terms. It also distinguishes this from costing/credential-related use cases, making it clear among siblings like get_usage.

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 a clear use case: answer 'what does this cost' without a credential. It implies this tool is appropriate when no authentication is available and the agent needs plan/quotas information, though it does not explicitly name alternative 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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the board is 'refreshed hourly' and includes 'peak rating and fights rated.' 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?

Two sentences with no filler. The first sentence front-loads the core definition and the second gives actionable parameter guidance. Every clause earns its place.

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 read-only board tool with five parameters, the description covers the main usage patterns and the promotion scope. It does not explain limit behavior or return shape, but the schema covers required org, days, and view enums, and annotations cover the safety profile.

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 80%, so the schema already documents most parameters. The description adds some usage color for view and division, but it largely restates what the schema says and does not clarify the undocumented limit parameter or the days snapping behavior.

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 (UFCalendar Power Index board), the scope (one promotion), and the distinguishing nature ('our own rating engine'). It also names the view modes, making it easy to tell apart from sibling tools like get_rankings or get_leaderboard.

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 concrete usage guidance for view and division parameters ('Pass view=movers for the biggest risers...'), but it does not explicitly state when to use this tool versus alternatives like get_rankings or get_leaderboard. 'Our own rating engine' hints at differentiation but no exclusions or when-not-to-use guidance is provided.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond those: data is published about three weeks out and repriced at least weekly, and the corner-stamping guarantee prevents mismatched fighter/probability pairs. The betting disclaimer is also extra transparency.

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 three sentences, front-loads the core purpose, and each sentence adds distinct value: scope, freshness/repricing, correctness guarantee, parameter usage, and disclaimer. No wasted words or redundant restatements of the title.

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?

Given the simple parameter surface, the strong annotations, and the absence of an output schema, the description provides enough context for a correct invocation. It covers scope, freshness, integrity, and the optional narrowing parameter. It does not describe the exact return shape, but that is a minor gap for such a focused read-only tool.

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%, with the event parameter already documented as an optional slug or numeric id to narrow to one card. The description repeats the same instruction ('Pass event= to narrow to one card') without adding meaning beyond the schema, so the baseline of 3 applies.

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 tool as providing UFCalendar model win probabilities specifically for upcoming UFC bouts, with additional details about publication timing and repricing. This distinguishes it from sibling tools like find_fights or get_event_card which serve different purposes.

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 clear context: this is for upcoming UFC bouts with model predictions, and it explicitly instructs to pass event= to narrow to one card or omit for all upcoming bouts. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for selection.

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

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

With readOnlyHint/idempotentHint/destructiveHint already provided, the description adds valuable behavioral semantics: point-in-time reads, rank 0 as champion, movement vs previous snapshot, is_new for debuts, and meta containing previous/next snapshot dates. 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?

Three dense sentences, with the core purpose and point-in-time nature front-loaded. No filler; every clause contributes distinct information. A model of conciseness.

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?

Given there is no output schema, the description supplies key output semantics (entry movement, is_new, meta snapshot dates) and parameter behavior. It doesn't spell out the exact response envelope or pagination, but for a read-only fetching tool this is close to complete.

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 already documents all 4 parameters (100% coverage), so baseline is 3. The description adds meaning beyond the schema: the date parameter is for point-in-time reads, division narrows the board, and board defaults to official. This elevates it to 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 states a specific verb+resource: reading the official rankings board for one promotion, with point-in-time semantics. It distinguishes this from generic leaderboards or champion lists by emphasizing 'official rankings board' and historical date reads. The title and description align.

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 when to use the tool: when you need the official rankings board for a promotion, optionally as of a specific date and narrowed by division. It does not explicitly name sibling alternatives like get_leaderboard or get_champions, so it misses the exclusionary guidance for a 5, but the context is unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: it notes the payload size (~140 KB at 10 rows) and the default of 3 rows per board, which helps an agent understand performance implications. It also clarifies that 'active' means a bout in the last ~18 months, which is a behavioral definition not in the schema. This exceeds the baseline for annotation-covered tools.

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 two sentences with no waste. The first sentence front-loads the core purpose and the key differentiator (all-time and single-night records an agent quotes). The second sentence efficiently lists the narrowing dimensions. Every phrase earns its place, and the structure is scannable.

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 read-only, idempotent tool with 100% schema coverage and no output schema, the description is nearly complete. It covers what the tool returns (top rows of every leaderboard grouped by category), the key parameters, and a performance note. The only minor gap is that it doesn't explicitly state the return format (e.g., JSON structure), but since there's no output schema and the description says 'the top rows of every leaderboard,' an agent can infer the shape. The performance note about payload size is a strong addition.

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 documents all 6 parameters thoroughly. The description adds value by explaining the default top=3 and the payload size trade-off, and by clarifying the 'active' population definition. It also groups the scope options into 'one kind of board' and notes the country/active exclusion, which helps an agent understand parameter interactions 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 clearly states the tool's purpose: retrieving the Record Book for one promotion in a single call, with the top rows of every leaderboard grouped by category. It distinguishes itself from siblings like get_leaderboard by emphasizing the all-time and single-night records an agent quotes, and the scope options (division, country, active fighters) add specificity.

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 implies when to use this tool: when an agent needs the full record book for a promotion, including all-time and single-night records. It doesn't explicitly name alternatives like get_leaderboard or compare_fighters, but the context signals and sibling list suggest it's the comprehensive record-book endpoint. The description could be stronger with an explicit 'use this instead of get_leaderboard when you need the whole book' statement, but the scope and grouping language provides clear context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by listing exact returned values and the calling-account scope, but it does not disclose any further behavioral traits such as response format or rate-limit details.

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?

A single, well-structured sentence that packs all key return fields without filler. The trial-specific note is appended cleanly without disturbing the main list.

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 zero-parameter, read-only usage endpoint with no output schema, the description is complete: it names every important value an agent would need to decide whether to call it and what to expect. Nothing critical appears 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 tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to explain. The description adds useful context by implying the account identity is derived from the caller rather than a parameter.

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 enumerates the specific usage metrics returned: requests used, plan limit, per-minute limit, reset time, and trial end. It is distinct enough from sibling tools by focusing on account-wide API usage, though it does not explicitly contrast itself with get_plans or other resource getters.

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?

No guidance is given about when to call this tool versus alternatives, and no exclusions or prerequisites are mentioned. The intended use is implied by the content, but the description does not state it explicitly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by specifying the exact payload fields returned, such as name, city, coordinates, and IANA time zone, which is especially important given no output schema is provided.

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?

A single, front-loaded sentence that immediately states the action and the returned fields. There is no filler or redundant explanation.

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?

The tool is low-complexity with one required parameter, full schema coverage, and annotations covering safety. The description lists all relevant return fields, which is sufficient since no output schema exists.

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% and the venue_id parameter is already described as 'Venue id. Integer or numeric string.' The description only repeats 'id' without adding format details or additional parameter semantics, so it meets 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?

The description states a specific verb ('Fetch'), a specific resource ('one venue by id'), and explicitly lists the fields returned. This clearly distinguishes it from broader tools like search or list_events.

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 indicates this tool is for retrieving a single venue when its id is known. It does not name alternatives or exclusions, but for a simple get-by-id tool the use context is clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral nuance beyond the schema: 'upcoming cards on top, then the history' discloses a special ordering behavior that the schema's order parameter does not fully convey. No contradictions 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?

Two sentences pack the core purpose, ordering behavior, and the crucial reference to list_events. There is zero fluff or redundant restatement; the most distinctive features are front-loaded.

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?

The description is complete for a scoped read-only list tool given the schema and annotations. It mentions the custom ordering, points to list_events for filters and response shape, and the schema documents all parameters well. There is no output schema, but the reference to list_events (whose schema is presumably accessible) fills that gap. Minor ambiguities like the exact meaning of 'covered' and the interplay between ordering and the 'order' parameter prevent a perfect score.

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 86% (high), so the baseline is 3. The description adds no new per-parameter semantics beyond what the schema already provides; it merely points to list_events for shared filter definitions. It does not explain limit or pagination beyond what the schema's cursor description says, but the schema mostly carries the load.

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—listing every covered event at one venue—and distinguishes itself from the closely related sibling list_events by explicitly scoping to a single venue. The phrase 'Same filters and row shape as list_events' further clarifies what kind of tool this is and how it relates to the sibling.

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 makes the tool's purpose clear: use it for events at one venue. It references list_events for shared filters and output shape, which implies when to use this versus the broader list_events, but it does not explicitly state the exclusion condition ('use list_events when you need events across venues'). This is clear context without an explicit when-not.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the output is numeric/aggregate ('in numbers') across a fixed year and optional promotion, which is useful, but it does not describe return shape, pagination, or edge-case behavior.

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 one front-loaded sentence that starts with the core scope ('One calendar year... in numbers') and then lists specific stats. The list is long, but each item helps differentiate the tool from other get_* siblings, so it is not idle padding.

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 2-param read-only tool with no output schema, the description gives a solid idea of what the caller will get: a numeric year-in-review breakdown with events, finishes, divisions, upsets, fighters, countries, and judges. It still leaves the exact output structure implicit, but an agent can select and call it confidently.

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 year and org are already well documented. The description restates the year and promotion concepts but adds no new type, range, format, or enum semantics beyond the schema, so the baseline 3 applies.

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 makes clear that this tool returns a calendar-year aggregate summary for one promotion or all promotions, and the list of stats distinguishes it from siblings like get_leaderboard, get_record_book, or get_champions. It lacks an explicit main verb in the body, though the title supplies 'get', so it is not quite a 5.

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 phrase 'one calendar year' and 'promotion (or all covered promotions)' gives useful temporal and scoping context, so an agent can infer when this tool is appropriate. However, it does not explicitly compare against sibling stat tools or state when-not-to-use alternatives, leaving routing mostly implied.

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

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

Annotations already establish this as a read-only, idempotent, non-destructive operation. The description adds useful behavioral detail beyond the annotations by stating that it returns the URLs for authentication and which methods it explains.

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?

A single well-structured sentence that front-loads the tool's purpose, details the two covered authentication methods, and states the expected return value. No wasted words.

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 zero-parameter, informational tool, the description is complete: it tells the agent what will be explained, which authentication methods are covered, and what the tool returns. No output schema exists, but the simple return content is sufficiently described.

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 tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to clarify. The 0-parameter baseline of 4 applies because no parameter semantics are needed.

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 ('Explain how to authenticate') and clearly identifies the target resource ('UFCalendar Fight API from this MCP server'). It also distinguishes itself from all sibling data- and webhook-related tools by being the authentication-help tool.

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 makes the context clear: use this when you need to know how to authenticate, and it even enumerates the two supported methods. There are no sibling tools offering a similar alternative, so explicit when-not-to-use guidance is not necessary.

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

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

Annotations already cover read-only and idempotent behavior. The description adds meaningful behavioral detail: it merges promotion rights deals with event broadcast listings, includes provider/kind/link/worldwide row, and is series-aware so a Contender Series card uses its own deal. This goes beyond the annotations without contradicting them.

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?

Three dense sentences with no filler. The core question ('Who airs one event, country by country') is front-loaded, and every additional clause earns its place by explaining a meaningful behavioral nuance.

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 two-parameter read-only tool, the description covers the main behavior, the country filtering logic, and an important series-specific edge case. It does not describe output structure, but there is no output schema and the description already gives enough to call the tool 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value: it clarifies that the country parameter controls a market-plus-worldwide view, and it explains the series-aware behavior for the event parameter, which is not obvious from the schema alone.

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: it tells you who broadcasts one event, country by country. It also differentiates itself from siblings like get_broadcast_rights by explicitly describing the merge of promotion-level rights deals with event-level confirmed listings.

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 gives clear usage context: pass a two-letter country code to get that market plus worldwide, or omit it for every country. It does not explicitly name an alternative tool or say when not to use it, but the parameter behavior is precise enough for an agent to invoke correctly.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds genuine behavioral context beyond the annotations: newest-first ordering, a default 90-day window, and the fact that the data mirrors the webhook audit trail. There is no contradiction with 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 dense but efficient: it front-loads the core purpose ('cross-event change feed, newest first'), enumerates the change kinds in one compact list, states scope and time default, and closes with the polling-vs-webhook usage hint. No sentence or clause is wasted.

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 read-only feed with no required parameters and 80% schema coverage, the description provides enough to call it correctly: scope, change kinds, ordering, default time window, and the intended use case. Minor gaps remain: it does not describe the response shape, pagination behavior (cursor/limit), or explicitly differentiate from get_event_changes, but these are secondary for a tool whose annotations and schema already cover the essential contract.

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 80% (only limit lacks a description), so the schema already documents org, kind, since, and cursor. The description reinforces param meaning by listing change kinds in prose and stating the since default ('default the last 90 days'), and it clarifies org scope ('every covered promotion or one of them'). This is helpful but largely redundant with the schema, so it adds only marginal value.

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 resource ('cross-event change feed') and a concrete verb ('list'), then enumerates the exact change types covered: bouts added/cancelled/reinstated, opponents swapped, times/venues moved, fighter profiles merged. It also states the scope ('across every covered promotion or one of them'), which distinguishes it from event-scoped siblings like get_event_changes without opening their schemas.

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 a clear usage context: it is the change feed for polling agents, explicitly framed as 'the same audit trail webhooks deliver, for agents that poll instead.' It also implies when to use org/kind filters. However, it does not explicitly name alternatives or state when NOT to use this tool versus get_event_changes or list_events, so guidance is strong but not fully explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is known. The description adds valuable behavioral context: cursor pagination, default ordering, the meaning of status=upcoming, and the include=headline enrichment including fight results. No contradictions 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?

Four sentences, no filler. The core purpose is front-loaded, followed by default behavior, filtering options, and pagination note. Every sentence earns its place, and the structure flows logically from general to specific.

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 10-parameter read-only list tool with no output schema, the description covers defaults, filtering, pagination, and inclusion semantics. It does not describe the event object structure, but that is arguably the schema's job; given the complexity, the description is comprehensive enough for an agent to call correctly. Minor gap: no mention of how limit interacts with pagination.

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 90% (limit lacks a description), so the schema carries most parameter meaning. The description adds value by clarifying defaults (bare call = upcoming soonest-first), the archive pattern (order=desc), and the effect of include=headline (brings main event and result). This goes beyond the schema's per-parameter 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 states a specific verb ('List') and resource ('fight cards') with explicit filtering dimensions (promotion, status, date range). It clearly differentiates from siblings like get_event_card (single event) and find_fights (fight-level search) by focusing on cards as the unit. The opening sentence is 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 provides clear in-tool usage patterns (bare call returns upcoming, order=desc for archive, include=headline for main event), but it never mentions when to choose this tool over alternatives such as get_event_card or get_next_event. It implies its role as a list endpoint but does not explicitly contrast it with siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context about the returned data (career aggregates and meta.league baselines), which goes beyond the structured fields. It doesn't contradict 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 two sentences with no fluff. The main purpose and key aggregates are front-loaded, followed by filter options. Every phrase earns its place.

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 list tool with no output schema, the description explains what is returned (career aggregates and baselines) and the main filters. It doesn't detail pagination (cursor/limit) but these are standard for list endpoints and the schema provides the parameter names. Overall, an agent can call this correctly with the given information.

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 only 20% (only q is described). The description compensates by naming three filters: name, promotion, and minimum fights, which map to q, org, and min_fights. However, it omits limit and cursor, which remain undocumented in both schema and description. Since pagination is a common pattern, this is acceptable but not fully compensating.

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 the tool's purpose: a judge directory with specific career aggregates (cards turned in, rounds scored, 10-8s, split cards, lone dissents) and league-wide baselines. It also mentions filtering capabilities. This distinguishes it from single-judge tools like get_judge and scorecard-specific get_judge_scorecards.

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 implies this is for listing/searching judges rather than retrieving a single judge, but it doesn't explicitly say when to use this over get_judge or get_judge_scorecards. No explicit exclusions or alternative suggestions are given, leaving the agent to infer from context.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it exposes that the result includes per-org capability flags and that odds are a consensus line presented for information, not betting advice. This meaningfully helps an agent interpret the output.

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?

Two sentences with no filler. The first sentence states the action and scope, the second adds a necessary caveat about odds. Every sentence earns its place and the key information is front-loaded.

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 parameterless, read-only list tool with strong annotations, the description is complete: it names the resource, the scope, and the nature of the returned data. No output schema exists, but the description provides enough of the return shape for an agent to call and interpret the tool 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 tool has zero parameters and schema description coverage is 100%, so the parameter dimension is trivially satisfied. The description adds value by indicating what the returned data will contain (capability flags such as stats, rounds, rankings, and odds), which is useful context even though there are no parameters to document.

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 ('List') and resource ('promotions the UFCalendar Fight API covers') and adds the per-org capability-flag detail, so an agent can tell it is an enumeration tool rather than a single-resource lookup like get_org. However, it does not explicitly distinguish itself from the sibling get_org, and the tool name 'list_orgs' slightly mismatches the title/description using 'promotions'.

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 implies usage: use this tool when you need to know which promotions the API covers and what capabilities each has. It does not explicitly say when to prefer it over get_org or other list tools, nor does it state any exclusions, so the guidance is inferred rather than stated.

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

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

Beyond the readOnly/idempotent/destructive annotations, it discloses source scope ('commission records only'), ordering ('newest first'), output contents (all judge cards plus the dissenting judge), and epistemic stance ('Facts as filed; UFCalendar adds no verdict of its own'). 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?

Two sentences, front-loaded with the core resource, then filters, then output details and caveat. No filler; every clause adds information.

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 supplies the essentials: what records are returned, their order, their source, and the no-verdict caveat. The input schema covers parameter mechanics, and annotations cover safety, so the combined definition is sufficient for an agent to invoke it 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?

Schema coverage is 100%, so the baseline is 3. The description only restates date-range and promotion-or-all filtering already expressed in the schema; it adds no new meaning for limit, cursor, from, to, or org beyond their labels. It connects the params to the tool's intent but does not lift above 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?

Description names a specific resource ('completed bouts decided on split or majority cards') and states the output shape ('every judge's official card and the dissenting judge named'). The commission-records-only qualifier plus 'no verdict of its own' distinguishes it from broader event/fight listing and editorial tools.

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 gives clear context for invocation: only completed split/majority bouts, commission records, optional promotion or date range. It doesn't name sibling alternatives (e.g., find_fights, get_judge_scorecards) or state when not to use it, so it misses the explicit when-not/alternatives level.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond those annotations: the endpoints are 'signed', scoped to the 'calling account', and the response includes subscribed event kinds. Pagination and rate limits are not mentioned, but those are minor for this simple list operation.

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 a single focused sentence that front-loads the action and resource, then adds the two most useful qualifiers: account scope and returned event kinds. No filler or redundant phrasing.

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 zero-parameter, annotated as read-only list tool with no output schema, the description is complete enough: it states what the list contains, who it belongs to, and a key output attribute. Nothing an agent needs to call it correctly 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 has zero parameters, so the baseline is 4 and there is nothing for the description to explain. No parameter-level detail is needed.

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 verb ('List'), a specific resource ('webhook endpoints'), and a clear scope ('registered on the calling account'). It also adds the result content ('event kinds each one subscribes to'), which distinguishes it from the sibling create/delete/rotate webhook tools.

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 implies the correct use case: retrieving the account's webhook endpoint registry rather than creating, deleting, or rotating secrets. It doesn't explicitly name alternatives or exclusions, but the context is clear and no prerequisites are needed for a zero-parameter read-only list.

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

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

Goes beyond the destructiveHint annotation by specifying the exact behavioral consequence: immediate invalidation of the old secret. Also discloses that the new secret is returned only once, which is critical for the caller to handle correctly.

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?

Three concise sentences with no wasted words. The main action is front-loaded, followed immediately by the most important timing caveat and the one-time return behavior.

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?

All essential information for a one-parameter destructive tool is present: what it does, the immediate impact, the deployment order, and the one-time output behavior. No output schema is needed because the description covers the critical return characteristic.

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 documents endpoint_id, including its source and accepted integer/numeric-string formats. The description adds little parameter-specific meaning because it relies on the schema's complete coverage.

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?

States a specific action ('Replace the signing secret of one webhook endpoint') with a clear resource and scope. It is easily distinguished from the sibling create/delete tools because it is about rotating an existing endpoint's secret.

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?

Provides clear operational context by explaining that the old secret stops verifying immediately and instructing the user to update the receiver first. It does not explicitly name alternatives, but the rotation action is unique enough among the siblings that this is not a significant gap.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond those flags: it characterizes the search as 'typeahead' and clarifies that the output is a slug suitable for other tools. It does not disclose result limits or response format, but with annotations present, this is acceptable.

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?

Two compact sentences: the first defines scope and behavior, the second states the intended use. No filler, and the action is front-loaded, making it easy for an agent to parse quickly.

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 one-parameter read-only search tool, the description covers the essential invocation context: what is searched, typeahead behavior, and the purpose of the output. It omits response structure details, but that is a minor gap given the simple input and strong annotations.

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 only describes q as a string with minLength 2. The description enriches this by explaining that q is the name a user typed and that the tool converts it to a slug, adding meaning that the schema alone does not convey.

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 (search) across two resources (fighters and events) and emphasizes 'in one call', which distinguishes it from narrower sibling tools like search_fighters. The scope and action are immediately clear.

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 second sentence gives explicit usage context: use it when a user has typed a name and you need a slug for other tools. However, it does not name alternatives or state when not to use it, so it lacks the explicit exclusion/alternative guidance needed for a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavior beyond those annotations: exact return fields, ordering, locale behavior ('in any of the 13 site languages'), the fallback to English, and the exclusion of betting editorial.

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?

Three dense sentences with no filler: the first defines scope and behavior, the second states the return contract and follow-up action, and the third states the exclusion. Key facts are front-loaded and every sentence earns its place.

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?

The description is nearly complete: it covers purpose, ordering, languages, returned fields, and the next step to get_article, and the schema fully documents all parameters. A minor gap is that neither q nor tag is marked required, and the description does not state what happens if both are omitted.

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 has 100% description coverage across all five parameters, so the schema already documents each parameter. The description reinforces q and tag ('by keyword or tag') and locale ('13 site languages'), but it adds little new semantic detail beyond what the schema provides; baseline 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 opens with a specific verb and resource: 'Search UFCalendar's own editorial archive', then enumerates content types, sorting ('newest first'), and language scope. It also differentiates itself from siblings by stating that it returns metadata only and that 'Betting editorial is not served.'

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 the tool — searching UFCalendar's editorial archive by keyword or tag — and explicitly routes users to get_article for the body. It also states an exclusion (no betting editorial), but it does not enumerate when alternatives like search, search_fighters, or search_venues should be preferred.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds useful behavioral context by noting cursor-based pagination and that only identity fields are returned, which is not inferable from the schema.

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?

Two sentences, front-loaded with the core purpose and filters, followed by pagination and a pointer to get_fighter. No filler or redundant restatement of the title.

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?

Given the read-only annotations and the simple optional-parameter search surface, the description covers what the tool does, how results are paginated, what fields are returned, and where to go for more detail. The identity-fields statement is especially valuable since there is no output schema.

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 descriptions already cover q, org, and country, and the description's 'name, nationality or promotion' largely restates them. The only added parameter insight is 'cursor paginated', which lightly explains limit/cursor but does not fully compensate for the undocumented limit and cursor parameters at 60% schema coverage.

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?

States a specific action ('Search the fighter roster') and explicit filters (name, nationality, promotion), distinguishing it from siblings like get_fighter for full records and the generic search tool. The scope is immediately clear.

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?

Description gives a clear routing rule: use this for identity-level roster searches and get_fighter for the full record. Cursor pagination also signals this is intended for list-style queries rather than single-record lookups.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which lowers the burden on the description. The description adds meaningful context beyond annotations by disclosing the scope restriction ('that have hosted a covered promotion') and the exact fields returned, which shapes agent expectations. It does not describe pagination behavior, but the cursor parameter and schema mitigate that gap.

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?

Two sentences with no filler: the first front-loads purpose and search dimensions, the second states the return fields and the sibling handoff. Every clause earns its place.

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 read-only search tool with no output schema, the description compensates by listing the returned fields and routing to the related events endpoint. It is complete enough for correct invocation; the only missing element is an explicit note on pagination via cursor, which the schema already documents.

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 75%, and the description adds value by mapping the search dimensions onto the parameters ('by name, city or country'), clarifying that q covers name/city fragments and country is a separate filter. This goes beyond restating the schema, though it provides no detail on limit or cursor behavior, which are minor since cursor is self-describing in 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 ('Find arenas and venues that have hosted a covered promotion') and enumerates search dimensions (name, city, country). It also differentiates from the sibling get_venue_events by explicitly routing the id to that tool, so an agent can distinguish the search tool from its neighbors.

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 a clear context for when to use the tool (searching by name, city, or country) and explicitly points to get_venue_events as the follow-up for event data. It does not mention the get_venue sibling as the alternative for a single venue's details, but the search-tool usage context is unambiguous and includes a concrete handoff.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds useful behavioral context beyond that: it runs without the Fight DNA/style-clash factor, so scores may differ from ufcalendar.com, and it includes the already-booked bout when one exists. This goes beyond the structured data without contradicting it.

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 two tight sentences with no filler. The core purpose and output are front-loaded, and the caveat about Fight DNA is placed after the main content, where it adds context without obscuring the primary function.

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 read-only two-parameter tool with no output schema, the description adequately enumerates the key return elements: recommended opponents, model win probabilities, the score behind each pairing, and the booked bout if present. Combined with full schema coverage and clear annotations, this is enough for an agent to invoke and interpret the tool 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?

Schema description coverage is 100% for both fighter and limit, so the schema already documents the parameters. The description confirms that fighter is the subject of the recommendation but adds no extra detail about the limit parameter or slug/id formats, keeping this 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?

The description clearly identifies the tool's purpose: given one fighter, return the most sensible next opponents from UFCalendar's matchmaker, with win probabilities and the existing booked bout. It is specific enough to distinguish from general fight search and fighter-profile tools, though it does not explicitly name or contrast sibling tools.

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 phrase 'For one fighter' implies this tool is for single-fighter next-opponent recommendations, and the matchmaker context suggests when it would be relevant. However, it does not explicitly state when to prefer this over alternatives like find_fights, get_fighter, or compare_fighters, nor does it give exclusions.

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