Federal civil deadlines (FRCP, FRAP 4, removal, listed district local rules), with the rule quoted.
Scored across 4 tools
The four tools mostly target distinct tasks: general day counting, federal-rule deadline computation, holiday listing, and local-rule deadline computation. The main overlap is between federal_count_days and federal_deadline, but the descriptions explicitly distinguish them by use case: unspecific periods such as court orders versus periods covered by a specific federal rule row.
All names use snake_case with a consistent federal_ prefix, making them readable and clearly grouped. However, the set is not a uniform verb_noun pattern: federal_count_days is action-oriented while the others are noun phrases.
Four tools is a well-scoped set for a specialized deadline-calculation server. Each tool covers a distinct layer of the domain: general counting, federal deadlines, holidays, and local deadlines.
The surface covers the core deadline workflow: counting periods, computing federal and local deadlines, and identifying legal holidays. Minor gaps remain, such as no dedicated rule-lookup tool or broader appellate briefing coverage, but the main civil deadline lifecycle is represented.
Count a period stated in days from a date under FRCP 6(a) or FRAP 26(a): leave out the trigger day, count every day, and if the last day is a weekend or legal holiday roll to the next open day (or, for a period counted backward before an event, to the preceding one). Optionally adds 3 days under FRCP 6(d) or FRAP 26(c) after the roll, for a period that runs after being served. Returns the due date under the prevailing reading, and the earliest and latest dates when observed or closure days make the readings differ. Use this for a period no specific rule row covers, such as one set by a court order. With court_open_days, counts only days a district court is open instead, for a local rule that states its period that way.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The date of the event the period counts from. That day itself is not counted. | |
| days | Yes | How many days: calendar days, or with court_open_days only days the court is open. Negative counts backward, for a period measured before an event. Not zero. | |
| regime | No | frcp (default) counts under FRCP 6(a), for the district court; frap counts under FRAP 26(a), for an appeal. | |
| district | No | Optional. The CM/ECF id of the district court, such as casd, cacd, nysd or dcd. Adds the notes for that district and the Ninth Circuit notes for California districts. Required with court_open_days. | |
| frap_delivery | No | FRAP only, and only when the period runs after being served: how the paper was delivered. "other" adds 3 days under FRAP 26(c). served-electronically = Served electronically: adds nothing; delivered-on-proof-date = Delivered on the date stated in the proof of service: adds nothing; other = Any other service: adds 3 days (FRAP 26(c)). | |
| service_method | No | FRCP only, and only when the period runs after being served: how the paper was served under Rule 5(b)(2). Mail, leaving it with the clerk and other consented means add 3 days under Rule 6(d); the rest add nothing. 5b2C-mail = Mail (Rule 5(b)(2)(C)); 5b2D-clerk = Leaving it with the clerk (Rule 5(b)(2)(D)); 5b2F-consented-other = Other means you consented to in writing (Rule 5(b)(2)(F)); 5b2E-electronic = The court's electronic-filing system or other consented electronic means (Rule 5(b)(2)(E)): adds nothing; 5b2A-handing = Handing it to the person (Rule 5(b)(2)(A)): adds nothing; 5b2B-leaving = Leaving it at the office or home (Rule 5(b)(2)(B)): adds nothing. | |
| court_open_days | No | Optional, FRCP only, and only with a district whose local rules this site applies (federal_local_deadline accepts it): true counts only days that court is open, skipping weekends, legal holidays and the days its posted schedule closes the court. The last day counted is a day the court is open, so it is not rolled. Not with service_method. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description carries real behavioral weight on top of that, spelling out the counting method (exclude trigger day, count every day, roll forward or backward off weekends/holidays), the conditional 3-day service addition, and what is returned including the earliest/latest spread.
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?
One dense paragraph, front-loaded with the core counting rule and its exceptions in priority order. A few clauses restate schema-level details (district ids, court_open_days mechanics), which is the main thing keeping it from a 5.
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 7-parameter tool with no output schema, the description covers return values (due date plus earliest/latest when readings diverge) and the three conditional regimes. It is slightly thin on the unexplained term 'prevailing reading' and on failure behavior for invalid or missing districts.
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 the schema leaves implicit — that the +3 days are applied 'after the roll,' that the district parameter drives note selection, and that court_open_days suppresses both rolling and service_method.
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 and resource ('Count a period stated in days from a date') and pins the legal regime it implements (FRCP 6(a) / FRAP 26(a)). The closing sentence distinguishes it from the rule-table tools by scoping it to 'a period no specific rule row covers, such as one set by a court order.'
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?
Gives clear usage context: use it for periods without a specific rule row (e.g., court orders), and switch to the court_open_days mode for local rules that count only open days. It stops short of naming federal_deadline or federal_local_deadline explicitly as the alternatives to prefer when a rule row does exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute one federal civil deadline under the Federal Rules of Civil Procedure, FRAP 4 or 28 U.S.C. 1446 and 1447, from the date of the event the rule counts from. Counts under FRCP 6(a) (FRAP 26(a) for an appeal), rolls off weekends and legal holidays in the direction the rule requires, and adds 3 days under Rule 6(d) or FRAP 26(c) only when that rule reaches the period and the method of service calls for it. Returns the due date under the prevailing reading and, when the readings differ, the earliest date (safe for a party computing its own deadline) and the latest date (the floor for arguing someone else was late), with every open question, the rule text, the authority and the countersign status. A deadline a district court's own local rules set is returned by federal_local_deadline.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes | The rule row to compute. Each id names the rule and subdivision: fed-frcp-4m (FRCP 4(m), after the complaint is filed); fed-frcp-4d1F (FRCP 4(d)(1)(F), after the request was sent); fed-frcp-12a1Ai (FRCP 12(a)(1)(A)(i), after being served with the summons and complaint); fed-frcp-12a1Aii (FRCP 12(a)(1)(A)(ii), after the request for a waiver was sent); fed-frcp-12a2 (FRCP 12(a)(2), after service on the United States attorney); fed-frcp-12a3 (FRCP 12(a)(3), after service on the officer or employee or service on the United States attorney, whichever is later); fed-frcp-12a4A (FRCP 12(a)(4)(A), after notice of the court's action); fed-frcp-12a4B (FRCP 12(a)(4)(B), after the more definite statement is served); fed-frcp-15a1A (FRCP 15(a)(1)(A), after serving it); fed-frcp-15a1B (FRCP 15(a)(1)(B), after service of a responsive pleading or 21 days after service of a motion under Rule 12(b), (e), or (f), whichever is earlier); fed-frcp-15a3 (FRCP 15(a)(3), after service of the amended pleading); fed-frcp-38b1 (FRCP 38(b)(1), after the last pleading directed to the issue is served); fed-frcp-16b2 (FRCP 16(b)(2), the earlier of 90 days after any defendant has been served with the complaint or 60 days after any defendant has appeared); fed-frcp-26f1 (FRCP 26(f)(1), at least 21 days before a scheduling conference is to be held or a scheduling order is due under Rule 16(b)); fed-frcp-26a1C (FRCP 26(a)(1)(C), after the parties' Rule 26(f) conference); fed-frcp-26a1D (FRCP 26(a)(1)(D), after being served or joined); fed-frcp-26a2Di (FRCP 26(a)(2)(D)(i), at least 90 days before the date set for trial or for the case to be ready for trial); fed-frcp-26a2Dii (FRCP 26(a)(2)(D)(ii), after the other party's disclosure); fed-frcp-26a3B-disclosures (FRCP 26(a)(3)(B), at least 30 days before trial); fed-frcp-26a3B-objections (FRCP 26(a)(3)(B), Within 14 days after they are made); fed-frcp-33b2 (FRCP 33(b)(2), after being served with the interrogatories); fed-frcp-34b2A-served (FRCP 34(b)(2)(A), after being served); fed-frcp-34b2A-early (FRCP 34(b)(2)(A), after the parties' first Rule 26(f) conference); fed-frcp-36a3 (FRCP 36(a)(3), within 30 days after being served); fed-frcp-45d2B (FRCP 45(d)(2)(B), 14 days after the subpoena is served); fed-frcp-56b (FRCP 56(b), until 30 days after the close of all discovery); fed-frcp-72a (FRCP 72(a), after being served with a copy); fed-frcp-72b2-objections (FRCP 72(b)(2), after being served with a copy of the recommended disposition); fed-frcp-72b2-response (FRCP 72(b)(2), after being served with a copy); fed-frcp-50b (FRCP 50(b), after the entry of judgment); fed-frcp-50d (FRCP 50(d), after the entry of the judgment); fed-frcp-52b (FRCP 52(b), after the entry of judgment); fed-frcp-59b (FRCP 59(b), after the entry of judgment); fed-frcp-59c (FRCP 59(c), after being served); fed-frcp-59d (FRCP 59(d), after the entry of judgment); fed-frcp-59e (FRCP 59(e), after the entry of the judgment); fed-frcp-54d2Bi (FRCP 54(d)(2)(B)(i), after the entry of judgment); fed-frcp-60c1 (FRCP 60(c)(1), after the entry of the judgment or order or the date of the proceeding); fed-frcp-62a (FRCP 62(a), for 30 days after its entry); fed-frap-4a1A (FRAP 4(a)(1)(A), after entry of the judgment or order appealed from); fed-frap-4a1B (FRAP 4(a)(1)(B), after entry of the judgment or order appealed from); fed-frap-4a3 (FRAP 4(a)(3), after the date when the first notice was filed); fed-frap-4a4 (FRAP 4(a)(4), from the entry of the order disposing of the last such remaining motion); fed-frap-4a5 (FRAP 4(a)(5)(A)(i), no later than 30 days after the time prescribed by this Rule 4(a) expires); fed-frap-4a6 (FRAP 4(a)(6), after the date when its order to reopen is entered); fed-usc-1446b1 (28 U.S.C. 1446(b)(1), after the receipt by the defendant, through service or otherwise, of a copy of the initial pleading); fed-usc-1446b2BC (28 U.S.C. 1446(b)(2)(B)-(C), after receipt by or service on that defendant of the initial pleading or summons described in paragraph (1)); fed-usc-1446b3 (28 U.S.C. 1446(b)(3), after receipt by the defendant, through service or otherwise, of a copy of an amended pleading, motion, order or other paper); fed-usc-1446c1 (28 U.S.C. 1446(c)(1), more than 1 year after commencement of the action); fed-usc-1447c (28 U.S.C. 1447(c), after the filing of the notice of removal under section 1446(a)); fed-frcp-81c2 (FRCP 81(c)(2), receipt of the initial pleading; service of the summons for an initial pleading on file; filing of the notice of removal); fed-frcp-6c1 (FRCP 6(c)(1), before the time specified for the hearing); fed-frcp-6c2 (FRCP 6(c)(2), before the hearing). | |
| reason | No | FRCP 60(c)(1) only, required there: the reason under Rule 60(b), 1 to 6. Reasons 1 to 3 have a one-year outer limit; reasons 4 to 6 have no fixed date. | |
| district | No | Optional. The CM/ECF id of the district court, such as casd (S.D. Cal.), cacd (C.D. Cal.), nysd (S.D.N.Y.) or dcd (D.D.C.). Adds the time the last day ends where the court states it, the notes for that district, and the Ninth Circuit notes for California districts. For a district whose local rules this site applies (federal_local_deadline accepts it), it also adds that court's local rule notes and the days its posted schedule closes the court; for any other district the answer says its local rules are not applied. | |
| us_party | No | FRAP 4(a)(3), 4(a)(4) and 4(a)(5): true when one of the parties is the United States, a United States agency, or an officer or employee in one of the four categories FRAP 4(a)(1)(B) lists, which makes the appeal period 60 days. | |
| trigger_date | No | Required, except on fed-frcp-26f1 when defendant_served_date is given. The date of the event the rule counts from, in the rule's own words above: the date of service, entry, filing, the conference, or for a period counted backward the date of the later event (trial, a hearing, the scheduling conference). For a removal row, the date of receipt by the defendant, through service or otherwise, as 28 U.S.C. 1446(b) puts it, never a mailing date plus 3. | |
| frap_delivery | No | For an appeal period that runs after being served: how the paper was delivered, under FRAP 26(c). served-electronically = Served electronically: adds nothing; delivered-on-proof-date = Delivered on the date stated in the proof of service: adds nothing; other = Any other service: adds 3 days (FRAP 26(c)). | |
| service_method | No | How the paper that starts the period was served, under FRCP 5(b)(2). Only mail, leaving it with the clerk and other consented means add 3 days, and only on a period that runs after being served: 5b2C-mail = Mail (Rule 5(b)(2)(C)); 5b2D-clerk = Leaving it with the clerk (Rule 5(b)(2)(D)); 5b2F-consented-other = Other means you consented to in writing (Rule 5(b)(2)(F)); 5b2E-electronic = The court's electronic-filing system or other consented electronic means (Rule 5(b)(2)(E)): adds nothing; 5b2A-handing = Handing it to the person (Rule 5(b)(2)(A)): adds nothing; 5b2B-leaving = Leaving it at the office or home (Rule 5(b)(2)(B)): adds nothing. | |
| compliance_date | No | FRCP 45(d)(2)(B) only, required there: the date for compliance stated in the subpoena. | |
| compliance_time | No | FRCP 45(d)(2)(B) only, required there: the time for compliance stated in the subpoena, 24-hour HH:MM. | |
| outside_district | No | FRCP 4(d)(1)(F) and 12(a)(1)(A)(ii): true when the waiver request was sent to the defendant outside any judicial district of the United States. | |
| third_trigger_date | No | A third date, used only by FRCP 81(c)(2): service of the summons for an initial pleading on file. | |
| second_trigger_date | No | A second date, for a row that compares two periods: FRCP 12(a)(3) the other service date; 15(a)(1)(B) the service date of the other paper; 15(a)(3) the date the response to the original pleading was due; 16(b)(2) the date any defendant appeared; 26(f)(1) the other anchor; FRAP 4(a)(3) entry of the judgment or order; 1446(b)(1) service of summons; 81(c)(2) receipt of the initial pleading. | |
| defendant_served_date | No | FRCP 26(f)(1) only, when neither the scheduling conference date nor the date the scheduling order is due is known: the date any defendant was served with the complaint. Rule 16(b)(2) is then computed first and the conference date counted back from it, in one reading. trigger_date and second_trigger_date are ignored. | |
| defendant_appeared_date | No | FRCP 26(f)(1) only, with defendant_served_date: the date any defendant appeared, if known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description still adds substantial behavioral context: the FRCP 6(a) counting method, weekend/holiday roll-off, the conditional 3-day add under 6(d)/26(c), and the tri-part return (due date under prevailing reading, earliest, latest). It doesn't discuss rate limits or error behavior, which keeps it short of a 5.
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?
Front-loaded with the core computation, then counting rules, then return values, then the sibling redirect — good ordering. It is dense and lengthy, but nearly every clause carries information an agent needs; minor trimming of the return-value enumeration could tighten it.
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?
Despite 14 parameters and no output schema, the description covers the return shape (prevailing/earliest/latest dates, open questions, rule text, authority, countersign status) and the branch conditions. Nothing an agent needs 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 description coverage is 100% across 14 parameters, so the schema itself documents every field and enum value. The description restates the anchor-date concept and the return semantics but adds little per-parameter meaning beyond what the schema already provides. Baseline 3 is 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?
States a specific verb and resource ('Compute one federal civil deadline') and names the governing authorities it covers (FRCP, FRAP 4, 28 U.S.C. 1446/1447). It also explicitly distinguishes itself from the sibling federal_local_deadline for local-rule deadlines, so an agent can route correctly without opening a schema.
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?
Says clearly when to use it (from the date of the event the rule counts from) and redirects the local-rule case to federal_local_deadline with the exact condition that selects that sibling. The counting and 3-day-add rules are stated as conditions, not left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the legal holidays for a year under FRCP 6(a)(6) and FRAP 26(a)(6): the eleven days in 5 U.S.C. 6103(a), the Friday observed for a Saturday holiday (5 U.S.C. 6103(b)(1)), the Monday observed for a Sunday holiday (Executive Order 11582), and the days the President closed the executive branch. These are the days a federal deadline rolls off. Each observed or closure day says which reading treats it as a legal holiday and that the point is not settled. State holidays are not applied.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Four-digit year, 2024 to 2030. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only and closed-world, so the description carries the real burden and does: it discloses the inclusion rule set (eleven statutory days, Friday/Monday observance, presidential closures) and warns that each ambiguous day is flagged as unsettled rather than silently resolved. It also states the state-holiday exclusion, which materially affects results.
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 scope and ending with the exclusion — every clause carries scope information. The stacked statutory parentheticals are dense but each one defines a distinct category of holiday, so they earn their 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 reference tool with no output schema, the description covers inclusion rules, ambiguity handling, and exclusions, which is everything an agent needs to trust and use the result. Nothing material is left to inference.
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% and the single `year` parameter already documents its 2024-2030 range, so the schema does the work. The description adds nothing about the year argument beyond implying a single year is evaluated; baseline 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?
States a specific verb and resource ("List the legal holidays for a year") and pins the scope to named authorities (FRCP 6(a)(6), FRAP 26(a)(6), 5 U.S.C. 6103). The enumeration of what counts as a holiday makes it clearly distinct from the sibling tools that count days or compute 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 sentence "These are the days a federal deadline rolls off" gives a concrete use context, and "State holidays are not applied" is an explicit exclusion. It does not, however, name a sibling or say when to prefer federal_count_days or federal_deadline over this reference list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a deadline a federal district court's own local rules set, for the districts whose local rules this site applies: a motion, an opposition or a reply counted back from the hearing date, and the court's other periods the rules fix. Give the rule as the court's own citation or a row id; rule "list" returns the district's rows and the date each counts from. Counts under FRCP 6(a) and the court's computation rule, applies the days the court's posted schedule closes it and the court's own mail rule, and returns the due date under the prevailing reading with the earliest and latest dates where the readings differ, the federal date a local rule replaces, the time of day where the rule sets one, the court's notes, the rule text and the countersign status. A district this site does not cover returns the districts it does.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes | Required. The row to compute: a row id from the list, the court's own citation as its local rules print it (for example "CivLR 7.1.e.1"), matched without regard to case, or "list" for every row this site computes for the district. A citation that names more than one row returns those rows and computes nothing; an unknown one returns the district's citations. | |
| district | Yes | Required. The CM/ECF id of the district court, such as "casd". Only districts whose local rules this site applies are accepted; any other id returns the list of those that are. | |
| schedule | No | Optional. true returns every paper of the briefing schedule the row belongs to, for the one hearing date in trigger_date, with the dates under FRCP 6(c) alone beside them. | |
| trigger_date | No | Required unless rule is "list". The date the row counts from, in the row's own words (the list gives them): for a motion, opposition or reply, the hearing date; for an earliest-hearing row, the date the papers will be filed. | |
| service_method | No | How the paper was served, under FRCP 5(b)(2), on a row whose date depends on it (the list says which). A local rule's own extra days for mail, or Rule 6(d)'s 3 days, are added only where that rule reaches the row and the method calls for it: 5b2C-mail = Mail (Rule 5(b)(2)(C)); 5b2D-clerk = Leaving it with the clerk (Rule 5(b)(2)(D)); 5b2F-consented-other = Other means you consented to in writing (Rule 5(b)(2)(F)); 5b2E-electronic = The court's electronic-filing system or other consented electronic means (Rule 5(b)(2)(E)): adds nothing; 5b2A-handing = Handing it to the person (Rule 5(b)(2)(A)): adds nothing; 5b2B-leaving = Leaving it at the office or home (Rule 5(b)(2)(B)): adds nothing. | |
| second_trigger_date | No | Only on a row that asks for a second date (the list says which): the other date of a row that takes the later of two periods, or the date a federal rule's own period counts from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses computation under FRCP 6(a), schedule closures, the court's mail rule, return of prevailing/earliest/latest dates, replaced federal dates, time-of-day details, notes, rule text, and countersign status. It also explains fallback behavior for uncovered districts and ambiguous or unknown rule citations.
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 is front-loaded and the description is dense with relevant detail rather than filler. It is somewhat run-on and could be easier to scan, but every part contributes to understanding the tool's scope and behavior.
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 six parameters, high schema coverage, lack of an output schema, and complex legal computation, the description is complete. It explains inputs, computation behavior, return contents, and district-coverage fallback.
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 carries the main parameter semantics. The description reinforces the rule input and "list" behavior, but adds little beyond what the input schema already documents.
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 and resource: compute a deadline set by a federal district court's local rules, including motion/opposition/reply periods counted from a hearing date. It is clearly a local-rule deadline tool, though it does not explicitly contrast itself with sibling federal_deadline or federal_count_days.
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?
It explains how to identify the rule to compute, including the special "list" value and citation/row-id matching, and scopes itself to covered districts. However, it does not explicitly say when to use this tool instead of federal_deadline or federal_count_days.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
federal_count_daysfederal_deadlinefederal_legal_holidaysfederal_local_deadlineFederal rules and deadlines
Judge-level filing rules, court holidays and enforcement data for US federal and state courts.
Computes California state court deadlines and cites the code section behind every date. No API key.
Free US federal court case lookup: status, judge, filings, deadlines. Then watch it for new filings.
Add one secure layer between your agents and this server.
