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.