Skip to main content
Glama

GLO Law

Keyword search over statute text

statute_search
Read-onlyIdempotent

Keyword (BM25) search over the body text of statute sections and, in the default source, Kansas administrative regulations, in the same snapshot as the statute tool; source= searches one regulation source alone. Without jurisdiction=, results mix states: on 6,852 benchmark housing-law questions run unconfined, the top-ranked section came from a state other than the asker’s in 97.7% of them. Each row carries its jurisdiction, corpus and as_of; statute and regulation rows can appear together. Rank is textual match strength only. Keyword, not concept, with no stemming: very common words are dropped, duplicates collapse, at most 40 words run, matched any-of, so a top hit may share one word with the query; terms_searched and terms_dropped report what ran, and "double quotes" require a phrase. Only the body is searched, not the heading. Scores drift in their last digits between restarts, so close rows can swap places. Returns metadata, a snippet with [hl]...[/hl] marks and a rank; the statute tool returns the full section. A section not returned is a miss, not an absence. ends_at_colon is flagged as in the statute tool. A missing keyword index returns a visible 503, not zero matches. Every response, including 400 and 503, carries "note" and "coverage_note". The sources tool returns this tool’s full coverage statement and, per source code, its coverage and counts.

Input Schema

NameRequiredDescriptionDefault
qYeswords to match in the statute section text. A full natural-language question is fine: common words are dropped and the rest matched ANY-OF, so more words widen the search rather than narrowing it. "double quotes" for a phrase that must appear together
limitNomax results, default 20, capped at 50
titleNoonly with source=: narrows the search to one title, part or chapter of that source; the forms per source are given by sources(tool="statute_search", source=<code>)
sourceNoomit for statutes and Kansas regulations; a regulation source code ("cfr" for federal, or a state code) searches that source alone; each code’s coverage is given by sources(tool="statute_search", source=<code>)
jurisdictionNorestrict to one jurisdiction, e.g. "ks" or "us". STRONGLY preferred when the user’s state is known: without it results mix states

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?

Beyond the read-only and idempotent annotations, it discloses ranking limitations, token handling, body-only matching, score instability, non-exhaustiveness, highlighting, and error behavior. The mixed-jurisdiction warning and distinction between a visible 503 and zero matches are especially valuable for correct interpretation.

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?

The purpose and jurisdiction risk are front-loaded, and nearly every subsequent sentence supplies actionable behavioral or output-interpretation information. However, it is a dense single paragraph, repeats some schema guidance, and uses more space than necessary on precise benchmark figures.

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?

With no output schema, the description still covers row metadata, snippets and highlight markers, rank, search-term diagnostics, ends_at_colon, response notes, and 400/503 behavior, while delegating full coverage details to sources. Together with the complete parameter schema and safety annotations, this gives an agent enough information to invoke the tool and interpret its results correctly.

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?

Although schema coverage is 100%, the description adds operational detail such as no stemming, duplicate collapse, the 40-word execution cap, body-only matching, and the practical risk of omitting jurisdiction. Some q and source guidance repeats the schema, and the description adds little beyond it for limit or title.

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 opening identifies the method (BM25 keyword search), resource (statute-section body text and, by default, Kansas administrative regulations), and scope. It also distinguishes the tool from statute, which returns full sections, while "Keyword, not concept" separates it from conceptual retrieval.

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?

It gives actionable selection guidance: use source to isolate one regulation source, constrain jurisdiction to avoid mixed-state results, use statute for full text, and use sources for coverage details. "Keyword, not concept" and "A section not returned is a miss, not an absence" also clarify when the tool and its results should not be relied upon.

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