validate_cfg

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

Annotations already declare this a read-only, idempotent, closed-world operation, so the safety profile is covered. The description adds real value by disclosing the specific categories of problems surfaced (unknown names with suggestions, out-of-range values, cheat/devonly flags, context mismatches), which tells an agent what to expect back beyond the hints.

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?

A single dense sentence that front-loads the action and resource, then enumerates the checks in a compact parenthetical list. Every clause carries useful information and nothing is padded.

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?

With an output schema present, return values need not be described, and the required parameters plus context default are covered by the schema. The description supplies enough on validation dimensions for correct invocation, though it could say what the agent should do with the findings (e.g., fix and revalidate) before deploying.

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%, so game, text, and context are already fully documented, including the context enum and its default. The description's mention of 'client-vs-server context' loosely reinforces what the context parameter governs, but adds no format or syntax guidance for text or game beyond the schema. Baseline 3 applies.

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 (check) and resource (every command in a .cfg) and enumerates exactly what is validated: unknown names with suggestions, out-of-range values, cheat/devonly flags, and client-vs-server context. This clearly separates it from the similarly named sibling validate_cs_script, which targets scripts rather than .cfg contents.

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 scope 'every command in a .cfg' makes the intended use case clear (validating a config file's contents), and 'client-vs-server context' hints that the outcome depends on where the cfg runs. It stops short of naming any alternative or stating exclusions, such as when to prefer get_convar or list_convars for a single lookup.

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