NC General Statutes

Read a North Carolina (NC) General Statutes section

get_statute

Read-onlyIdempotent

Full text of one North Carolina (NC) General Statutes section, by citation.

Use for "what does G.S. 14-72.1 say". Accepts any spelling — "14-72.1", "G.S. 14-72.1", "§ 14-72.1". Returns catchline, body, history note, and when it was first enacted and last amended. as_of gives the text observed on a past date; pending lists variants enacted but not yet effective.

Carries codified_through, session_laws_through and a legislation_note naming any enacted act that touches this section outside the codified text. An uncodified override ("Notwithstanding G.S. ...") is never codified, so it is reported regardless of the watermark. PENDING BILLS ARE NOT COVERED — a ratified bill is not law and appears in neither source, so an empty note is not evidence nothing passed.

as_of RESOLVES AGAINST OBSERVED VERSIONS, NOT EFFECTIVE DATES — it answers "what did this database hold on that date", so it cannot reach text from before the first ingest run. For "what took effect on 1 October" use recent_law_changes(source="effective").

Section-level only — ask for "20-141", not "20-141(j1)". The Rules of Evidence and of Civil Procedure are each one statute (G.S. 8C-1, G.S. 1A-1) holding many rules; ask for a rule as "8C-1, Rule 104" or "1A-1, Rule 12" (N.C. R. Evid. / N.C. R. Civ. P. forms work). Asking for 8C-1 or 1A-1 itself lists the rules. For WHEN it changed use amendment_history; for WHAT changed use diff_statute.

Input Schema

Name	Required	Description
`as_of`	No
`pending`	No
`citation`	Yes	One NC General Statutes SECTION, or one rule of the Rules of Evidence or Civil Procedure ("8C-1, Rule 104", "N.C. R. Civ. P. 12"). Any spelling works; subsections do not — ask for 20-141, not 20-141(j1), and 1A-1, Rule 12, not Rule 12(b)(6).
`max_chars`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 16, 2026

changedInput schema / properties / citation / description

Previous value: -"One NC General Statutes SECTION. Any spelling works; subsections do not — ask for 20-141, not 20-141(j1)."New value: +"One NC General Statutes SECTION, or one rule of the Rules of Evidence or Civil Procedure (\"8C-1, Rule 104\", \"N.C. R. Civ. P. 12\"). Any spelling works; subsections do not — ask for 20-141, not 20-141(j1), and 1A-1, Rule 12, not Rule 12(b)(6)."

changedInput schema / properties / citation / examples

Previous value: -[
-  "14-72.1",
-  "G.S. 14-72.1",
-  "§ 14-72.1",
-  "15A-145.5"
-]New value: +[
+  "14-72.1",
+  "G.S. 14-72.1",
+  "§ 14-72.1",
+  "15A-145.5",
+  "8C-1, Rule 104"
+]

First observedOct 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already establish the safe-read profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavioral context beyond them: what as_of actually resolves against, the observed-version watermark vs effective dates, how uncodified overrides are reported, and the limit that pending ratified bills appear in neither source.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Long, but front-loaded with purpose and scoping on the first line and structured into constraint-bearing paragraphs. Nearly every sentence carries a distinct, actionable warning; a small amount of repetition (as_of semantics restated) keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a citation-lookup tool with an output schema present, the description covers everything an agent needs: accepted citation spellings, section-level granularity, the Rule-as-statute special cases, and the watermark caveats. Return fields are enumerated helpfully rather than redundantly.

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

Parameters4/5

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

Schema description coverage is low (25%), so the description must compensate, and it does for as_of ("text observed on a past date", resolving against observed versions not effective dates) and pending ("variants enacted but not yet effective"). max_chars remains unexplained in both the description and schema, leaving one parameter undocumented.

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 gives a specific verb+resource ("Full text of one North Carolina (NC) General Statutes section, by citation") and immediately distinguishes itself from siblings by naming amendment_history, diff_statute, recent_law_changes, and search_statutes for their respective jobs. An agent can route correctly without opening another schema.

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?

Explicit when-to-use ("what does G.S. 14-72.1 say"), when-to-use-alternatives ("For WHEN it changed use amendment_history; for WHAT changed use diff_statute"), and a redirect for effective-date questions ("use recent_law_changes(source=\"effective\")"). It also names exclusions (PENDING BILLS ARE NOT COVERED).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All NC General Statutes tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?