classify_register

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses the heuristic nature, limitations, return fields, score range, the role of syntactic signals, and the 100,000-character input cap. It even explains that a score of 'neutral' is common for newsletter prose, which is exactly the behavioral nuance an agent needs.

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 longer than most, but each paragraph earns its place: purpose, outputs, use cases, limitations, and alternative routing. The only minor inefficiency is the denseness of the `structure` sentence; still, it is an effective and organized front-loaded definition.

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 one-parameter read-only heuristic classifier, this description is effectively complete. It explains the output semantics, score bounds, limitation, pointer to check_overwrite, and input cap. No output schema exists, but the description gives enough on returns that an agent can understand them without additional context.

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?

With only one parameter and 100% schema description coverage, the schema already covers what `text` is. The description raises semantics by specifying the 100,000-character cap, the Estonian-only expectation, and the lexical scope (legal-administrative and academic/report vocabulary). The mention of `structure` is a slight oddity as it is not a schema parameter, but it reads as an internal behavior note rather than an input directive.

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 opening sentence states the exact function: 'Heuristic register classifier for Estonian (formal vs colloquial)', which is a specific verb+resource pair. It also lists the concrete outputs (tier, score, markers), and the later note referencing check_officialese distinguishes it from the most similar sibling.

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 explicitly says when the tool is useful: sanity-checking marketing copy and contract drafts. It also gives a strong when-not and alternative: 'Use the result as a directional hint, not a verdict; for a full kantseliit breakdown with per-issue suggestions, call check_officialese.' Input cap and neutral-score limitation further shape safe usage.

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