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

Annotations already declare a safe, non-destructive, closed-world read, so the bar is lower; the description still adds real behavior: conflicting arguments are rejected by name rather than one silently winning, normalization requires scaleId, the window is ignored for Vihinen flexibility, and weightVariation collapses at edge 1. It does not describe output shape, but an output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two dense sentences, front-loaded with the purpose before the mode split, with no filler. The parenthetical enumerations of profile families are slightly heavy but each carries selection-relevant 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?

For a 10-parameter tool with nested objects, four enums, and an output schema, the description covers the decisions an agent must make: which mode, which argument combination, and the normalization prerequisite. The remaining gap is sibling disambiguation, which the description leaves silent.

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 baseline is 3; the description earns a bump by explaining the mutual-exclusion contract between scaleId and kind/scale and by summarizing what the five kind profiles actually compute (GRAVY hydropathy, Vihinen flexibility, Hopp & Woods, Emini, Janin). It does not clarify the nested _subject/_files parameters, which the schema handles.

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 -- a windowed physicochemical profile along a protein, attributed to ExPASy ProtScale -- and splits the tool into its two distinct modes (scaleId catalogue vs kind/ProtParam profiles). It does not distinguish itself from close siblings such as protein_properties, protein_membrane_profile, or protein_disorder, so an agent must infer which profiling tool to pick.

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 clear routing guidance between the two entry paths: pass scaleId for the full 57+14 catalogue, or pass kind for the five ProtParam profiles, with the explicit note that scaleId together with kind is refused. It stops short of naming alternative sibling tools or stating when to prefer those over this one.

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