Check Repovive house style

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

The description fully aligns with the readOnlyHint=true annotation – it is a check operation that lists deviations, implying no side effects. It adds behavioral detail beyond annotations by specifying the exact checks performed (memory, time limits, tags, sample explanation) and the output as a list of deviations. No contradiction exists, and the description enriches the agent's understanding of the read-only nature.

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 a single, well-structured sentence. It front-loads the primary action ('Check a problem against Repovive's measured house style') and then efficiently lists the specific criteria in a compact, comma-separated enumeration. There is no redundant wording or filler, making it both concise and clear.

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 is simple with one parameter, a clear output schema (exists), and a description that fully enumerates the checks performed. The description covers all relevant behavioral aspects for an agent to call the tool correctly. It does not explicitly discuss error handling or input validation beyond the schema's minLength, but given the simplicity and output schema coverage, these are minor gaps. Overall, the description is complete enough for effective use.

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?

The schema description coverage is 100%, as the single parameter 'problem_json' is described as 'A problem object as a JSON string' with a minLength of 2. The tool description adds no additional meaning to this parameter beyond stating it is a problem; it does not explain expected structure, formatting nuances, or how the JSON string maps to the checks. Since schema already covers the parameter, the description does not contribute extra value, so baseline 3 is appropriate.

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 clearly states the verb 'Check' and resource 'problem against Repovive's measured house style' and enumerates the specific deviations it checks (input/output braced-array notation, t bound, tags, memory, time limit, points value, sample). This makes the tool's purpose unambiguous and distinguishes it from sibling validators like repovive_validate_problem, which would cover general problem validation.

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 this tool: when checking whether a problem conforms to the house style. It lists the exact aspects checked, which helps an agent decide relevance. However, it does not explicitly name alternatives or state when to use a different validator (e.g., repovive_validate_problem), so it lacks explicit exclusions or alternative guidance.

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