Skip to main content
Glama

deadlines_from_trigger

Read-only

Every deadline that follows one trigger event, like a docketing system: court, trigger, date in; all resulting deadlines out, each with its date, the rule citation, the official source and the 1Court rule page. Deadlines that apply only to some case types (limited civil, asbestos, PI Pathway...) are listed separately. For broad triggers (a motion hearing covers every motion type), pass kind to narrow (e.g. "Noticed motion", "Motion for summary judgment"); otherwise the usual kind is chosen and the rest are listed as other_deadlines. Ask the user for the trigger date and how the paper was served; do not assume them. Show the user the citation and source link with every date or rule. Results are not legal advice. Coverage: Deadlines: California in depth (civil, family, probate, eviction, small claims, government claims, criminal, juvenile, appeals, agencies, pre-suit clocks, special proceedings, statutes of limitations; local rules for all 58 counties), federal civil and criminal, federal bankruptcy, and a partial Texas set. Other states’ deadlines are not covered. Court directory: every U.S. county.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "rule_set": "<rule_set>",
      "trigger": "<trigger>",
      "date": "<date>"
    },
    "name": "deadlines_from_trigger"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYesDate of the trigger event, YYYY-MM-DD
kindNoFor broad triggers, the kind to select (from list_triggers kinds), or "all"
courtNoCourt id for local rules (federal and appellate)
countyNoCalifornia county slug for local rules, e.g. "los-angeles"
triggerYesTrigger id from list_triggers, e.g. "complaint_served", "motion_hearing", "trial_date"
rule_setYesRule set id: TX, CA, CA-FAM, CA-APP, US, US-BK, US-CRIM, CA-PROB, CA-UD, CA-SC, CA-GOV, CA-CRIM, CA-JUV, CA-AGENCY, CA-PRESUIT, CA-SPECIAL, CA-SOL
service_methodNoHow the triggering paper (or the summons) was served, from the trigger's service_options. Omit for personal service.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only cover readOnlyHint and openWorldHint, so the description carries real weight and delivers: how broadening/kind fallback behaves, that case-type-specific deadlines are listed separately, that citations and source links accompany every date, and a disclaimer of legal advice. It stops short of describing response shape or how many deadlines might come back, which keeps it out of the top band.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the input/output contract before the detail, and every clause carries information. The coverage sentence is a long comma-run that is harder to scan than the rest, and the stray '1Court' token is a minor blemish, but there is little filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the return-value detail an agent needs (deadline date, rule citation, official source, rule page link, other_deadlines split) plus explicit geographic and subject coverage limits, including that other states are not covered. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 behavior the schema does not: what kind actually does (select vs. default vs. all), and why service_method and date must be sourced from the user rather than guessed. It reinforces rather than merely restates the parameter docs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a concrete verb-resource-scope: 'court, trigger, date in; all resulting deadlines out,' explicitly framed as returning every deadline from one trigger rather than a single computed date. That wording distinguishes it from the calculate_deadline sibling without needing to name it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states conditions explicitly: pass kind for broad triggers like motion_hearing, otherwise the usual kind is chosen and the remainder fall into other_deadlines. It also mandates 'ask the user for the trigger date and how the paper was served; do not assume them,' which is actionable operational guidance, and points to list_triggers for trigger and kind values.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources