California Court Deadlines

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

Annotations already establish readOnlyHint=true, and the description adds meaningful behavior: skipping weekends and California judicial holidays, plus supporting negative counts. It does not detail output format or edge cases, but it adds useful context beyond the structured fields.

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 front-loaded with the core function, followed by usage context. The final sentence about hand-counting errors is motivational rather than essential, but it is short and does not meaningfully detract from clarity.

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 two-parameter, read-only calculation tool, the description is largely complete: it states the operation, the holiday behavior, and the intended legal use case. The lack of an explicit return-format statement is a minor gap given the absence of an output schema.

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 the schema already documents both parameters well. The description reinforces the meaning of 'court days' but adds no new syntax, bounds, or format details beyond what the schema provides.

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 opens with a specific verb and resource: 'Add or subtract court days from a date, skipping weekends and California judicial holidays.' This clearly states the operation and scope, and the mention of court days distinguishes it from sibling tools like california_court_day_check and california_court_holidays.

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 gives explicit when-to-use guidance: 'Use this for any period a statute states in court days rather than calendar days,' with a concrete statutory example. It does not explicitly name alternatives or exclusions, so it falls short of a 5, but the context is clear and actionable.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=false, and the 'say whether' language is consistent with those. The description adds real behavioral value beyond the annotations by disclosing the roll-forward mechanism and the governing statute (CCP §12a), which the agent would otherwise not know.

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?

Two sentences with zero waste. The core behavior is front-loaded in the first sentence, and the second sentence provides actionable usage guidance that 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 single-parameter, read-only tool with no output schema, the description fully explains what the caller receives: a court-day determination plus the next roll-forward date under §12a. Nothing an agent needs in order to call it correctly is missing.

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 schema already documents the date parameter with its format and 'The date to check.' The description adds mild context by implying the date is a filing or deadline date, but it adds no substantive semantics beyond what the schema already provides, so the baseline of 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?

The description states a precise action — determining whether a given date is a California court day and, if not, rolling forward to the next one under Code of Civil Procedure section 12a. This distinguishes it clearly from siblings like california_court_holidays (a static holiday list) and california_add_court_days (which adds days to a date) without needing to open their schemas.

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 second sentence gives explicit when-to-use guidance: 'Use this before asserting that a filing date or a deadline falls on a working day.' It names the decision context precisely, though it does not mention exclusions or route the agent to alternative sibling tools for other scenarios.

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

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

Annotations already mark this as read-only, so the description doesn't need to cover safety. It adds meaningful behavioral detail beyond the schema by noting that weekend-observed shifts are included, flagging a common source of errors. This gives the agent useful expectations about the returned data.

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?

Three concise, purposeful sentences. The first states the action and output, the second gives legal context, and the third highlights the non-obvious weekend shifts. No redundant words or filler.

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 read-only tool with no output schema, the description is complete. It states what is returned (every holiday with observed date), why it matters (court-day counting and deadline roll-off), and a key correctness detail (weekend shifts). An agent can correctly select and invoke this tool with the provided information.

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 fully documents the single 'year' parameter with a range and description ('Four-digit year'). The tool description adds little beyond restating 'for a given year,' so it does not meaningfully improve on the schema. Baseline 3 applies given 100% schema coverage.

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 ('List') and a specific resource ('every California judicial holiday for a given year') with a defined scope. It clearly distinguishes this holiday-lookup tool from the sibling deadline calculators, which are about adding days or computing 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 explains the practical context: these are the days excluded when counting court days and when deadlines roll off under CCP section 12a. This tells the agent when the tool's output is relevant, though it does not explicitly name an alternative or state when not to use it.

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

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

Annotations only declare readOnlyHint and openWorldHint=false, so the real value is the rule-specific context: the description pins behavior to Rule 4.111 and proactively rules out service-method extensions, which is a substantive constraint an agent could otherwise assume. It doesn't cover error behavior when trigger_date is omitted for event-timed motions.

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?

