Skip to main content
Glama

Court Delta

Search North Carolina (NC) money judgments and criminal sentences (incl. aliases)

search_judgments
Read-only

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. Unlike search_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 in facets with live counts, so read facets rather 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNorelevance
aliasNo
limitNo
partyNo
countyNo
detailNo
to_dateNo
from_dateNo
case_numberNo
judgment_typeNo
sentence_typeNo
cause_of_actionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. First observed

TDQS

A5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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

With 0% schema description coverage, the description fully compensates: 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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources