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

Annotations already declare readOnlyHint and openWorldHint, so no side-effect disclosure is needed. The description goes further by detailing key rule behavior: the 81-day notice period, service-extension handling, the electronic-service-after-2027 special rule, and the assumption that opposition and reply are computed off the last permissible hearing date.

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 one dense, front-loaded sentence that immediately states the statute and the anchor trial date before listing the computed outcomes. It contains no filler, though the parenthetical and clause-heavy structure makes it slightly harder to parse at a glance.

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 no output schema, the description compensates by naming the computed outputs: the last hearing day, the last file-and-serve day, and the opposition and reply dates. It does not specify the exact result keys or formatting, but for a two-parameter read-only calculator this is enough for an agent to select and invoke it correctly.

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 coverage is 100%, so the baseline is 3, but the description adds genuine semantics beyond the schema. It explains why service_method matters by referencing the section 437c(a)(2) extension table and the specific no-extension rule for electronic service on or after January 1, 2027, and it ties trial_date to the 30-day and 81-day anchor calculations.

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 the specific verb 'Compute' and identifies a precise resource, California Code of Civil Procedure section 437c deadlines, then enumerates the exact dates it derives from a trial date. This clearly separates it from broader siblings like california_motion_deadlines and california_criminal_motion_deadlines.

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 clearly states the context: calculating summary-judgment deadlines in California from a trial date under section 437c. It does not explicitly name alternatives or state exclusions, so it stops short of a 5, but an agent can confidently identify when this tool applies.

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