Three sentences, front-loaded with the primary output and then the secondary deadline family, with the service-method caveat last. No filler, though the final sentence is a caveat that could be tighter.

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?

A read-only computation tool with no output schema, so the description must convey what comes back; it does so by listing the computed deadline items. The §995/§1510 trigger-date dependency is alluded to but not tied explicitly to the trigger_date parameter, a minor gap.

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 the baseline is 3; the schema already explains motion enums, hearing_date's dual meaning for §1538.5(i), and trigger_date. The description corroborates the trigger-date concept (event-timed motions like §995) but adds no format or edge-case detail 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?

States a specific verb (compute) and a specific resource/scope (the CRC 4.111 briefing chain for a criminal pretrial motion), enumerating the outputs: moving papers service, proof of service, opposition, reply, hearing. The criminal framing and rule citation distinguish it from the civil sibling california_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?

Makes clear the tool covers two families of computation: the 4.111 briefing chain and the outside deadlines triggered by an event (§995, §1510). It also flags a when-not condition by stating there is no service-method extension in criminal motions. It stops short of explicitly routing the agent away from the civil sibling.

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

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

Annotations declare readOnlyHint=true, and the description aligns with that by describing a pure computation. The description adds valuable behavioral context beyond the schema: it discloses the legal rules applied (section 1013, 1010.6, AB 540, 12a), the date-rollover behavior (weekends and judicial holidays), and the critical temporal cutoff for electronic service. This is exactly the kind of non-obvious behavior an agent needs to know.

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 core purpose and then packs in the legal nuance without waste. Every clause earns its place: the discovery types, the service-method dependency, the AB 540 exception, and the holiday rollover are all covered in one efficient sentence.

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 pure computation tool with 100% schema coverage and readOnlyHint=true, the description is nearly complete. It covers the legal basis, the key exceptions, and the output behavior (rolling to the next business day). It doesn't explicitly state the output format (e.g., a date string), but with no output schema and a clear computation described, an agent can infer the result is a date. Minor gap: it doesn't mention that the result is a date, but this is easily inferred.

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 schema already documents all three parameters. The description adds meaningful context by explaining that service_method is what the extensions 'key to' and by clarifying the electronic service date cutoff. It also explains the served_date semantics ('the date the discovery was served on you'). This goes beyond the schema's terse descriptions.

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 states a specific verb ('Compute'), a precise resource ('responses to California written discovery'), and enumerates the three discovery types covered. It also distinguishes itself from sibling tools by naming the exact legal sections applied (1013, 1010.6, AB 540, 12a), making its scope unmistakable.

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 explains what inputs are needed (served date and service method) and how the computation works, including the key distinction for electronic service before/after January 1, 2027. It doesn't explicitly say when NOT to use this tool versus siblings, but the specificity of 'written discovery responses' and the sibling names (motion deadlines, response to complaint, etc.) make the intended use case clear.

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

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

Annotations only cover safety (readOnlyHint, openWorldHint=false); the description carries the real behavioral burden and does so richly: it explains the § 1005 chain versus the § 659a/§ 660(c) exception for new trial and JNOV, the § 12a forward vs backward roll convention for weekends and judicial holidays, and that each returned date carries its statutory basis. It also flags a site-specific convention the agent could not otherwise infer.

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 purpose and output list are front-loaded in the first sentence, and the new trial/JNOV exception is placed after the general rule where it belongs. It is dense and statute-heavy but each sentence carries substantive content; the new-trial paragraph mildly duplicates the schema's entry_date/hearing_date descriptions, which keeps it from a perfect score.

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 complex, statute-driven calculator with 8 parameters, 5 enums, and no output schema, the description supplies what the structured fields cannot: the rule hierarchy, the exception chains, the roll convention, and the shape of the return value (date plus governing statute plus holiday adjustment). An agent has everything needed to call 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 description coverage is 100%, so the baseline is 3, but the prose adds conceptual framing beyond the schema: it clarifies that trigger_service_method is a different question from service_method and never extends a summons-based period, and that unknown input defaults to personal so it errs early. That interpretive context is genuinely additive even though the per-parameter details live in 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 names a specific verb (compute) and resource (the California CCP § 1005 briefing chain plus the outside deadline to bring certain motions), and enumerates the exact outputs (moving, opposition, reply dates). It is very clear about what it does. However, it never distinguishes itself from siblings such as california_summary_judgment_deadlines, even though "msj" appears in its own motion enum, leaving a real routing ambiguity unaddressed.

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 only usage direction is the closing "Use this instead of computing California motion deadlines yourself," which is a recommendation rather than routing guidance. It implies context (civil, noticed motions, California) but gives no when-not conditions and never names the alternative tools in the same family (criminal deadlines, SJ deadlines, response-to-complaint deadline) that an agent must choose between.

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

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

