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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state what the tool returns (boolean, BOM position, or a report), whether the BOM is checked only at the start or anywhere in the string, or how edge cases like empty input behave. For a check-type tool with no output schema, these are material gaps.

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 short and easily scannable, and the core clause 'Check for a UTF-8 BOM in text' is efficient. However, the 'BOM Check:' prefix largely duplicates the tool name and contributes no information, keeping it from earning top marks for structure.

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?

This is a 1-parameter tool with no output schema and no annotations, so the description must carry substantial weight. It conveys the operation but omits the return contract entirely and offers no differentiation from related text/encoding siblings. For a tool this simple, the gap between the description and what an agent needs to invoke and interpret it correctly is moderate.

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% (input documented as 'Input to process'), so the baseline is 3. The description's phrase 'in text' confirms the input is the string being examined but adds no format, encoding, or constraint details beyond the schema. This is adequate but not additive.

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 'Check for a UTF-8 BOM in text' names a specific verb and resource, making the tool's function clear and distinguishing it from the large sibling set, none of which target BOM detection. It is not a tautology, since it adds what is operated on and what is detected. It falls short of 5 because 'check for' leaves ambiguity about return type (boolean vs. details) and whether detection applies only at the start of the text.

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 on when to use this tool versus alternatives. With hundreds of siblings including related text/encoding tools like utf8-validate and charset-detect, the description provides no selection criteria, exclusions, or context. An agent must infer usage entirely from the tool name and one-line purpose.

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