Court Delta
Server Details
Look up North Carolina court cases, citations, judgments, hearing dates and courthouse info.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
TDQS
Every potential overlap is explicitly resolved: the search_cases_by_* family is segmented by party type (person, business, attorney), search_judgments is contrasted with the case index, check_traffic_charge defers to lookup_court_case when a case number exists, and get_attorney_hearing_calendar is explicitly distinguished from search_cases_by_attorney. The descriptions cross-reference each other heavily, so an agent reading them will not misselect.
The dominant pattern is verb_noun with strong sub-pattern regularity: check_* (3 tools), search_cases_by_* (3 tools), plus lookup_, list_, estimate_, get_, screen_, and subscribe_to_. Two tools break the verb-first convention — court_delta_help and court_visit_info are noun phrases — a minor but noticeable deviation from an otherwise consistent set.
At 15 tools this sits at the upper edge of the well-scoped band, and the breadth of the domain justifies it: case lookup, four search modes, judgments, filings, attorney calendars, traffic guidance, expunction, scam assessment, courthouse info, and case alerts each address a genuinely distinct need. There is no filler or redundant tool.
The read-side lifecycle is fully covered: find a case by number, name, business, attorney, or batch list; inspect details, judgments, filings, and documents; obtain traffic, expunction, and scam guidance; then follow up with courthouse location info or email alerts. Every terminal tool names its next step or fallback, so there are no dead ends.
Available Tools
15 toolscheck_court_scamCheck whether a North Carolina (NC) court-payment demand is a scamARead-onlyInspect
Is this court-payment demand a scam? Assesses a contact someone received against known North Carolina (NC) court-scam patterns.
Use this when someone describes being contacted about jury duty they missed, unpaid court costs, a warrant, or a bond — and being asked to pay. Gather what they can tell you and pass it in; every field is optional, and a partial description still gets an assessment.
THE ASSESSMENT IS DETERMINISTIC, NOT A JUDGEMENT CALL. Upstream rules decide the severity; you are not being asked to estimate risk yourself. Report what comes back.
severity 2 = "Matches known scam patterns" (LIKELY SCAM). A payment method NC
courts never accept, a jury-duty demand above the $50 statutory penalty, or a cold
contact that also carries a payment demand or arrest threat.
severity 1 = "Matches some known scam patterns" (USE CAUTION).
severity 0 does NOT mean the contact is legitimate. It means none of the
patterns this tool checks for were present in what was described. Say exactly that —
never "this looks legitimate", never "you're fine". Someone reading a false all-clear
may send money. The safe next step is always to verify independently through the
court, using a number they look up themselves.
Pass the ids listed in the parameter types verbatim — they are a fixed vocabulary.
behavioral_flags accepts any of: threatened_immediate_arrest, claimed_to_be_official,
used_target_personal_details, spoofed_caller_id, gave_callback_number,
pressured_to_stay_on_line, asked_to_stay_on_phone_during_purchase,
requested_ssn_or_financial_info, transferred_to_supervisor_or_clerk,
background_noise_office_or_radio, asked_to_meet_in_person, after_hours_contact,
demanded_secrecy.
raw_description is anything else they were told, in their own words. It is used for
the assessment and to derive category tags; the text itself is not stored.
IF THEY GAVE A CASE OR CITATION NUMBER, caseLookup.status comes back "pending" —
this tool does not fetch the record. Call lookup_court_case with that number to
check whether it is real, and read the two answers together: a demand referencing a
case that does not exist is strong evidence of a scam, and a real case number does NOT
make the payment demand legitimate (scammers cite real numbers).
Always surface facts (what NC courts actually do) and reporting (where to report).
If they already sent money, point them to the FBI IC3 link in reporting.
WHEN SEVERITY IS 1 OR 2, ASK THEM TO REPORT IT. ask_them_to_report carries the ask
and the reason: reports are what show which scams are running in which NC counties
right now, so the next person who checks gets a current warning. Their minute protects
someone else. Make it an offer — if they decline, drop it. At severity 0 there is no
such field and you must not ask, because nothing has been established as a scam.
Every link you pass on — this one and the NCDOJ / FTC / IC3 ones — must keep its
https:// prefix so it is clickable. reporting.court_delta.markdown is already
formatted for that; use it verbatim rather than retyping the domain.
reporting.court_delta.url is a scam-trend tracker, NOT a law-enforcement report —
never present it as one, or as a substitute for the NCDOJ / FTC / IC3 routes.
Never asks for or transmits a name or phone number. A de-identified record — claim type, channel, county, payment method, flags, amount, severity — is stored so scam trends can be tracked. NC only. Informational, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| county | No | ||
| claim_type | No | ||
| amount_demanded | No | ||
| contact_channel | No | ||
| raw_description | No | ||
| behavioral_flags | No | ||
| case_or_citation_number | No | ||
| payment_method_requested | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint/openWorldHint annotations: it states the assessment is deterministic, explains that severity 0 does NOT mean legitimate, discloses that a de-identified record is stored, clarifies that no name or phone number is collected, and explains how severity 1/2 should trigger ask_them_to_report. No contradiction with annotations: the storage is internal trend tracking and the tool remains non-destructive to user data.
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 long but tightly packed with operational rules; it opens with the purpose and usage trigger, uses bold severity markers, and gives imperative handling instructions. A little redundancy exists (e.g., 'every field is optional' plus 'partial description still gets an assessment', and repeated 'never' cautions), but the length is justified by the safety-sensitive nature of scam triage.
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?
The description covers all needed context for safe invocation: optionality, severity interpretation, the severity-0 false-all-clear hazard, case-number interplay with lookup_court_case, reporting channels, ask_them_to_report behavior, link formatting, data storage/privacy, and NC-only scope. Even though an output schema exists, the description adds essential decision logic around those outputs, making it complete for an agent to invoke and relay results responsibly.
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?
With schema description coverage at 0%, the description compensates by explicitly listing accepted behavioral_flags, defining raw_description as free-form text used for assessment/category tags but not stored, and explaining that case_or_citation_number yields a pending status requiring lookup_court_case. Other parameters such as county and contact_channel are not individually described, though their enum/string values are self-explanatory and all fields are optional, so the remaining gap is modest.
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 first line directly asks 'Is this court-payment demand a scam?' and the description begins with 'Assesses a contact someone received against known North Carolina (NC) court-scam patterns.' This names a specific verb, resource, and jurisdiction, and it clearly distinguishes this tool from siblings like lookup_court_case or search_cases_by_party by focusing on scam-pattern assessment rather than court record lookup.
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 an explicit trigger: 'Use this when someone describes being contacted about jury duty they missed, unpaid court costs, a warrant, or a bond — and being asked to pay.' It also states NC-only scope and instructs when to route to a sibling: 'Call lookup_court_case with that number to check whether it is real.' Combining two related tools is spelled out, and the warning that a real case number does NOT make the payment demand legitimate prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_expunction_optionsWhich North Carolina (NC) expunction statute and petition form fit a caseARead-onlyInspect
Which expunction statute and AOC petition form fit how each charge ended.
Reads the case's actual per-charge dispositions and routes each one to the statute(s)
that cover that outcome, with the petition and instruction-sheet links, where to file,
and the fee. Call with no caseNumber to get the whole statute table.
CHECK automaticExpunction FIRST AND LEAD YOUR ANSWER WITH IT. Under G.S.
15A-146(a4), a case where EVERY charge was dismissed without leave, dismissed by the
court, or ended in a not-guilty/not-responsible finding — all disposed on or after
12/01/2021, with no felony dismissed pursuant to a plea agreement — is expunged BY
OPERATION OF LAW, 180 to 210 days after final disposition. NOTHING IS FILED. No
petition, no form, no fee.
When automaticExpunction.applies is true, the correct answer to "what do I file?" is
"nothing — it happens on its own between and ". Do NOT
lead with the petition forms; sending someone to a clerk with a $175 fee discussion
when the charges expunge themselves for free is a wrong answer. The petition routing is
the fallback if the automatic expunction does not in fact occur.
THIS IS THE ONE DETERMINATION THIS TOOL MAKES, and it is safe precisely because (a4)
turns only on how the charges on THIS case ended — which the record shows in full —
and not on anything person-level. determinable: false means the record could not
answer (a charge with no disposition, an unrecognised disposition); say so rather than
treating it as a "no".
EVERYTHING ELSE ROUTES. IT DOES NOT DECIDE ELIGIBILITY, and you must not present it as doing so. Three reasons, all of which belong in your answer when someone asks "can I get this expunged?":
Eligibility is PERSON-level. A disqualifying conviction anywhere bars relief, and this data cannot confirm identity — date of birth is rarely published and is masked to the year, and common names collide heavily.
A prior expunction can itself disqualify, and an expunged case is REMOVED from the court record — so the very thing that would disqualify someone is invisible here.
Some expunctions bar future ones, so which statute you petition under matters. The North Carolina (NC) Courts guidance is to consult an attorney about that choice.
"NOT YET ELIGIBLE" IS SAFE TO SAY when a waiting period plainly hasn't run — that is arithmetic. "Eligible" is never safe to say.
WAITING PERIODS come from G.S. 15A-145.5(c): 3 years for one nonviolent misdemeanour, 7 for more than one, 10 for one nonviolent felony, 15 for breaking or entering under 14-54(a), 20 for two or three felonies. THE DATE RETURNED IS THE EARLIEST POSSIBLE. The statute runs the clock from conviction OR from completion of any active sentence, probation or post-release supervision, WHICHEVER IS LATER — and completion dates are not in this record. Say the date is a floor, not a target.
family per charge: "dismissed", "acquitted", "convicted", "pjc", or "unknown". Treat
each differently:
dismissed +
withLeave: true→ the State may still REINSTATE the charge. Flag it, and note it also defeats automatic expunction under (a4).dismissed +
perPleaAgreement: true→ 15A-146 treats dismissals pursuant to deferred prosecution or conditional discharge differently from plain ones."acquitted" → found not guilty or not responsible at trial. Routes to 15A-146(a2), and qualifies for automatic expunction under (a4).
"pjc" → neither conviction nor dismissal; no statute is suggested, by design.
"unknown" → the register text didn't map (e.g. "Superior Process/ Probation Other"). The full statute table comes back instead. Do NOT guess an outcome.
An impaired-driving charge returns no statutes: G.S. 15A-145.5(a1) makes it ineligible.
G.S. 15A-146(a6): a court may grant a petition under that section WITHOUT a hearing, except where the section says otherwise. Do not tell someone to expect a hearing on a 15A-146 petition as though it were automatic.
Read-only. NC only. Informational, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| felony | No | ||
| caseNumber | No | ||
| convictionCount | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and openWorldHint annotations, the description adds substantial behavioral context: automatic expunction means 'NOTHING IS FILED,' `determinable: false` should be reported rather than treated as 'no,' impaired-driving charges return no statutes, and 15A-146(a6) makes hearings non-automatic. These traits are not inferable from the schema or annotations and materially change the agent's answer formation.
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 long and emphatic, but it is well-sectioned and front-loaded with the most critical behavior (automatic expunction). Every major paragraph earns its place given the legal complexity. Minor redundancy exists (e.g., repeated 'no petition, no form, no fee'), and the all-caps emphasis is somewhat noisy, but structure remains clear.
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?
The description is exceptionally complete on output semantics, edge cases (dismissed with leave, unknown, pjc, impaired-driving), and safety disclaimers. The main gap is input completeness: `felony` and `convictionCount` are not explained. An output schema exists and is rich, so return-value coverage is not required, but a complete callable definition should still document those two parameters.
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 0%, so the description carries the full burden, but it only explicitly explains `caseNumber` via 'Call with no `caseNumber` to get the whole statute table.' The `felony` and `convictionCount` parameters are never tied to the schema fields or given any usage semantics. Concepts like felony and conviction counts appear in legal discussion but not as parameter guidance, leaving two of three parameters effectively undocumented.
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 opens with a specific verb and resource: 'routes each one to the statute(s) that cover that outcome, with the petition and instruction-sheet links.' It also sharply distinguishes this from eligibility determination ('THIS IS THE ONE DETERMINATION THIS TOOL MAKES'), which prevents confusion with broader legal-advice tools and sibling case-lookup tools.
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 gives explicit invocation guidance: 'Call with no `caseNumber` to get the whole statute table' and 'Check `automaticExpunction` FIRST AND LEAD YOUR ANSWER WITH IT.' It also states clear when-not-to conditions: 'IT DOES NOT DECIDE ELIGIBILITY,' and warns against saying 'eligible' when only arithmetic supports 'not yet eligible.' This is far beyond basic when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_traffic_chargeCheck whether a North Carolina (NC) traffic charge requires a court appearanceARead-onlyInspect
"Do I have to go to court for this ticket?" — answered from the citation itself.
For someone holding a paper North Carolina (NC) citation, BEFORE their case is searchable. Returns waiver eligibility per charge (waivable / mandatory / conditional) plus how to ask for a reduction or dismissal. FAST — no court-portal request, unlike the other tools.
IF THE USER HAS A CASE NUMBER, USE lookup_court_case INSTEAD. It runs these same
rules on the real charges and also gives the court date and the amount owed. This
tool is for when there is no case number yet.
THE STATUTE DRIVES THE ANSWER. Pass the G.S. number printed on the citation
(e.g. "20-141(J1)", "G.S. 20-127(D)"). Without a parseable statute a charge cannot
be classified — ask the user to read the "G.S." line off their citation rather than
guessing from the offense name. unclassified lists any charge that fell through.
PASS EVERY CHARGE ON THE CITATION, not just the one asked about. Eligibility is computed ACROSS the citation: one mandatory charge forces an appearance for all of them. Reporting on a single charge in isolation gives the wrong answer — a real Wake case has two waivable charges and one DWLR, and the correct answer is "you must appear".
viaCompanionCharge: true on a charge means exactly that: it would be waivable on
its own, but AOC mandatory-appearance item #39 makes every violation on a citation
mandatory once ANY violation on it is. Never tell someone they can pay such a charge
off separately or handle it by mail — the whole citation must be appeared on. Say
which charge is forcing it, since that is usually the one they want to ask the
District Attorney about.
SPEED CHANGES THE ANSWER. With no charged speed a speeding charge comes back
conditional, not waivable: over 80 mph, or more than 15 over while over 55, is
mandatory. Pass actual_speed/speed_limit if known — or just pass the offense line
verbatim ("SPEEDING 85 IN A 65"), which is parsed for the speed.
PASS offense VERBATIM FROM THE CITATION for every charge, not a paraphrase. A few
rules cannot be decided from the statute number alone and are read off the offense
text: texting is waivable UNLESS it was while operating a school bus, and a
registration or title violation is waivable UNLESS it involves stolen, altered or
fictitious plates or certificates. Both statutes are the same either way, so a
paraphrase that drops "school bus" or "fictitious" silently turns a mandatory
appearance into "waivable". If the user summarises rather than quotes, ask for the
exact wording on the citation before answering.
county (optional) decides the reduction path: participating counties get NC's
online Guide & File link, others get the in-person District Attorney route.
A null citationOptions means these are NOT waivable-citation charges — either not
NC Chapter-20 traffic, or a serious criminal charge (impaired driving, death by
vehicle, eluding) or a felony, where "it's just a ticket" framing is wrong. Say that
plainly; do not present it as "no appearance required".
General guidance for the charges given, NOT a lookup of any real case, and not legal
advice. amountDue is always null here — there is no case to read a balance from.
| Name | Required | Description | Default |
|---|---|---|---|
| county | No | ||
| charges | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare `readOnlyHint: true`, and the description aligns with that by noting there is no court-portal request and `amountDue` is always null. It goes well beyond annotations by explaining cross-charge mandatory appearance logic, the `viaCompanionCharge` semantics, speed-based conditional outcomes, and what a null `citationOptions` means.
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 long and detailed, but the legal complexity justifies most of it. It is well-structured with clear warning sections and front-loaded purpose, though a few points (such as the across-citation mandatory appearance rule) are restated in multiple paragraphs, adding slight redundancy.
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?
Covers the tool's inputs, outputs, edge cases, alternative tool routing, and limitations ('not legal advice', not a real-case lookup). It even explains what to do when a statute is unparseable and warns against paraphrasing offenses. Nothing critical seems missing for an agent to select and use this tool correctly.
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?
With 0% schema description coverage, the description carries the full burden and succeeds. It explains that `statute` drives the answer, `offense` must be verbatim because certain rules depend on exact text, `actual_speed`/`speed_limit` affect speeding classification, and `county` determines the reduction path. This is far more than the raw schema provides.
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 opens by answering the exact user question ('Do I have to go to court for this ticket?') and states the tool's specific job: determining waiver eligibility from a paper NC citation before the case is searchable. It also differentiates itself from `lookup_court_case`, which handles cases with an existing case number.
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?
Explicitly tells the agent when to use this tool versus `lookup_court_case`: 'IF THE USER HAS A CASE NUMBER, USE `lookup_court_case` INSTEAD.' It also provides strong operational guidance, such as passing every charge on the citation and passing the offense verbatim, with concrete examples and failure modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
court_delta_helpWhat Court Delta can do (capabilities + example questions)ARead-onlyInspect
What this Court Delta server covers, with example questions.
Call this ONLY when the user asks what this server / connector can do, what data it
has, or how to use it. It is NOT a step toward answering a court question — if the
user asked about a case, a citation, a person, or a bond, skip this and call
lookup_court_case / search_cases_by_party directly. Calling this first just
delays their answer.
Takes no arguments. Returns static text; makes no court-portal request.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, and the description adds context beyond those: 'Returns static text; makes no court-portal request' discloses that no network/portal interaction occurs, and 'Calling this first just delays their answer' reveals the latency tradeoff of misusing the tool. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the capability statement, then gives the call condition, then the exclusion with alternatives, then the behavioral note. Every one of the four sentences earns its place; the length is justified by the routing nuance needed across 15 sibling tools.
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 0 parameters, a readOnlyHint annotation, and an output schema already present, the description covers everything an agent needs: what it returns, when to call it, when to avoid it, what it does not do, and that no arguments are required. Nothing necessary 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?
The tool has 0 parameters, which warrants a baseline of 4. The description explicitly states 'Takes no arguments,' confirming to the agent that invocation requires no input and that the schema's empty object is intentional, not a schema omission.
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 the purpose with specific verbs and resource: 'what this Court Delta server covers, with example questions.' It clearly distinguishes the tool from its siblings by positioning it as the capabilities/help endpoint, explicitly naming lookup_court_case and search_cases_by_party as the tools to use instead for actual court queries. An agent can tell this apart from every sibling without opening their schemas.
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 explicit when-to-use ('ONLY when the user asks what this server / connector can do, what data it has, or how to use it'), explicit when-not-to-use ('It is NOT a step toward answering a court question'), and names the alternatives with routing conditions ('skip this and call lookup_court_case / search_cases_by_party directly'). This is the model of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
court_visit_infoCourthouse location, phone and nearby parking for a North Carolina (NC) countyARead-onlyInspect
Which courthouse, where it is, when it's open, and where to park.
For "I have court on Tuesday — where do I go?". Give a county ("Wake") or a
caseNumber to derive it. From the North Carolina (NC) AOC directory plus Google Places.
RETURNS locations[], NOT ONE COURTHOUSE. 19 counties have several venues and
picking one silently is a real way to send someone to the wrong building. Wake has a
Courthouse, a Justice Center AND a Clerk's office; Guilford has courthouses in
Greensboro and High Point, in different cities. multipleLocations:true means you
must disambiguate rather than assume.
TO PICK THE RIGHT ONE, USE THE CASE'S HEARING LOCATION. lookup_court_case returns
upcomingHearings[].location (e.g. "Wake Co. Justice Center"), which usually names
the building. Match it against locations[].name, allowing for "Co." vs "County".
BUT DO NOT FORCE A MATCH: measured on real hearings, a third have "No location" at
all, and several use names that don't correspond to the directory —
"Buncombe Co. Judicial Complex" is the Buncombe County Courthouse,
"Alamance Co. JB Allen" is the Alamance County Courthouse. When it doesn't map
cleanly, SHOW THE OPTIONS and let the user choose. Guessing between Wake's Courthouse
and its Justice Center is exactly the wrong place to be confident.
HOURS ARE REAL — and watch for lunch closures. A value like "08:30-12:30, 13:30-17:00" means the venue SHUTS between those times; someone arriving at 1pm in Nash, Wilson, Cherokee or either Guilford courthouse finds a locked door. Say the closure out loud. Courts also close on NC state holidays, which these hours do not encode.
parkingAttributes are what the venue publishes — "freeLot", "paidGarage",
"onSite" etc. ABSENT MEANS NOT CLAIMED, NOT "no parking". nearbyParking (actual
lots near the building, with distanceMeters and a mapsUrl) and parkingMapUrl
(a static map image, courthouse marked "C") appear on AT MOST ONE location — the one
the scrape described. Their absence on the others is not a statement about them.
accessibility is published PER BUILDING — "wheelchairEntrance", "wheelchairParking",
"wheelchairRestroom", "wheelchairSeating", "restroom". Report what a venue claims. An
ABSENT flag is NOT a claim that the feature is missing: every venue claims wheelchair
entrance, parking and restroom, but only 15 of 121 claim accessible SEATING, and no
venue publishes assisted-listening data at all. For anyone who depends on a specific
accommodation, give what's listed and say to call the courthouse to confirm the rest —
do not report "not accessible" from a missing flag.
source:"nccourts-scrape" means the directory had no entry and this fell back to the
live site, so hours will be empty — tell the user to call rather than inventing
them. All 100 counties are currently in the directory, so this should be rare.
THIS IS LOCATION INFO, NOT CASE INFO — nothing about hearings, charges or status; use
lookup_court_case for those. Cite the disclaimer: verify with the clerk before
travelling. Read-only. NC only.
| Name | Required | Description | Default |
|---|---|---|---|
| county | No | ||
| caseNumber | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is exceptionally transparent about behavioral quirks beyond the annotations: it warns that multiple locations may be returned, hours include lunch closures, absent parkingAttributes do not mean 'no parking', and source fallback leaves hours empty. It also confirms the readOnlyHint ('Read-only') and openWorldHint ('ABSENT MEANS NOT CLAIMED'). No contradiction with annotations is present.
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 long but deliberately structured with clear sections: purpose, disambiguation, hours, parking, accessibility, source fallback, and disclaimer. It is front-loaded with the core question it answers. Minor redundancy in the repeated warnings about not guessing between courthouses makes it slightly less concise than ideal.
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 tool with subtle real-world pitfalls, the description covers nearly everything an agent needs: return shape, multi-location handling, matching against hearing locations, lunch closures, parking semantics, accessibility semantics, source fallback behavior, and when to route to another tool. The output schema exists, so the description doesn't need to enumerate return fields; the behavioral caveats are what matter and they are thoroughly addressed.
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 0%, so the description must carry parameter meaning. It does: it explains that `county` expects a value like 'Wake' and that `caseNumber` can be used to derive the county. The sole gap is that it doesn't discuss precedence or behavior when both parameters are supplied, and it doesn't give a caseNumber format example. Still, it compensates well for the schema's silence.
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 opens with a specific statement of what the tool provides: 'Which courthouse, where it is, when it's open, and where to park.' It also explicitly distinguishes itself from case-related tools: 'THIS IS LOCATION INFO, NOT CASE INFO.' This clearly separates it from siblings like 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context: 'For "I have court on Tuesday — where do I go?"'. It names the alternative tool, lookup_court_case, for case info, and provides detailed disambiguation guidance involving upcomingHearings[].location. It even tells the agent when NOT to force a match and to show options instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_license_pointsEstimate North Carolina (NC) driver's-licence points for traffic chargesARead-onlyInspect
Driver's-licence points under G.S. 20-16(c) — a COMPARATOR, not a lookup.
Returns what each possible outcome would cost: convicted as charged, reduced to improper equipment, prayer for judgment, or dismissed. That comparison is the useful answer; a single number is not. Fast — no court-portal request.
LICENCE POINTS ONLY. Insurance (SDIP) points are a SEPARATE system with different values, set by the Rate Bureau rather than statute, and are NOT included. If someone asks what a ticket will do to their premium, say this tool doesn't cover that.
THE PJC SCENARIO'S ZERO HAS TWO EXCEPTIONS and you must state them. Under G.S. 20-4.01(4a) a prayer for judgment counts as a CONVICTION — so it does carry points — if it is the THIRD OR SUBSEQUENT PJC within any five-year period, or for ANY PJC where the driver holds a CDL or the offence was in a commercial vehicle. Prior PJC history is not in court records here, so the 0 assumes neither applies.
unmatched[] LISTS CHARGES THAT COULD NOT BE SCORED — always mention them. The
schedule has a real "All other moving violations = 2" row, so a charge that matched
the catch-all (viaCatchAll: true) and one we failed to classify are different
things; do not let a total silently omit either.
Non-Chapter-20 charges score nothing at all — a drug or assault charge is not a traffic offence and gets no points. Non-moving violations (improper equipment, parking, inspection, registration, adult seat belt) are 0, which is why "reduce to improper equipment" is the standard outcome people seek.
SPEEDING TURNS ON ABSOLUTE SPEED, not how far over the limit: the schedule row is
"speeding in excess of 55 mph = 3". 50-in-a-45 is 2, not 3. Pass actual_speed when
known — without it a speeding charge cannot be scored and lands in unmatched.
POINTS ARE NOT THE WHOLE CONSEQUENCE OF A SPEEDING CONVICTION. Check
excessiveSpeedingSuspension and report it whenever it applies. G.S. 20-16.1(a)
mandates a 30-DAY LICENCE SUSPENSION, imposed by the Division without a preliminary
hearing, on conviction of either (i) more than 15 mph over the limit while ALSO above
55 mph, or (ii) any speed above 80 mph. This is separate from and additional to points.
An 85-in-a-65 is only 3 points but ALSO costs the licence for 30 days — reporting the 3
alone is a true number that leaves a false impression. Pass speed_limit as well as
actual_speed: without the limit, branch (i) cannot be assessed and the tool abstains
(determinable: false) rather than implying there is no suspension.
That suspension attaches only ON CONVICTION, so a reduction, PJC or dismissal avoids it — which is usually the single biggest factor in the comparison, bigger than the points.
G.S. 20-16.1(b)(1): on a FIRST conviction only, the trial judge "may when feasible" allow a limited driving privilege for purposes reasonably connected with the HEALTH, EDUCATION AND WELFARE of the person convicted and their family. There is no listed "work" privilege — employment is commonly argued under welfare, so do not describe it as a work privilege as though the statute named one. The permit is valid for 30 days from issuance and the judge may restrict days, hours, vehicle types and routes.
THIS TOOL CANNOT TELL WHETHER IT WOULD BE A FIRST CONVICTION — prior convictions are not in the record, so the seven-year look-back cannot be applied. The privilege is discretionary and conditioned on feasibility. Answer "you can ask the court", never "yes, you will get one". Do NOT import limited-privilege rules from the DWI statute (G.S. 20-179.3); there is no "hard suspension period" concept in G.S. 20-16.1.
SUSPENSION FOR ACCUMULATED POINTS is a different mechanism again, with TWO thresholds
(G.S. 20-16(a)(5)): 12 points in three years, and 8 in
the three years after a licence is reinstated. Pass priorPoints and
recentlyReinstated if the user knows them — neither is in any court record, so
without them no suspension assessment is made.
Set commercialLicense or outOfStateLicense and the tool REFUSES rather than
guessing: a separate, higher schedule applies to CDL holders, and an out-of-state
conviction is assessed by the licensing state under the Driver Licence Compact.
Informational, not legal advice. Whether a reduction or PJC is actually available is a decision for the District Attorney and the court.
| Name | Required | Description | Default |
|---|---|---|---|
| charges | Yes | ||
| priorPoints | No | ||
| commercialLicense | No | ||
| outOfStateLicense | No | ||
| recentlyReinstated | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This goes far beyond the readOnlyHint by disclosing that PJC is zero only absent two exceptions, that unmatched[] must always be reported, that excessiveSpeedingSuspension is a separate mandatory 30-day suspension, that the tool abstains with determinable:false when speed_limit is missing, and that it refuses CDL/out-of-state cases rather than guessing. There is no contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is sectioned and front-loaded with the core comparator behavior and outcome list. Each major caveat is signposted with uppercase headers, making it navigable, though some legal background could be trimmed without losing essential meaning.
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 high-complexity legal estimator, the description is complete: it covers scope, exclusions, exceptions, required parameter combinations, and output caveats such as unmatched[] and determinable:false. Since an output schema exists, the description does not need to repeat return-value details.
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?
Despite the 0% schema description coverage, the description explains the meaningful behavior of the key parameters: actual_speed and speed_limit are required for speeding charges, priorPoints and recentlyReinstated drive the two accumulation thresholds, and commercialLicense and outOfStateLicense cause refusal. It also adds legal context to the charges object (catch-all versus unmatched) that the schema does not provide.
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: it estimates NC driver's-licence points under G.S. 20-16(c) and immediately defines itself as 'a COMPARATOR, not a lookup.' It also clearly scopes itself to licence points only, which helps distinguish it from insurance-point questions and other traffic-related sibling tools.
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 gives explicit when-not guidance: insurance SDIP points are excluded, non-Chapter-20 charges score nothing, non-moving violations score zero, and CDL or out-of-state license holders are refused. It does not explicitly name an alternative sibling tool, but the context is clear enough for an agent to route the request correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_attorney_hearing_calendarAn attorney's court calendar (hearings) by North Carolina (NC) State Bar numberARead-onlyInspect
"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_nameis set; treat the calendar as that person'smore 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.
| Name | Required | Description | Default |
|---|---|---|---|
| bar | No | ||
| end | No | ||
| last | No | ||
| first | No | ||
| start | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
list_cases_filedList North Carolina (NC) court cases filed by case type, county and dateARead-onlyInspect
What was FILED — every case of a given type in a county over a date range.
Answers "what IF cases were filed in Surry County yesterday?", "show me the estate
cases opened in Wake this week", "how many civil suits were filed in Mecklenburg on
Monday?". This is the DOCKET axis. The other searches are name axes — use
search_cases_by_party / _business / _attorney when you know WHO, and this when
you know WHAT and WHEN.
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.
date_start/date_end are the FILED date, not a hearing date. A case filed in
2023 can have a hearing today — for "who is in court today", use
get_attorney_hearing_calendar. Accepts YYYY-MM-DD, or the words "today" and
"yesterday" (resolved in North Carolina (NC) time).
Defaults to YESTERDAY, not today, when no date is given, and says so in
date_note. Today's filings are still being keyed in by clerks, so a "today" answer
is a partial set that reads like a complete one.
case_type is a case-number PREFIX, not a type code. CR also returns CRS;
CV also returns CVD and CVM. Read case_type_breakdown before reporting a
count as "42 CR cases" — some of them may be CRS.
Common types: IF infraction (traffic), CR/CRS criminal, CV/CVD/CVM civil,
E estate, SP special proceeding, M civil misc. judgment (liens, lis pendens).
Completeness. The portal caps a search at 200 cases; this splits the query by
date and case-number prefix to get past that. If truncated is true the count is a
LOWER BOUND, and incomplete_prefixes names the exact buckets that were not
read — say what is missing rather than reporting the number as a total. The remedy
is a shorter date range or a county.
An empty result is a real answer, but only when the lookup succeeded. On an
upstream failure this returns an error; never report that as "nothing was filed".
county_filter: "server" means the county was applied by the portal itself before
its cap, and every row is additionally checked against the county code embedded in
its case number — so a county-filtered result here is exact, unlike the
location-substring filter the name searches use.
A date range is required (max 31 days) — an unbounded search cannot be completed. Read-only public record, North Carolina only. Informational, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| county | No | ||
| offset | No | ||
| date_end | No | ||
| case_type | Yes | ||
| date_start | No | ||
| case_status | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark readOnly and openWorld hints; the description goes far beyond by revealing defaults (yesterday, not today), partial-data risks for today's filings, the 200-case portal cap with truncation semantics, the 'server' county filter guarantee, and the finer-grained case_status values. This is substantial behavioral context that annotations alone could not convey.
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 long but every section earns its place by preventing real misuses: defaults, prefix semantics, truncation handling, and empty-result interpretation. It is front-loaded with the core purpose and sibling differentiation, then organized with clear bold labels, making the length navigable rather than bloated.
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 tool's complexity, output schema availability, and the many edge-case traps, the description is remarkably complete. It addresses required date-range limits, truncation, incompleteness prefixes, error handling, county exactness, and status reporting rules, leaving no critical operational gap for an agent selecting or invoking the tool.
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 0%, so the description carries full weight for parameter meaning. It thoroughly explains date_start/date_end formats and semantics, case_type as a prefix rather than exact code, case_status granularity and prefix-matching requirement, and county_filter's 'server' special value. Only limit/offset lack explicit exposition, but their defaults and the portal-cap context make their role inferable.
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 leads with a specific verb and resource: 'What was FILED — every case of a given type in a county over a date range.' It immediately distinguishes itself from the sibling name-axis searches and provides concrete example questions, making it unmistakable which tool to invoke for docket-oriented lookups.
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 explicitly names alternatives: use search_cases_by_party/_business/_attorney when you know WHO, use get_attorney_hearing_calendar for today's hearings, and avoid lookup_court_case just for case status. It also clarifies when an empty result is a real answer versus an upstream failure, leaving no ambiguity about when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_court_caseLook up a North Carolina (NC) court case (by number, citation, or hash)ARead-onlyInspect
Look up a North Carolina (NC) court case or traffic citation.
Provide a case number (e.g. "26CV001234-012"), a citation number
(e.g. "92403H2"), OR a portalSessionRef from a search_cases_by_party row.
caseNumber is the STABLE, canonical identifier — prefer it for anything that
isn't an immediate follow-up. portalSessionRef is a fast path that resolves an
already-searched case without re-running the portal search. Its lifetime is
UNSPECIFIED and not guaranteed — the value rotates on every search and should be
treated as short-lived (it survives at least minutes; the upper bound is unmeasured);
never persist or reuse it. (caseHash is accepted as a deprecated alias for
portalSessionRef.)
Returns case status, upcoming and recently-elapsed hearing dates/times/
locations, charges (including speed fields for traffic cases), and — for
traffic charges — whether each charge is waivable or requires a court
appearance under the NC AOC schedules, plus how to request a reduction or
dismissal (online via NC Guide & File when the county participates, else in
person via the District Attorney) in citationOptions.howToRequest.
Read-only: no email is sent and nothing is saved. North Carolina only. Informational, not legal advice.
EVERY LOOKUP ENDS WITH TWO THINGS, PER CASE. Both are spelled out in
present_to_user, the FIRST key of this result, already filled in for this
particular case — read it and do what it says.
(1) caseSummaryUrl — hand it to the user and call it the durable, shareable link
to the full case record. It does not expire, it is publicly viewable, and the same
case returns the same link every time, so it is the canonical way to cite or share
the case. THE KEY IS ALWAYS PRESENT, so "when it appears" is not the test — the
VALUE is: non-null means give it; null means minting failed on this lookup, so say
nothing about a link rather than substituting trackThisCase.url, a portal URL, or
a guess.
(2) alerts — when alerts.available is true, ask whether they'd like email alerts
when the case changes: a new court date, case information, case events, service
events, or financial updates. ASK and wait for a yes. Never call
subscribe_to_case_updates on your own initiative and never invent an email address.
When available is false the case is closed, disposed, or not found — nothing would
ever be sent — and you must not raise it.
IN A MULTI-CASE TURN DO BOTH FOR EACH CASE, beside that case's own details. Two
cases means two links and two offers; one combined link, or a single offer at the
end of the answer, is wrong.
(A search row's portal_url is ephemeral by contrast — don't present that as
durable or persist it.)
upcomingHearings lists only FUTURE hearings; pastHearings lists recently-
elapsed ones (most recent first). The top-level status of "no_upcoming_hearings"
means exactly that — NOT that the case has no hearing history. Before telling the
user they have no court date, check pastHearings: an empty upcomingHearings
with a non-empty pastHearings means a hearing has ALREADY occurred (they may
have missed it) — a different answer than "nothing scheduled." Never infer "you
didn't miss court" from an empty upcomingHearings/status alone.
service answers "was the defendant actually reached?" on civil / SP / estate cases
— the civil-side counterpart to bailRisk, and null on criminal/traffic, where
service of process does not apply (null there = NOT APPLICABLE, not "not served").
Read status FIRST; three of its values mean the absence of a return is EXPECTED and
must never be reported as "not served":
served/unserved/mixed— a return of service is docketed.mixedmeans both outcomes appear (several defendants, or the alias-and-pluries retry cycle).proven_other— a certificate / affidavit / acceptance of service instead of a formal return. Still proof.appeared_service_moot— the defendant answered or appeared, which waives a service defect. Service became unnecessary.not_required— an appeal or petition; no summons is issued at all.pending— a summons went out recently and nothing is back YET. Say "service is still outstanding", NOT "they weren't served".unknown— a summons issued, nothing returned, and the case isn't new.returns[]is the full history (the retry cycle is often the story) andlatestReturnthe most recent attempt.returns[].partyis NULL about a third of the time — the docket records the outcome without naming who it applied to — so never read a null party as "nobody". For the same reason there is deliberately NO per-defendant served flag: one case in the sample had a single docketed return against 41 defendants, and a per-party boolean would be confidently wrong.legacyScan:truemeans the paper file was scanned as ONE bundle rather than itemised, so proof of service may sit inside that PDF where no docket-text rule can see it — a missing return is weak evidence on those cases.causesOfActionis the civil counterpart tocharges— the claims pleaded (cause,filedOn,remedy), e.g. "CV - Unfair Trade Practice". On a civil / SP / estate case this is usually the ONLY statement of what the matter is about, so lead with it there. An empty list means the docket does not ITEMISE causes, NOT that no claims exist — say the docket doesn't break them out rather than implying the case is about nothing. Repeated boilerplate entries are collapsed; distinct dates are kept, since a cause added later is an amendment. Each charge also carriesoffenseDate(when the offense occurred — different from the case'sfiledOn, and usually what someone means by "when was this?") andagency(the citing law-enforcement agency). If a tool returns anerrorwithretryable/upstream_status, that is a transport or portal failure — NOT a statement about the case. Never turn it into "no results" or "case not found"; say the lookup itself failed, and retry only whenretryableis true.caseCategorynormalizes the case class (criminal | civil | infraction | special_proceeding | estate | juvenile | other). Use it to read null fields correctly: on a NON-criminal category,bailRisk/citationOptions= null means NOT APPLICABLE, not "none found."partiesis the register-of-actions roster (name + roles[] + attorneys[]{name, appointment} + selfRepresented + counselWaived) —appointmentis how counsel came to the case ("Retained" = the party hired them, vs "Court Appointed" / "Public Defender"; null when unstated, and the list is learned from the register rather than a closed set). It is what makes acounselWaived:trueparty who nonetheless HAS counsel intelligible — appointed, then a waiver, then retained. The authoritative source for identifying who is on a case and their role, especially on civil/SP cases where the caption/DOB are absent; prefer it over a party-search row's caption for entity resolution.selfRepresented:true= no counsel of record (self-listed as own attorney OR a filtered counsel-absence sentinel, with no other attorney); it does NOT distinguish an active pro-se appearance from a defaulted / served-by-publication defendant.counselWaivedis a SEPARATE, independent flag — NOT a narrowing ofselfRepresented— and it is NOT a claim the party is unrepresented: it can be true while attorneys[] is non-empty (seen on 22CR702455-520, counselWaived:true with a Court Appointed AND a Retained attorney, the docket running appointed counsel -> Waiver of Counsel -> retained counsel). Always read it WITH attorneys[], never instead of it.counselWaivedis set by either Odyssey placeholder "attorney" name, filtered out of attorneys[] rather than shown as a lawyer: "WAIVED, WAIVED" (counsel affirmatively waived on the record — the docket does not say whether the waiver covered all assistance of counsel or only court-appointed counsel) or "PRO SE" (the party asserted as their own representation). Either means the party declined counsel rather than merely lacking it, but the flag does NOT say which placeholder produced it, so it is not proof the party is litigating pro se.counselWaived:falsemeans NOT OBSERVED, not "did not waive". A true value is predominantly a criminal-side artifact and is rare on civil rosters — treat it as unexpected but NOT impossible on a non-criminalcaseCategory; don't read one there as an error. A false unrepresented party is still any of defaulted / never-served / unappeared-entity / pro-se-without-a-docketed-marker — or simply TOO EARLY: on a recently-filed case that has not had a hearing yet, counsel is frequently not entered on the roster.partiesreflects what is DOCKETED, not who is retained; checkfiledOnand an emptypastHearingsbefore reading an empty attorneys[] as unrepresented — on a pending case that has not been to court, "not shown yet" is usually the better answer than "no lawyer." attorneys[] non-empty ⇒ represented ⇒ selfRepresented false.documentslists scanned filings, newest first —{date, name, url}, wherenameis the register entry that produced it ("Bond Forfeiture Notice", "Release Order Issued", "Waiver of Counsel"). Most criminal cases have at least one; an empty list means nothing is scanned in, not that nothing was filed. Offer the links when they're relevant to what was asked. Retrieval is UNRELIABLE — the portal intermittently returns errors or an empty body while it prepares a document — so present a link as something that may need a retry, never as "here is the document", and never state or guess at its contents: this server does not read them.dispositionsgives the per-charge OUTCOME behind a "Disposed" status — one row per charge withplea,disposition,sentence,dispositionDate,judge, and any judgmentdocumentUrls. This is how you answer "what happened to the case / to a charge": a "Disposed" caseStatus alone does not say whether a charge was dismissed, pled down, or convicted — readdispositionsfor that (e.g. a speeding charge reduced to improper equipment shows plea "Responsible to Lesser"; a "VD-District Dismissals ... Per Plea Agreement" is a dismissal). Empty on pending/undisposed cases.trackThisCaseis an upstream ELIGIBILITY FLAG (non-null only on an open case), not something to act on: this server already consumes it — it is what gatesalerts.available— so don't reason from it, and never showtrackThisCase.urlto the user. That is a generic signup page with no case identity. The case-specific paths arecaseSummaryUrland, once the user has said yes,subscribe_to_case_updates. For criminal cases with a bond or bail activity,bailRiskis non-null: failure-to-appear history (ftaCount, date-deduped;ftaEvents[]gives the raw counted entries {date, description} for auditing — voided "in Error/Stricken" FTAs are already excluded), FTA-triggeredordersForArrest, bond amount/type, and the NCGS §15A-544.5(f) prior-FTA bar. That bar turns on FTAs that preceded the bond's EXECUTION, not the case total:bondExecutedOnis the "Bond Posted" date for the operative bond andpriorFtasAtExecutioncounts FTAs strictly before it (null when no posting is docketed).setAsideBarInapplicable:true(0-1 prior FTAs) is RELIABLE — (f) cannot bar a set-aside. State it plainly; it's the answer that tells someone a motion is worth filing.setAsideBarPossible:true(2+ prior) is NOT a finding that the bar applies. It means only that the TIMING fits. Under (f), actual notice exists ONLY where a judicial official noted the prior failures on the defendant's release order. CheckreleaseOrderFBoxbelow before saying anything further, and never say "the forfeiture cannot be set aside" on the strength of this flag alone.Both false = execution date unknown; neither ruled out nor suggested.
releaseOrderUrlis the portal PDF of the release order governing that bond — the document the (f) question actually turns on, since the judicial official's "second or subsequent failure to appear" notation appears there (AOC-CR-200) and in NO structured field. ALWAYS present this link whensetAsideBarPossibleis true, even when the read below already answered the question: the order is the authority.releaseOrderFBoxIS THAT READ, present only on barred cases where the order could be fetched and parsed. Report it, and report it precisely — this is the field that decides whether someone spends their one motion:"unchecked" — on its face (f) does NOT bar a set-aside; the prior FTAs do not block relief and it is worth pursuing. Say so, and add that they should confirm it on the order before relying on it.
"checked" — (f) MAY bar it. Do NOT say "cannot be set aside". Tell them to confirm on the order BEFORE filing, because a motion that fails uses up the single opportunity for relief.
"ambiguous" — the order was opened and the box could NOT be read. Say exactly that, and hand over the link. The notation is a flattened checkbox with no glyph in the text layer, so the printed label appears whether or not it is marked. NEVER round this to "unchecked": a misread tells a bondsman to abandon a recoverable bond.
absent / null — no read was attempted (not a barred case, no order docketed, or the fetch failed). This is ALSO not "unchecked". Fall back to the link. For the forward-looking question ("could a bond I write NOW be barred?") use
ftaCount: 2+ FTAs on the case means the next release order should carry the judicial notation — tell the user to read it before signing. Thenforfeiturewith itsstatus(the latest DOCKETED forfeiture event — may lag the clock) and the 150-day set-aside clock (noticedOn,deadline,daysRemaining,windowOpen).noticeAnchorsays wherenoticedOncame from: "notice_event" = an explicit forfeiture NOTICE line (the date the statute runs the 150 days from); "earliest_forfeiture_event" = no notice was docketed, so the earliest forfeiture entry stands in — the deadline is then a CONSERVATIVE proxy (earlier than the true notice), anddaysFtaToNoticemeasures FTA-to-forfeiture rather than FTA-to-notice. Don't present a proxy-anchored deadline as the exact statutory date — treatwindowOpen/daysRemainingas authoritative for whether the set-aside window is open; oncewindowOpenis false the window has closed even ifstatusstill readsin_effect.deadlineNextBusinessDayis the first day the clerk's office is open on or afterdeadline(equal to it when that is already a business day; later when it falls on a weekend or NC court holiday). ADVISORY ONLY — it never movesdaysRemaining/windowOpen, which stay on the strict notice+150 date, because the safe error is telling someone they have LESS time, never more. null = UNDETERMINED (deadline year outside the published NC holiday calendar), NOT "no adjustment needed"; never present a null as though the deadline is a normal business day.triggeringFta(latest counted FTA on or beforenoticedOn) anddaysFtaToNotice(the gap in days) report HOW LONG after the failure the forfeiture notice was docketed. Report the number; do NOT call a long gap a defect or a filing error — there is deliberately no threshold flag, and whether a gap affects the notice's validity is for the reader's attorney. Plus the bondingagent(Fiduciary) +surety(insurer). All from public NC eCourts records. (citationOptionsis null on disposed/closed cases — the reduction path isn't live.) Informational underwriting signal, not legal advice; don't state legal conclusions.
| Name | Required | Description | Default |
|---|---|---|---|
| caseHash | No | ||
| citation | No | ||
| caseNumber | No | ||
| portalSessionRef | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint/openWorldHint annotations: it states that no email is sent and nothing is saved, explains unstable retrieval behavior for documents, discloses the unspecified and rotating lifetime of portalSessionRef, and warns about null-field semantics such as 'not applicable' versus 'not found'. There is no contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but front-loaded with purpose and identifier guidance before descending into field-level nuance. It is dense and sometimes repetitive in its caveats, which prevents a 5, but nearly every block conveys a distinct operational rule that an agent needs in order to avoid misleading users.
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 tool with high semantic complexity, sparse schema descriptions, and no required parameters, the description covers the full surface: all identifier modes, return-field meanings, expected versus absent values, multi-case turn behavior, error semantics, and even downstream alert subscription. Nothing an agent needs to call this tool safely appears to be 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?
The input schema has 0% description coverage, so the description carries the full burden for parameters. It does so thoroughly: caseNumber is called the stable canonical identifier, citation gets an example, portalSessionRef is tied to a search row and its short-lived/unreliable nature is disclosed, and caseHash is explicitly marked as a deprecated alias of portalSessionRef.
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 opens with a specific verb and resource: 'Look up a North Carolina (NC) court case or traffic citation.' It clearly defines the scope (NC only, read-only) and differentiates the tool from the party/citation search siblings by explaining that it resolves an already-found case into full case details, including a reference to search_cases_by_party.
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 gives concrete guidance on which identifier to prefer (caseNumber is stable and canonical), treats portalSessionRef as a fast path for immediate follow-up, and warns against persisting it. It also instructs when not to call subscribe_to_case_updates without user consent, though it does not explicitly enumerate all alternative sibling tools and their selection conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_names_by_partyScreen up to 5 people for North Carolina (NC) court cases (counts only)ARead-onlyInspect
Triage a SHORT list of people for North Carolina (NC) court cases.
Built for the "here is a list of names, which ones have cases?" question — a CSV of applicants, tenants, or bond clients. This server cannot accept file uploads: read the file yourself and pass the names as an array.
Returns COUNTS AND FACETS PER NAME, not case detail — matched, case_count,
counties, case_types, case_numbers (first few), portal_truncated. That keeps a
5-name response readable. Once you know which names are interesting, call
search_cases_by_party (full rows) or lookup_court_case (one case) on those.
LIMITS, and why they are low: each name runs a LIVE portal search, and the upstream session token is shared by every user of this service — a wide fan-out risks blocking it for everyone. Max 5 names per call, 3 at a time. Split a longer list across calls.
SLOW BY NATURE: measured ~60s for 3 names and ~2 minutes for 5. Tell the user you're checking and roughly how long it takes; don't retry on a slow response, and don't treat the wait as an error. If your client's timeout is tight, send fewer names.
PARTIAL RESULTS ARE NORMAL: one name failing (portal hiccup, timeout) does not fail
the batch — that entry comes back with an error and the rest still return. Report
which names were checked and which weren't; never present a failed name as "no cases
found", because those mean completely different things.
portal_truncated: true on a name means the portal hit its statewide 200-case cap, so
that person's count is a LOWER BOUND — narrow with county, case_status, or a filed
date range and re-run that name.
Dates: ISO YYYY-MM-DD or MM/DD/YYYY — both accepted. file_date_* bounds when
the case was FILED, not when a hearing is scheduled.
Matching is exact on last + first name (no soundex here — it broadens results and
would make a screening list noisier). A common name will match multiple different
people; case_count is "cases matching this name", NOT "cases belonging to one
person". There is no DOB or identity confirmation in this tool — do not treat a hit as
identifying a specific individual.
Read-only. NC only. Public records. Informational, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | ||
| county | No | ||
| case_status | No | ||
| file_date_end | No | ||
| file_date_start | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds substantial behavioral context: live portal searches with a shared upstream token, slow responses (~60s for 3 names, ~2 min for 5), partial batch failures with per-name errors, portal_truncated as a lower bound, exact matching with no soundex, and no identity confirmation. No statement contradicts 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place, covering limits, latency, partial results, truncation semantics, date formats, matching behavior, and disclaimers. The structure uses clear categorical labels and front-loads the primary purpose before caveats, making it scannable despite its length.
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 tool's complexity and the existence of an output schema, the description is remarkably complete: it covers rate-limit rationale, slow-response expectations, partial-failure behavior, truncation, date interpretation, exact-match semantics, identity limitations, and jurisdiction. Nothing an agent needs to call this tool 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?
With schema description coverage at 0%, the description carries the burden of explaining parameters. It explains that county, case_status, and file_date_* are narrowing filters, defines file_date_* as filing-date bounds, and specifies accepted date formats. It does not detail county value formatting or the effect of leaving filters null, but it compensates well for most of the schema's silence.
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 opens with a specific verb and resource: 'Triage a SHORT list of people for North Carolina (NC) court cases.' It immediately identifies the exact use case ('which ones have cases?') and explicitly distinguishes itself from siblings like search_cases_by_party and lookup_court_case by stating it returns counts and facets, not case detail.
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 states when to use this tool, what not to do ('This server cannot accept file uploads'), and names the alternatives: call search_cases_by_party for full rows or lookup_court_case for one case. It also gives concrete usage constraints: max 5 names per call, 3 at a time, split longer lists, and don't retry on slow responses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cases_by_attorneyFind an attorney's cases by North Carolina (NC) State Bar numberARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| bar | No | ||
| last | No | ||
| first | No | ||
| limit | No | ||
| county | No | ||
| case_status | No | ||
| file_date_end | No | ||
| file_date_start | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
search_cases_by_businessFind a company's court cases by business nameARead-onlyInspect
Cases with a COMPANY as a party — by business name.
Use this, not search_cases_by_party, whenever the subject is an organization:
an LLC, corporation, insurer, hospital, landlord, dealership or municipality.
Party search requires a first AND last name, which a business does not have, so
it cannot answer this at all.
FAST — about 5-45 seconds. No CAPTCHA. Do not warn about a long wait.
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.
TYPE THE NAME AS IT APPEARS, COMMA INCLUDED. The comma is significant and NARROWING: "FOOD LION, LLC" is a different, smaller search than "FOOD LION". Do not strip it, and do not replace it with a wildcard — advice to do that appears in the portal's help text but applies to a different search mode.
WILDCARD: a trailing * is allowed and needs AT LEAST 4 characters before it.
"WALM*" works; "WAL*" is rejected. Use it for a company whose exact registered
name you do not know ("CAROLINA TOWING*").
THERE IS NO PARTY ROLE IN THIS RESULT, ON PURPOSE. The portal labels every row
"Defendant" regardless of the truth — including cases the company FILED as
plaintiff and criminal cases where it was the victim. NEVER say the business is
the defendant. Read the side from case_name ("X VS Y" — the company's position
in the caption is the real signal), or call lookup_court_case for the actual
party list.
THE 200-CASE CAP BITES IMMEDIATELY FOR ANY CHAIN OR INSURER. results_truncated: true means real matches are MISSING. Worse, county filters AFTER that cap, so
a truncated county-filtered count is a LOWER BOUND, never a total — "11 cases in
Wake" may be 11 of the 200 statewide the portal was willing to show. Only
case_status and the file-date range narrow server-side. Say the list is
incomplete instead of reporting a count as if it were complete.
matched_businesses lists the distinct entity names actually hit. More than one
means legally separate entities are mixed together ("FOOD LION, LLC" alongside
"DELHAIZE AMERICA, LLC") — surface that rather than treating them as one company.
Dates: ISO YYYY-MM-DD or MM/DD/YYYY — both accepted. These bound WHEN THE
CASE WAS FILED, not when anything is scheduled. A year at a time is the most
effective way to get a chain's cases under the 200-cap: 'FOOD LION' unfiltered
caps out, but restricted to 2023 it returns 42 complete rows.
Public record. Read-only. North Carolina (NC) only. Informational, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No | ||
| county | No | ||
| case_status | No | ||
| file_date_end | No | ||
| file_date_start | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses extensive behavioral traits beyond the annotations. It reveals that the tool is fast (5-45 seconds), has no CAPTCHA, that case_status rows are finer-grained than filter values (so equality checks fail), that there is no party role (every row labeled 'Defendant' incorrectly), that the 200-case cap affects results and county filters happen after truncation, and that matched_businesses lists distinct entities. It also explicitly states 'Public record. Read-only.' which aligns with the readOnlyHint annotation. No contradictions.
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 long but every sentence carries essential information. It is structured with clear sections and emphasis (bold, caps) to highlight pitfalls and constraints. The primary purpose and alternative are front-loaded, followed by critical usage rules and edge cases. There is no filler; each clause adds value.
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 tool's complexity (6 parameters, output schema, many potential pitfalls), the description is remarkably complete. It covers usage guidelines, behavioral expectations, parameter nuances, and result semantics (e.g., case_status granularity, matched_businesses meaning). It also warns against common mistakes (e.g., not testing equality with filter vocabulary, not claiming the business is the defendant). With an output schema present, the description needn't explain return structure, but it still clarifies result semantics. Nothing an agent needs to call this tool 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?
Although schema description coverage is 0%, the description adds critical semantics for each parameter: name must be typed as it appears with the comma included; limit is not mentioned but default is in schema; county filter happens after the 200-case cap (so counts are lower bounds); case_status values are broad but actual results are more detailed; file_date_start/end bound filing dates and accept two formats. The description also explains wildcard behavior (at least 4 chars before *) and recommends yearly filtering to stay under the cap. This far exceeds what the schema provides.
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: find court cases by business name. It explicitly differentiates from sibling search_cases_by_party by specifying that this tool is for organizations (LLC, corporation, insurer, etc.) and that party search requires first and last names. The purpose is unambiguous and well-scoped.
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 explicit when-to-use and when-not-to-use guidance: 'Use this, not search_cases_by_party, whenever the subject is an organization.' It explains why the alternative fails for businesses. It also gives detailed usage tips: comma significance, wildcard rules, date formats, the 200-case cap, and how to handle truncation and county filters. These are actionable instructions that guide correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cases_by_partySearch North Carolina (NC) court cases by party (person) nameARead-onlyInspect
Search North Carolina (NC) court cases by a person's name.
Returns (person, case) matches from the NC eCourts party-name search. Each row
carries a case_number (the stable id) and a portal_session_ref — a Tyler token
whose lifetime is UNSPECIFIED (it rotates every search; survives at least minutes;
upper bound unmeasured). Pass it to lookup_court_case (as portalSessionRef) for a
quick follow-up; for anything persisted or delayed use case_number. Never persist
or reuse the ref. Each row also carries portal_url — the direct NC eCourts source
record; it embeds the same short-lived token, so treat it like the ref (don't persist).
caseSummaryUrl (from lookup_court_case) is the durable link.
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.
Rows carry party_type (the person's role) plus party_role_source: "caption"
= surname confirmed in the case caption (trust it); "portal_party_type" = role
from the portal's own PartyTypeKey but no caption to confirm (common on SP /
foreclosure cases — usable, but corroborate for high-stakes use); null = no role
(or a role dropped as suspect, e.g. a citing officer mislabeled "Defendant" on
someone else's caption). For an AUTHORITATIVE role/roster, call lookup_court_case
and read its parties list. party_role_verified (bool) = source == "caption".
Read-only. NC only. Informational, not legal advice.
Required: last, first. Filters differ in where they apply:
SERVER-SIDE narrowing (reduce the portal search — the ONLY way to clear the 200-case cap):
case_status("Pending"|"Disposed"|"Closed"|"Reopened"), the filed-date rangefile_date_start/file_date_end(ISO YYYY-MM-DD or MM/DD/YYYY — both accepted), and a more specific name.soundex: trueis also server-side but BROADENS (phonetic surname matching → MORE matches, more likely to truncate) — don't enable it to clear a cap.CLIENT-SIDE (filter the rows already returned; do NOT recover cases missed by the cap):
county("Wake" or "Wake County") andcase_type(pick a value from thenarrowing.caseTypesfacet).
Speed: a search runs a live portal query and takes ~15-50s, with real run-to-run
variance — do NOT pick filters for speed. Narrow for COMPLETENESS: case_status and
a file_date range are server-side and are the only filters that recover cases past
the 200-cap; county/case_type only filter what was already returned.
Two different limits:
portal_truncatedtrue = the portal hit its statewide 200-case cap, so the set is INCOMPLETE (real matches are missing). Seeportal_truncated_note; when true,narrowinggives counties only (counts are lower bounds). Clear it withcase_status/ date range / a more specific name.results_truncatedtrue = the (complete) set exceededlimit, so not all rows are shown. Pass a higherlimit(up to 200) to show them all.
Breadth (read narrowing_hint): the tool never asks you to withhold results, and it
distinguishes two cases with different remedies:
INCOMPLETE (
portal_truncatedtrue): the shown cases are valid but some are missing. Present them, and to recover the rest narrow with server-side filters (a filed-date range orcase_status) — or, if autonomous with no user to ask, re-callconfirm_broad=trueto proceed as-is.COMPLETE but long (a large set with
portal_truncatedfalse): nothing is missing. List or summarize the results; refining (county/case_type/date) is optional, not required. A moderate complete set is a fine answer on its own.
| Name | Required | Description | Default |
|---|---|---|---|
| last | Yes | ||
| first | Yes | ||
| limit | No | ||
| county | No | ||
| soundex | No | ||
| case_type | No | ||
| case_status | No | ||
| confirm_broad | No | ||
| file_date_end | No | ||
| file_date_start | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses critical behaviors: the ephemeral lifetime of portal_session_ref, truncation flags (portal_truncated vs results_truncated), fine-grained case_status values that do not match the filter enum, party_role_source trust levels, and the 15-50s runtime variance. This goes far beyond what annotations provide.
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 long, but the tool is complex with 10 parameters, two truncation limits, server-side vs client-side filtering, and token-lifetime caveats. Nearly every sentence carries operational value; the main cost is that the length requires an agent to parse several dense paragraphs, so it is not maximally concise, but it is well-structured with clear topic breaks.
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?
The description covers the full calling context: required and optional inputs, result semantics, truncation handling, follow-up tool routing, data-quality caveats, read-only nature, jurisdiction, and legal disclaimer. With an output schema present, it does not need to document return types, and 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter: last/first required, limit up to 200, county values, soundex broadening behavior, case_type sourced from narrowing.caseTypes, case_status enum plus the caution about finer-grained return values, confirm_broad for autonomous recovery, and file_date_start/end accepted formats. This is exemplary parameter-level documentation.
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 opens with a specific, unambiguous statement: 'Search North Carolina (NC) court cases by a person's name.' It clearly identifies the resource (NC eCourts party-name search), the action (search), and the scope (party/person), and the title and first sentence align exactly with the tool name and its distinguishing role among sibling tools.
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 gives explicit when-to-use and when-not-to-use guidance: it tells the agent to pass portalSessionRef to lookup_court_case for quick follow-up, to use case_number for persisted work, to NOT call lookup_court_case just to check open/closed status, and to call lookup_court_case for an authoritative role/roster. It also explains exactly which filters are server-side versus client-side and when to use them to recover truncated results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_judgmentsSearch North Carolina (NC) money judgments and criminal sentences (incl. aliases)ARead-onlyInspect
Search North Carolina (NC) money judgments and criminal sentences by party name.
This is the JUDGMENT index, NOT the case index. A judgment is what a court
ENTERED on a case — a money judgment against someone, or a criminal sentence.
Use this for "does X have a judgment against them", "how much do they owe on
it", "is it still active", "find liens/judgments before I lend or rent".
For the case itself — charges, hearings, next court date, parties, service —
use search_cases_by_party (by name) or lookup_court_case (by number).
Every row carries case_number: that is the handoff key into
lookup_court_case when the user wants the underlying case.
IT CARRIES REAL PROPERTY LIENS, WHICH IS NOT OBVIOUS. NC files these as "Civil
Misc. Judgment" records on the judgment docket, so this index — not the case
search — is where they live. cause_of_action on each row says which kind, and
the values seen in production include:
CV - Claim of Lien (G.S. 44A claim of lien on real property)
CV - Federal Tax Lien CV - NC Certificate of Tax Liability
CV - Lien CV - Employment Security Comm Lien
CV - Institutional Lien (Hospitals)
CV - Lis Pendens (pending action against the property)
CV - Transcript of Judgment (a judgment docketed from another county)
CV - Summary Ejectment, CV - Money Owed, CV - Possession,
CV - Collection on Account, CV - Other, FAM - Divorce, ...So "are there any liens against this person?" is answerable HERE, and answerable well: this index has no 200-cap, so a clean search really does mean none found.
DO NOT FILTER TO "lien" TO ANSWER "ARE THERE ANY LIENS?" — that under-reports badly.
A money judgment docketed with the clerk is ITSELF a lien on the debtor's real
property in that county, whatever its cause of action says. So CV - Money Owed,
CV - Collection on Account and CV - Transcript of Judgment rows are encumbrances
too. Measured on one name: 4 rows whose cause contains "lien", and 35 further
docketed money judgments the filter would silently drop — roughly a tenfold
under-count. For a lien or title question, DO NOT filter; report the whole set and
let the reader classify.
cause_of_action is for isolating a RECORD TYPE — "show me only the lis pendens",
"only the summary ejectments" — not for deciding what counts as a lien.
ASK WHICH RECORD TYPES THEY WANT — do not guess. Run the search, read
narrowing["Cause of Action"] (computed from the actual rows, BEFORE any filter, so
it always shows the full menu), tell them what is there, and let them choose.
cause_of_action MATCHES ON SUBSTRING AND FILTERS CLIENT-SIDE. "lien" catches
every lien variant above; "Claim of Lien" catches only G.S. 44A. Because the
index offers no server-side filter for it, the match runs over the rows already
fetched — so when results_total exceeds what was fetched, cause_of_action_note
will say the count is NOT a total. Read that note before reporting a number.
NOT in this index, and not anywhere in this server: UCC financing statements (those are NC Secretary of State), Register of Deeds records, and lien-agent notices under G.S. 44A-11.1 (liensnc.com is not a court system). Say so plainly rather than implying a clean search covered them.
Provide at least one of party, case_number, alias, or from_date.
party is a name in "LAST, FIRST" form (business names work as-is).
case_number accepts dashed or undashed. from_date/to_date bound the
date the judgment was ORDERED (not the case filing date, and not a hearing
date) — ISO YYYY-MM-DD or MM/DD/YYYY, both accepted.
A PARTY SEARCH DOES NOT COVER ALIASES, so this tool checks them for you.
party and alias are separate indexes with no overlap — measured, a search for
"WILLIAMS, PAMALA" as a party misses a judgment filed against "MCARDELL, PAMALA"
that lists "WILLIAMS, PAMALA" as an alias. Whenever you pass a full party name,
an alias sweep runs automatically alongside it and its hits come back in
alias_matches, separate from results.
READ alias_sweep.status BEFORE CALLING ANYONE CLEAR:
"ran" -> aliases were checked. Zero matches is a real negative.
"failed" -> they were NOT checked. Say so; do not report the search as clear.
"skipped" -> not applicable, EXCEPT when the reason says the name was a surname
only. Ask for a full "LAST, FIRST" name and re-run.
AN ALIAS IS NOT NECESSARILY A FORMER NAME. It is any other name recorded for that party — a maiden or married name, a hyphenated or reordered variant ("LEWIS-WILLIAMS, FARRAH" vs "WILLIAMS, FARRAH LEWIS"), or a fuller spelling ("WILLIAMS, SHANE" vs "WILLIAMS, SHANE CHRISTOPHER"). Measured, 15% share the party's own surname. Do NOT describe an alias as a name that was "changed", and do not infer a marriage or divorce from one — the record does not say.
An alias_matches row is filed against a party recorded under a DIFFERENT NAME, so
it may be the same person or an unrelated namesake. Report those rows as leads to
confirm — never state them as this person's judgments, and never merge them into a
total owed. They carry no amounts.
alias as an INPUT searches the alias index directly and takes the same
"LAST, FIRST" form ("PAMALA WILLIAMS" returns nothing). Passing it explicitly
turns the automatic sweep off, since it would repeat the same query.
Row-level debtor_aliases / creditor_aliases list other names recorded for that
party. They are populated essentially only on alias searches — empty on a party
search is normal and means nothing.
CIVIL vs CRIMINAL — read this before reporting a null. Each row has a
case_category of CV, CR or FAM. judgment_type populates on civil rows;
sentence_type populates on criminal rows. A null on either one means NOT
APPLICABLE to that row's category — it is NOT an absence of fact, and must
never be reported as "no sentence recorded" or "no judgment type".
DOLLAR AMOUNTS ARE FETCHED AUTOMATICALLY WHEN THE RESULT SET IS SMALL — do
NOT ask the user whether to pull them. Leave detail unset and this tool
decides: a case_number search, or any search returning 10 rows or fewer,
comes back with amounts already included. Check detail_included to see what
happened, and detail_skipped_reason when it didn't.
The reason it is not unconditional: detail fans out one upstream call PER
ROW. A broad name search with detail forced on has been measured timing out at
60s — "ANDERSON, DAVID" returns 153 judgments, and asking for 153 amounts at
once fails outright, whereas the same search without detail succeeds. So on a
large result set the amounts are deliberately skipped and
detail_skipped_reason tells you how to narrow (county, date range,
judgment_type, or a specific case_number). Narrow and re-run rather than
forcing it.
Override only if you must: detail=true still respects the row guard and will
not fan out over a large set; detail=false suppresses amounts entirely.
With detail, each row gains total_judgment_amount, principal_amount,
court_costs, attorney_fees, interest_rate, judgment_status and the
for/against party roster. Amounts are strings; a null means the court recorded
no value, which is different from "0.00". Where detail is null on a row, no
dollar figure is available — never infer or state an amount from such a row.
Filters:
county— a plain county name ("Wake"). Filtered SERVER-SIDE and exactly, covering both that county's District and Superior court. Unlikesearch_cases_by_party, this filter does not eat into a result cap.judgment_type— civil, comma-separated, e.g. "Recorded", "Granted in Whole or Part", "Default Civil".sentence_type— criminal, comma-separated, e.g. "Active", "Community", "Intermediate", "Fine". Every valid value for all three is returned infacetswith live counts, so readfacetsrather than guessing a filter value.
Speed: ~1-3 seconds. This tool is the FAST exception — it does NOT run the
slow WAF-gated portal search that search_cases_by_party and
lookup_court_case do, so do not warn the user about a long wait here.
Completeness: results_total is the TRUE statewide total. This index has no
200-case cap, so the truncation caveat that applies to search_cases_by_party
does NOT apply here. results_truncated reflects only the display limit;
page further with offset if needed.
Read-only. NC only. Informational, not legal advice. A name match is not an identity confirmation — same-name people are common.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | relevance | |
| alias | No | ||
| limit | No | ||
| party | No | ||
| county | No | ||
| detail | No | ||
| to_date | No | ||
| from_date | No | ||
| case_number | No | ||
| judgment_type | No | ||
| sentence_type | No | ||
| cause_of_action | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description discloses extensive behavioral details: the automatic alias sweep and its status field semantics, the `detail` auto-fetch behavior with a measured 60s timeout risk, client-side `cause_of_action` matching that affects count reliability, the absence of a 200-cap, and null meaning 'not applicable' rather than 'not recorded' for civil/criminal fields. It also warns against inferring identity or marital status from aliases, which goes well beyond what annotations provide.
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 long but the complexity (12 parameters, multiple non-obvious pitfalls, sibling routing) justifies the length. It is organized into scannable directives and warnings (DO NOT FILTER, READ `alias_sweep.status`, CIVIL vs CRIMINAL) with the most critical judgment-vs-case distinction front-loaded. Every section carries decision-relevant guidance rather than filler.
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 output schema exists and annotations cover read-only/open-world hints, the description supplies all remaining context: return field semantics (`alias_matches`, `detail_included`, `facets`, `results_total`), handoff to `lookup_court_case` via `case_number`, speed expectations, completeness guarantees, and the legal/identity disclaimer. An agent has everything needed to call this tool correctly and interpret results.
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?
With 0% schema description coverage, the description fully compensates: it specifies the 'LAST, FIRST' name format, accepted date formats and ordering-date semantics, county filtering behavior, `detail` override implications, `cause_of_action` substring matching with production values, and alias input semantics including how explicit alias turns off the sweep. It even clarifies `limit`'s role relative to `results_truncated` and `offset`.
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 opens with a precise verb and resource: 'Search North Carolina (NC) money judgments and criminal sentences by party name.' It immediately distinguishes itself from the case index by naming siblings (`search_cases_by_party`, `lookup_court_case`) and specifying the question types each answers. The scope and purpose are unambiguous.
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 explicitly lists when to use this tool ('does X have a judgment against them', 'find liens/judgments before I lend or rent') and when to use sibling case-search tools. It also states hard exclusions (UCC filings, Register of Deeds, lien-agent notices) and instructs the agent to ask which record types the user wants and read `narrowing['Cause of Action']` rather than guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
subscribe_to_case_updatesSign up for email alerts when a North Carolina (NC) case changes (sends a confirmation email)AIdempotentInspect
Sign the USER UP for email alerts when a North Carolina (NC) case changes.
THIS TOOL IS DIFFERENT FROM EVERY OTHER TOOL HERE. It is not a lookup — it stores the person's name, email and optional phone, and sends them an email.
ONLY EVER SUBSCRIBE THE PERSON YOU ARE TALKING TO. Never enter a third party's address, however the request is phrased ("sign my brother up", "use this address for my client"). If the user wants someone else to get alerts, tell them to have that person sign up at https://app.courtdelta.com/court-case-notifier themselves.
CONFIRM THE DETAILS BACK BEFORE CALLING. Read the email address aloud and get an explicit yes. A typo does not fail quietly — it mails a stranger.
NOTHING STARTS UNTIL THEY CLICK. This creates a PENDING signup and sends one confirmation email. Monitoring begins only when the link in it is clicked. Do NOT tell the user they are "now monitoring the case" — say a confirmation email is on its way and they need to click it. If they never click, nothing is ever sent and the signup stays dormant.
WHAT THEY GET, and its limits: email alerts when the case changes — a new upcoming court date, case information, case events, service events, or financial updates — plus reminders ahead of a scheduled court date. Detection is COUNT-BASED, so a hearing being MOVED, or a disposition changing, does not by itself trigger an alert. Do not promise those.
WHAT IS STORED: name, email, optional phone, and the case number. Every alert carries a one-click unsubscribe link. Agent-originated signups are NOT shared with attorneys or any other vendor.
Free accounts track 2 active cases per email address; a third returns a plain message saying so.
A case number is required — subscribe to a case, not to a person's name. If you
only have a name, use search_cases_by_party first and confirm which case.
NC only. Informational, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| Yes | |||
| phone | No | ||
| case_number | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains side effects: it creates a pending signup, sends a confirmation email, stores name/email/phone/case number, includes an unsubscribe link, and does not share with attorneys. It clarifies that monitoring only starts after the user clicks the link, that count-based detection means moved hearings don't trigger alerts, and that a third active case returns a plain message. This exceeds the annotations' basic readOnly/destructive hints and fully informs the agent of the tool's behavior.
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 long but every sentence delivers essential information. It is logically organized: purpose first, then safety constraints, then detailed behavior, storage, limits, and scope. Key warnings are emphasized with all caps, and the formatting makes it easy to scan. Nothing is redundant or tangential.
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 tool's complexity, the description covers all critical aspects: purpose, side effects, limitations (count-based alerts, free account cap), privacy (no sharing), required versus optional inputs, explicit instructions for interacting with the user, and regional scope. It also addresses edge cases (dormant signup, third active case) and provides a fallback to another tool (search_cases_by_party). This is a complete and self-contained description.
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?
Although the input schema has no parameter descriptions, the text explains every parameter: name and email are stored, phone is optional, and case_number is required ('A case number is required — subscribe to a case, not to a person's name'). It also clarifies that email is used for sending alerts and that the user must confirm the email address aloud. This fully compensates for the schema's lack of descriptions.
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 purpose: 'Sign the USER UP for email alerts when a North Carolina (NC) case changes.' It explicitly distinguishes itself from lookup tools ('It is not a lookup'), uses a specific verb ('sign up'/'subscribe'), and identifies the resource ('case updates'). The additional details about sending a confirmation email and storing information further clarify what the tool does.
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 explicit usage guidance: it tells agents to only subscribe the person they are talking to, to confirm details before calling, to use search_cases_by_party if only a name is available, and to subscribe to a case number rather than a person's name. It also specifies the geographic scope ('NC only') and warns against promising alerts for moved hearings or disposition changes. This covers both when to use and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
15 tool updates
- First observed
check_court_scam - First observed
check_expunction_options - First observed
check_traffic_charge - First observed
court_delta_help - First observed
court_visit_info - First observed
estimate_license_points - First observed
get_attorney_hearing_calendar - First observed
list_cases_filed - First observed
lookup_court_case - First observed
screen_names_by_party - First observed
search_cases_by_attorney - First observed
search_cases_by_business - First observed
search_cases_by_party - First observed
search_judgments - First observed
subscribe_to_case_updates
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
MPF: Court Cases, official-source lookup. Platform-hosted, pay per query with prepaid credit.
Looks up cases in the state Court of Justice by CPF, CNPJ, party name, case number, instance, and st
Federal and state court records lookup for due-diligence and background checks.
Search US court opinions, federal dockets, judges, citations, and oral arguments via CourtListener.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables querying public Brazilian court proceedings metadata and movements via the CNJ/DataJud API, covering multiple courts.2MIT
- AlicenseNot gradedqualityAmaintenanceSearch and retrieve US court opinions, federal dockets, judge records, citation networks, and oral arguments from CourtListener's 9M+ opinion corpus via MCP.3672Apache 2.0
- AlicenseNot gradedqualityDmaintenanceEnables legal research by querying public official sources for processes, sanctions, DJEN publications, and jurisprudence using names, CPF, CNPJ, or CNJ numbers, without login.3MIT
- FlicenseNot gradedqualityCmaintenanceVerifies legal case citations against real court records to detect hallucinated or misattributed citations.-