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

Annotations are sparse (only readOnlyHint, openWorldHint, idempotentHint, destructiveHint), so the description carries the burden. It discloses key behavioral traits: the process is deterministic ('DETERMINISTIC engine'), safety overrides are 'inviolable' and applied 'IN CODE,' it starts asynchronously by default, requires authentication, and returns a full audit trail. These are important behavioral details not inferred from annotations. It does not contradict any annotation. A small gap: it doesn't explicitly say what side effects occur (e.g., creation of a session or record), but the async and audit trail imply persistence.

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 dense but every sentence adds value: it covers purpose, process, determinism, safety floors, output, population restriction, anonymization, async, auth. It is front-loaded with the core action and gradually layers constraints. It could be slightly tighter (e.g., merging the panel list), but it is well-organized and not redundant. A 4 reflects good structure with minor room for condensation.

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?

There is no output schema, so the description must explain what is returned—it does: 'Returns the recommended Level of Care with a full audit trail.' It also covers safety overrides, population restriction, async, and auth. For a tool with this complexity (multi-reviewer panel, six dimensions), the description provides enough for an agent to call it correctly. It could detail the audit trail contents or the exact meaning of the Level of Care, but these are arguably outside the core invocation needs. Given the absence of an output schema, this is strong.

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 input schema already provides descriptions for all three parameters (case, model, wait_seconds), achieving 100% coverage. The description adds minimal extra semantics beyond what the schema states—it reinforces that the 'case' must be anonymized clinical text, and the wait behavior is described, but these are also in the schema. Baseline is 3, and there is no need to compensate because the schema carries the load. No additional parameter details are missing.

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 leads with a specific verb and resource: 'Score an anonymized adult mental-health / addiction case against LOCUS.' It clearly explains the process (panel, six dimensions, deterministic aggregation, Determination Grid) and the expected output (recommended Level of Care with audit trail). The mention of CALOCUS/CASII for child/adolescent explicitly distinguishes this tool from a sibling that would cover younger patients, and 'locus_determine_from_scores' is an auditory contrast, showing this is the full scoring pipeline, not just the grid application.

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 explicit usage constraints: 'Adults only (CALOCUS/CASII covers child/adolescent)' and 'use ONLY anonymized cases.' It also states the async start behavior with a recommendation to 'poll get_session,' effectively indicating when to use that sibling tool. It notes authentication requirements. It does not explicitly name an alternative tool for the CALOCUS pathway, but the child/adolescent reference is a strong hint. This covers when and when-not, though it could be more explicit about alternatives.

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