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 range file_date_start/file_date_end (ISO YYYY-MM-DD or MM/DD/YYYY — both accepted), and a more specific name.

• soundex: true is 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") and case_type (pick a value from the narrowing.caseTypes facet).

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_truncated true = the portal hit its statewide 200-case cap, so the set is INCOMPLETE (real matches are missing). See portal_truncated_note; when true, narrowing gives counties only (counts are lower bounds). Clear it with case_status / date range / a more specific name.

• results_truncated true = the (complete) set exceeded limit, so not all rows are shown. Pass a higher limit (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_truncated true): 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 or case_status) — or, if autonomous with no user to ask, re-call confirm_broad=true to proceed as-is.

• COMPLETE but long (a large set with portal_truncated false): 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.