clear_student_cache

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

With no annotations, the description carries the behavioral burden. It importantly discloses the broad effect of omitting a subdomain: clearing the cache for ALL schools, which is a critical side-effect warning. It does not elaborate on permissions or exact cache mechanics, but the provided context is solid.

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 two sentences with no filler. The first sentence states the action, the second gives usage guidance and scope behavior. Everything earns its place.

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 simple one-parameter cache-clearing tool with no output schema, this description is nearly complete. It covers why to call, when, and the global scope default. A minor gap is that it does not specify the format for the subdomain, but this is low-risk given the optional and scope-limiting nature of the parameter.

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 simply declares 'subdomain' with a default of null and no description. The description compensates by explaining the scoping effect: without a subdomain, the cache for all schools is cleared, implying that providing one limits the operation. It does not document the expected subdomain format, but it adds meaningful semantics beyond the schema.

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 uses a specific verb phrase 'Force refresh' targeting 'cached student data', which clearly identifies a cache-invalidation action. It distinguishes itself from sibling data-fetching tools like scan_students and find_student by naming them as sources of stale results.

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?

Explicitly states when to call the tool: after students are added/removed from a school, or when scan_students/find_student return stale results. This gives concrete trigger conditions and names the relevant sibling tools, leaving little ambiguity about the intended use case.

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