Skip to main content
Glama

NC General Statutes

Search North Carolina (NC) statutes by topic or keyword

search_statutes
Read-onlyIdempotent

Search North Carolina (NC) statutes by topic, keyword or phrase.

Use this when you know the SUBJECT but not the citation — "what's the NC law about leaving a dog in a hot car", "failure to appear penalty", "when can I expunge a misdemeanor". If you already have a citation, use get_statute instead.

Returns ranked sections with highlighted fragments showing why each matched, not full text: pick the one you want and call get_statute for it.

Supports quoted "exact phrases", -excluded terms and or. match_mode says how the query was read: "all_terms" (every word), "any_of" (the query used or), "any_terms" (nothing matched every word, so any word was accepted) or "citation" (the query was a bare citation, so it was looked up directly; when the section doesn't exist, the nearest real sections by number come back as suggestions). The loose modes only return sections that contain at least one of your words. Results are ordered by terms_matched — how many of the search words a section contains, a quoted phrase counting only when it appears as a phrase — then by rank. Court shorthand is expanded automatically and case-insensitively — FTA, DWLR, PJC, AWDW and similar become the statutory wording, because the statute book spells the phrase out and never uses the abbreviation. The expansion is reported back as expanded_query.

Searches the law in force today, at section level. A low top rank means the corpus probably has no section on point — NC simply has no statute on some subjects, and saying so is a better answer than the nearest loose word match.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYesTopic, keyword or phrase. Supports quoted "exact phrases", -excluded terms and `or`. Court shorthand (FTA, DWLR, PJC) is expanded for you.
chapterNo
include_repealedNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/closed-world, and the description adds substantial non-obvious behavior: match_mode semantics with all four values explained, automatic court-shorthand expansion reported as expanded_query, terms_matched ranking order, nearest-number suggestions for bare citations, and the interpretive rule that a low top rank means no on-point statute. This is exactly the extra context the annotation bar invites.

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: purpose, routing rule, and return-shape caveat come first, then query syntax and match_mode details. Every sentence carries operational information (expansion, ranking, suggestions), though the match_mode enumeration and ranking explanation could be tightened.

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?

An output schema exists, so return values need not be enumerated, yet the description still clarifies the shape that matters (ranked fragments with highlights, not full text) and the fields an agent must react to (match_mode, expanded_query, suggestions). For a 4-param search tool this leaves no material gap.

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 coverage is only 25%, so the description must carry the load, and it does for the dominant parameter: query syntax (quoted phrases, -exclusions, `or`), shorthand expansion and how the query is interpreted. However, limit, chapter and include_repealed are never addressed; 'the law in force today' only implicitly signals include_repealed=false, and chapter scoping is unmentioned.

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?

States a specific verb and resource ('Search North Carolina (NC) statutes') plus scope ('by topic, keyword or phrase') and instantly separates itself from get_statute by citation-vs-subject framing. An agent can distinguish it from every sibling without reading schemas.

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 ('when you know the SUBJECT but not the citation') with concrete example queries, and an explicit when-not with the named alternative ('If you already have a citation, use get_statute instead'). It also tells the agent what to do next after a hit (pick one, call get_statute).

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.

Directories

Resources