Return recorded KYJ profile or courtroom-rule changes since a date. Change tracking begins at the launch date, so an empty result does not prove that no earlier real-world rule changed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | Yes | Inclusive date in YYYY-MM-DD format | |
| court_slug | No | Optional canonical court slug | |
| judge_slug | No | Optional canonical judge slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: change tracking starts at launch date. This adds context beyond annotations (which are absent). However, it doesn't mention whether the tool supports pagination, how to handle large result sets, or what the return format looks like.
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 two sentences long, one focused on purpose, the other on an important constraint. It is front-loaded and efficient, with no wasted words.
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 there is no output schema, the description could explain what the result set contains (e.g., list of change objects with fields). The launch-date caveat is valuable, but the overall completeness is adequate rather than thorough.
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 75% with the `since` parameter described as 'Inclusive date in YYYY-MM-DD format'. The description adds no further parameter semantics beyond what the schema provides. Since coverage is high, 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?
The description clearly states the tool returns recorded KYJ profile or courtroom-rule changes since a date. It distinguishes itself from siblings like get_judge_profile and get_courtroom_presentation_rules which retrieve static information, not recent changes.
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 the important caveat that change tracking starts at launch date, so empty results don't prove no earlier changes occurred. However, it does not explicitly state when to prefer this over other tools or mention alternatives for before-tracking-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: finding judges, retrieving biography, profile, presentation rules, AI abuse cases, or recent changes. There is no overlap or ambiguity; descriptions further clarify boundaries.
All tools follow a consistent verb_noun pattern with snake_case (find_*, get_*). The naming is predictable and easy to interpret, aiding agent selection.
With 6 tools, the set is well-scoped for a judge and courtroom information server. Each tool addresses a distinct need without bloat or triviality.
Core workflows (finding judges, retrieving bio/profile, presentation rules, tracking changes) are covered. A potential minor gap is a tool for historical courtroom rules or direct case lookups, but the current set supports common use cases adequately.
