Skip to main content
Glama

Court Delta

An attorney's court calendar (hearings) by North Carolina (NC) State Bar number

get_attorney_hearing_calendar
Read-only

"What am I in court for today?" — an attorney's HEARING CALENDAR.

Returns every scheduled hearing in the date range: date and time, case number, caption, hearing type, judge and courtroom. Defaults to TODAY in North Carolina (NC) when no dates are given, so get_attorney_hearing_calendar(bar="21262") is exactly "what's on my calendar today".

THIS IS THE TOOL FOR "TODAY", "TOMORROW", "THIS WEEK" AND "MY CALENDAR". search_cases_by_attorney is a different question: it lists the cases an attorney is of record on and its file_date_* filters bound WHEN A CASE WAS FILED. A case filed in 2023 has hearings today, so filtering that tool's file date to today returns cases OPENED today — almost always nothing. Never substitute it for this.

PASS EITHER bar OR BOTH last AND first. A lone first or last name is rejected. PREFER THE BAR NUMBER whenever the user can supply it: it resolves to exactly one attorney, and a name may not.

READ attributable BEFORE ATTRIBUTING THE CALENDAR TO ANYONE. True means these hearings belong to exactly one attorney; false means they do not and must not be described as one person's day. On a BAR search it is always true and attorney_name is null — the hearing search returns no name, so that null means "not reported", not "ambiguous".

A NAME SEARCH MAY NOT BE ATTRIBUTABLE. The hearing grid has no attorney column, so if a name matches several attorneys their hearings come back MERGED with no way to tell whose is whose. To catch this the tool cross-checks the name against the case index and reports matched_attorneys:

  • exactly one match -> attorney_name is set; treat the calendar as that person's

  • more than one -> the calendar spans them all and CANNOT be split. Say so and ask for a State Bar number. Do not present it as one lawyer's day.

  • none -> no cases exist under that name, so an empty calendar may mean the name is wrong rather than the day being clear.

The cross-check is evidence, not proof — a single match still warrants preferring the bar number when the answer decides whether someone travels to a courthouse.

SLOW ON A CACHE MISS — 30-120 seconds, because it drives a real browser through two CAPTCHAs. Tell the user you're pulling their calendar and let it run. This is the opposite of search_cases_by_attorney, which is fast and needs no warning. Repeat calls for the same search and range are served from a 6-hour cache and return instantly; cached: true with fetched_at tells you which you got. If the answer is being used to decide whether to appear somewhere, quote fetched_at.

AN EMPTY CALENDAR IS A REAL ANSWER, BUT ONLY WHEN THE LOOKUP SUCCEEDED. If the call returns an error, the calendar could NOT be checked — say that, and never turn it into "you have nothing scheduled". Those differ by someone missing court.

Covers all 100 counties at once; there is no county filter on this search. Public record. Read-only. NC only. Informational, not legal advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
barNo
endNo
lastNo
firstNo
startNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint annotation by disclosing real behavioral traits: it is slow on cache miss (30-120 seconds, drives a browser through CAPTCHAs), uses a 6-hour cache with cached and fetched_at fields, and returns merged results for ambiguous name searches. It also explains the meaning of an empty calendar versus an error, which is critical for safe interpretation. No contradiction exists with 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.

Conciseness4/5

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

The description is long but well-structured with clear labeled blocks and front-loaded core purpose. Every major section adds necessary context, but there is some repetition, such as restating that merged results must not be presented as one lawyer's day in multiple places. It is appropriately sized for the complexity, though a light trim would make it tighter.

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?

Given the complexity, the output schema, and minimal annotations, the description is exceptionally complete. It covers invocation parameters, attribution risks, performance expectations, cache behavior, error interpretation, jurisdictional scope, and even user-facing expectations like telling the user the lookup takes time. There is no significant missing context an agent would need to safely use this tool.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining the relationship between bar, last, and first, including the rule that a lone first or last name is rejected. It also clarifies date defaults (today in NC when no dates are given) and the behavioral meaning of bar searches versus name searches, including the null attorney_name on bar searches. This gives an agent all semantic context needed to construct valid calls.

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 opens with a concrete question and immediately states the resource: 'Returns every scheduled hearing in the date range: date and time, case number, caption, hearing type, judge and courtroom.' It also clearly differentiates from the sibling search_cases_by_attorney by explaining that the sibling answers a different question about cases of record, not hearing dates. The verb 'returns' plus the enumerated output fields and the explicit 'THIS IS THE TOOL FOR TODAY...' make the purpose unmistakable.

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?

Usage guidance is explicit and actionable: 'THIS IS THE TOOL FOR "TODAY", "TOMORROW", "THIS WEEK" AND "MY CALENDAR".' It directly warns against substituting search_cases_by_attorney because file-date filters refer to filing dates, not hearing dates. It also provides precise parameter usage rules ('PASS EITHER bar OR BOTH last AND first', 'PREFER THE BAR NUMBER') and cautions to check attributable before attributing the calendar.

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