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?

The annotations declare readOnlyHint=true, and the description does not contradict that. It adds a valuable behavioral caveat: 'There is no service-method extension in criminal motions; rule 4.111 does not provide one,' which prevents an agent from assuming a civil-style extension applies. This goes beyond what annotations already convey, though it does not describe output details or other side effects.

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, with the primary computation stated first, the secondary outside-deadline feature second, and a crucial caveat third. Every sentence earns its place and there is no redundant or filler text. It is efficiently front-loaded.

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 core computation and the outside-deadline tracks, and the no-extension caveat is essential legal context. There is no output schema, but the listed output components (service, proof, opposition, reply, hearing) give a good picture of what is returned. The parameter semantics are fully handled by the schema, so nothing critical is missing for an agent to 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 description coverage is 100%, so each of the four parameters already has a clear description. The tool description does not add parameter-specific semantics beyond the schema; it mentions service/opposition/reply/hearing in the context of the output, not parameter meaning. This matches the baseline 3 for full 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 the specific verb 'Compute' with a precise resource ('California Rule of Court 4.111 briefing chain for a criminal pretrial motion') and lists the computed items. It clearly distinguishes from the sibling california_motion_deadlines by specifying 'criminal' and the rule number, so an agent can tell them apart without opening 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 description provides clear context: it is for criminal pretrial motions under CRC 4.111 and also covers outside deadlines for trigger-event motions. However, it does not explicitly name alternatives or state when not to use it, such as pointing to california_motion_deadlines for civil motions. The context is clear but lacks exclusions, so it stops short of a 5.

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?

The description goes beyond the readOnly annotation by revealing that the tool returns each date with the statute it relies on and whether the date was rolled off a weekend/holiday. It also discloses the special exception for new trial/JNOV and the forward-counting method. This provides substantial behavioral context that is not in 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?

The description is a single well-structured paragraph that front-loads the core function (computing the briefing chain) before adding exceptions and output details. It is somewhat long but each sentence adds valuable context—the new trial exception, the service method inputs, and the output format. It does not repeat schema information verbatim and avoids fluff.

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 legal-calendar tool, the description is remarkably complete. It covers all motion types, the service method nuances, and the special new trial/JNOV logic. Even though no output schema is provided, the description states exactly what is returned (each date with statute and roll-off status), so an agent can predict the tool's behavior. It also addresses the 6-parameter complexity by explaining the distinction between service_method and trigger_service_method, which is crucial for correct use.

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 description adds significant meaning beyond the schema by explaining how service_method drives the notice period and how trigger_service_method extends the motion-bringing deadlines, which the schema descriptions only hint at. It also clarifies the special handling of hearing_date for new-trial/jnov. However, since the schema already fully describes each parameter's purpose (100% coverage), the description's added value is not as high as it could be.

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 clearly states that the tool computes the section 1005 briefing chain (moving, opposition, reply, and outside deadlines) for civil motions, and explicitly identifies the tool as California-specific. It lists the motion types covered and distinguishes the new trial/JNOV exception. This clearly differentiates it from siblings like california_criminal_motion_deadlines and california_discovery_response_deadline.

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 states when to use this tool ('for a noticed civil motion') and tells the agent to use it instead of computing deadlines manually. It provides key usage nuances, such as the special handling for new trial and JNOV under section 659a, and mentions the service method parameters. While it does not name an explicit alternative, the context of sibling tools and the detailed scope make the usage context 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?

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?

With readOnlyHint=true, the tool is known to be read-only, and the description adds value by outlining the scope of computed deadlines (discovery, motion, expert, summary judgment) and the optional county-specific local rules. It does not detail computational assumptions or limitations (e.g., whether it accounts for court holidays), but given annotations cover read-only nature, this is sufficient.

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 concise and front-loaded, starting with the core action ('Work backward from a California civil trial date to the pretrial deadlines') and listing the key outputs in a sentence. It then adds the optional county feature in a second sentence. No fluff, each sentence 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?

Given the tool's complexity (multiple deadlines, optional county logic, and a service_method with 6 service types), the description covers the main outputs and optional parameters well. It doesn't explain the legal basis or what exactly 'section 437c rows' are, but for an AI agent specializing in legal deadlines, this is probably sufficient. With no output schema, the description could state the return structure, but the listed deadlines give a clear overview.

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 parameters are well documented in the schema. The description adds context for the 'county' parameter (adds local-rule deadlines) and 'service_method' (used for summary judgment rows), which aligns with the schema. It doesn't describe 'set_date' beyond the schema's 'some local rules count from,' but that is adequate. Overall, the description complements the schema without redundancy.

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 clearly states the tool computes various California pretrial deadlines by working backward from a trial date, listing specific deadlines (discovery cutoff, motion cutoff, expert exchange, etc.). It distinguishes itself from siblings like california_discovery_response_deadline and california_summary_judgment_deadlines, which focus on specific deadlines, whereas this is a comprehensive countdown tool.

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 indicates when to use it (when you need a comprehensive set of pretrial deadlines from a trial date), but it does not explicitly state when not to use it or name alternative tools for more specific needs. The existence of sibling tools focused on single deadline types (e.g., discovery response, summary judgment) implies the alternatives, but that exclusion isn't spelled out.

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