Beyond the readOnlyHint annotation, the description discloses that service methods are handled separately because they complete service on different days, and lists the specific extensions applied (section 430.41, rule 3.110(d), court-ordered). It also notes that unlawful detainer runs on section 1167. This adds meaningful behavioral context without contradicting the annotation.

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 three sentences, front-loaded with the core purpose, then elaborates on service methods and extensions. Every sentence adds information; there is no fluff or repetition of schema details.

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?

The description covers the essential aspects: the core computation, the service methods, the extensions, and the special case of unlawful detainer. It does not mention how holidays or court days are handled, but given the sibling tools (e.g., california_add_court_days) and the readOnlyHint, the description is sufficiently complete for an agent to understand what the tool does and when to use it.

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 100% schema coverage, the schema already documents each parameter. The description adds value by explaining why service_method matters (different completion days) and by referencing the extension parameters in context (meet-and-confer, stipulated 15 days, court-ordered), which reinforces their semantic meaning beyond the raw field descriptions.

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 opens with a specific verb and resource: 'Compute when a response to a California complaint is due.' It explicitly names the four service methods and the extensions, and clarifies that unlawful detainer runs on a different statute, which distinguishes it from the sibling tools that handle other deadline types (discovery, motions, etc.).

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 makes clear it is for complaint response deadlines and notes the special handling of unlawful detainer, but it does not explicitly name alternatives or state when not to use this tool. However, the subject matter and the distinction of service methods provide strong contextual guidance, and the sibling list makes the intended scope obvious.

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

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.

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

Annotations only give readOnlyHint and openWorldHint=false, so the description must carry the behavioral load, and it does add real value: it discloses that service_method drives the section 437c rows and the 998 offer deadline, and it openly flags the legal-basis caveat that no published decision applies sections 1013(c)/1010.6 to a 998 offer, so the tool follows Lecuyer v. Sunset Trails. That is genuine transparency beyond the annotations.

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?

Two sentences, front-loaded on the core computation with the optional county extension held to the second sentence. The enumeration is dense but each item is a distinct returned deadline, so it earns its space; only the trailing 'this site tracks' aside is slightly loose.

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 carries the burden of telling the agent what comes back, and it does so by listing every computed deadline category. Combined with the disclosed service-method caveat and the county scope limit, an agent has enough to invoke and interpret this tool 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 description coverage is 100%, so all four parameters (trial_date, county, set_date, service_method) are already documented in the schema, including the enum and pattern constraints. The description restates the optional county local-rule behavior and the service-method effect but adds little syntax or format detail the schema lacks, making the baseline 3 appropriate.

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?

Names a specific verb (work backward / countdown) and resource (California civil trial date to pretrial deadlines) and enumerates exactly which deadlines it returns: discovery cutoff, motion cutoff, expert exchange, expert discovery, last day to serve written discovery, and summary judgment dates. The 'civil' qualifier also naturally separates it from the sibling 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 trial-date anchor makes the usage context clear, and it notes the tool covers 'one of the counties this site tracks,' which hints at scope limits. However, it never states when to prefer this aggregated countdown over the focused siblings like california_motion_deadlines, california_summary_judgment_deadlines, or california_discovery_response_deadline, nor any when-not condition.

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