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

Annotations already declare readOnly=false, idempotent=true, destructive=true. The description adds useful context beyond them: the output is a W3C VC whose hash is anchored on Base L2, and the lineup is 'locked', implying irreversibility. However, it never explains why the operation is destructive, what cannot be undone after commit, whether the agent DID must be registered first, or what happens if a contest is already started beyond 'must be in the future'.

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 first paragraph is well front-loaded and earns its place, but the Args block is a verbatim restatement of the input schema's property descriptions and provides no new information to an agent that already receives the schema. Roughly half the text is redundant for a schema-aware caller.

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 has 10 parameters and an output schema, and the description covers purpose, mechanism, and inputs, so the core is present. It omits preconditions that matter for a destructive, money-attached operation (agent identity/registration requirements, whether failure cases like a past contest start return an error, gas/anchoring latency), leaving gaps for an agent deciding whether to invoke it.

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 restates the same argument documentation with examples (DID format, contest_id, ISO 8601 format, lineup_json example) and clarifies the acceptance rule 'must be in the future'. It adds examples beyond the schema but largely duplicates it.

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?

First line gives a specific verb (commit) plus resource (fantasy lineup) and states the mechanism (SHA-256 hash anchored on Base L2). It follows with the artifact produced (a FantasyLineupCredential W3C VC) proving the lineup was locked before contest start. It does not explicitly distinguish itself from mt_fantasy_verify or mt_fantasy_history, but the write-vs-read distinction is inferable from 'commit' and 'locked'.

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?

There is no explicit when-to-use / when-not-to-use guidance and no mention of the sibling tools (mt_fantasy_verify, mt_fantasy_history, mt_prediction_*) that an agent might pick instead. The only usage constraint given is that contest_start_iso must be in the future, which is a precondition rather than routing guidance.

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