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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is handled. The description adds behavioral context beyond annotations: it specifies ordering ('newest first'), pagination ('paged with from/count'), and the content of each submission (contest, problem, verdict, language, runtime, memory). This is valuable and non-contradictory 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 three sentences, front-loaded with the tool's core identity ('Codeforces competitive-programming API — the submission history of one Codeforces handle'), and every sentence contributes either scope, data details, or the practical question answered. There is no fluff 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?

The tool has a rich output schema and annotations already covering read-only/idempotent behavior. The description provides all necessary operational context: pagination, ordering, what each submission contains, and the high-level purpose. It is complete and self-contained for an agent selecting and invoking the 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 documentation covers 'from' and 'count' but leaves 'handle' undescribed. The description compensates by identifying the handle as 'one Codeforces handle' and explaining that from/count control pagination with 'newest first' ordering. This adds meaning beyond the raw schema definitions, especially for the required handle 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 opens with a specific verb-resource pair: 'the submission history of one Codeforces handle, newest first, paged with from/count.' It clearly distinguishes this tool from sibling tools like 'user' and 'user_rating' by focusing on submission history and verdicts, and it concludes with the actionable question answered: 'which problems a Codeforces user attempted lately and whether they passed.'

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 for when to use the tool: to see a Codeforces user's submission history and determine which problems they attempted and whether they passed. It does not explicitly name alternatives or exclusions, but the context is strong enough that an agent would know when this tool is appropriate. The lack of explicit 'use this instead of X' language prevents a 5.

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