Skip to main content
Glama

Court Delta

Find an attorney's cases by North Carolina (NC) State Bar number

search_cases_by_attorney
Read-only

Cases where an attorney is counsel of record — by bar number OR by name.

"What's on my docket?" for a lawyer or firm. Returns the case number, caption, filing date, case type and county for every case the register lists that attorney on. Each case_number goes straight into lookup_court_case.

EVERY ROW NOW CARRIES case_status, with no enrich needed — so do not call lookup_court_case merely to find out whether a case is open or closed. The returned text is FINER-GRAINED than the four filter values: alongside "Pending" and "Disposed" you will see "Disposed - Voluntary Dismissal", "Disposed - Dismissal on Order of the Court", "Disposed - Clerk of Superior Court" — i.e. HOW it ended, not just that it did. So never test it with equality against the filter vocabulary (status == "Disposed" misses most disposed rows); match on a prefix, and quote the portal's own wording when you report it.

FAST — about 3-15 seconds. This uses the portal's own attorney-search mode, not the slow WAF-and-CAPTCHA hearing scrape, so do NOT warn the user about a long wait here.

PASS EITHER bar OR BOTH last AND first — a first name alone or a last name alone is rejected. Prefer the bar number when you have it: it resolves to exactly one attorney, whereas a name can match several.

WHEN A NAME MATCHES MORE THAN ONE ATTORNEY, attorney_name comes back NULL and matched_attorneys lists everyone matched — the results are then a MERGED docket spanning all of them. Say so and offer to narrow by bar number; do not present it as one lawyer's caseload. When exactly one attorney matched, attorney_name is set, and it is worth echoing so the user can confirm it resolved to who they meant.

case_status="Pending" is usually what someone means by "my cases" — without it you get their entire history, which for a working attorney is mostly closed matters and will hit the cap below. Old cases legitimately remain Pending, so a 2016 case in a Pending list is not necessarily an error.

THE 200-CASE CAP IS REAL AND IT BITES HERE. truncated: true means matches are MISSING, not merely unshown — a busy defender or a large firm exceeds 200 routinely. case_status and file_date_start/file_date_end narrow SERVER-SIDE and genuinely recover cases; county does NOT — it filters after the cap, so a truncated county-filtered count is a lower bound, not a county total. Say the list is incomplete rather than presenting it as the attorney's full caseload.

A DATE RANGE MAY NOT BE ENOUGH ON ITS OWN. Measured: bar 21262 restricted to cases filed in 2024 still returned 200 truncated: true, spanning only 20 Nov – 31 Dec. Narrow to a few months and check truncated again rather than assuming one year fixed it.

Dates: ISO YYYY-MM-DD or MM/DD/YYYY — both accepted. file_date_* is WHEN THE CASE WAS FILED, not when a hearing is. For "what's on my calendar today", use get_attorney_hearing_calendar — filtering by file date answers a different question and will usually return nothing.

"OF RECORD" IS NOT "CURRENTLY REPRESENTING". This is what the register records, so withdrawn, substituted and long-closed representations still appear. Do not describe the result as someone's active caseload.

Public record — the portal offers this same search to anyone, so this is not a private view of a firm's book of business.

Read-only. North Carolina (NC) only. Informational, not legal advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
barNo
lastNo
firstNo
limitNo
countyNo
case_statusNo
file_date_endNo
file_date_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?

Annotations only provide readOnlyHint and openWorldHint, but the description discloses far more: 3-15 second latency, merged dockets when multiple attorneys match, finer-grained case_status values that break equality checks, the 200-case cap where truncated means missing rows, and county filtering happening after the cap. It also clarifies that 'of record' does not mean 'currently representing.' No contradiction with 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 and dense, but it is front-loaded with the core purpose and each warning block addresses a distinct real failure mode. A small amount of legal boilerplate and some repeated emphasis on truncation keep it from being perfectly concise, though the length is largely justified by the tool's complexity.

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?

For a tool with 8 parameters, no schema-level descriptions, and several sibling tools, the description is exceptionally complete. It covers invocation requirements, return-field nuances, edge cases like `truncated` and `matched_attorneys`, and explicit routing to alternatives, so an agent has what it needs to select and call the tool correctly.

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 carries the full burden and mostly succeeds. It explains bar/last/first combination rules, preferred identifier, file_date_* formats and meaning, case_status filtering caveats, and county's post-cap behavior. Only `limit` is left implicit, but the 200-case cap discussion makes its effect inferable.

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 opening sentence states exactly what the tool does: find cases where an attorney is counsel of record, by bar number or by name. It also lists returned fields (case number, caption, filing date, case type, county) and is clearly distinguished from siblings like search_cases_by_party and lookup_court_case.

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?

The description gives explicit invocation rules: pass either bar OR both last and first, prefer bar when available, and use get_attorney_hearing_calendar for calendar-type questions. It also tells agents when NOT to call lookup_court_case, when to warn about wait times, and how to handle multi-attorney or truncated results.

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