Skip to main content
Glama

Syfert Legal Research

by com.syfert
OverviewDiscussionsAdmin

Read a statute or rule

get_statute
Read-onlyIdempotent

Fetch the full text of a statute, rule, or code section: the current codification in the edition this corpus holds. Every answer carries currency (edition, current_through, current_through_basis, last_verified, text_last_changed = when our copy last changed, last_amended_year, effective_date, history_note, status, successor, versions_available) and temporal_note. OPERATIVE DATE: statute text is the edition this corpus holds, not the law on every date. For a crime, a contract, a limitations period or a procedural step, establish the operative date first (offense, contract, accrual or filing date) and pass it as as_of (YYYY-MM-DD); say so when the text postdates the facts, since an older offense may be charged under a predecessor section. With as_of, a section amended or enacted after that date returns temporal_warning FIRST, with the history note and, where this corpus kept it, the prior text (prior_text_available; most corpora keep none). A repealed or renumbered section returns status_warning with its successor. currency.status is current | sunset (operative until currency.sunset_date; successor names the version that takes over) | future (not yet operative; effective_date is when it starts) | expired | repealed | renumbered, and anything but current leads with status_warning. Where the later version is held (California sections with more than one version), as_of on or after its operative date returns that text in as_of_version. A U.S. Code section can also be omitted (dropped from the Code by the Office of the Law Revision Counsel and no longer printed; not a repeal): it leads with status_warning too, and the history note says why. A CFR section removed from the eCFR is status removed: status_warning REMOVED names the removal's effective date (currency.sunset_date) and the eCFR point-in-time link for the text in force before it. A former U.S. Code appendix section (usc, "50 U.S.C. App. § 462") returns status former_appendix with the current section(s) in former_appendix, not text.

Input Schema

NameRequiredDescriptionDefault
as_ofNoOptional operative date, YYYY-MM-DD (offense, contract, accrual or filing date). When the section was amended or enacted after it, the answer leads with temporal_warning (severity amended_after | enacted_after | text_older_than_as_of | unknown_history), the history note and, when this corpus kept it, the prior text (prior_text_available); otherwise as_of_check says no later change is recorded. On or after a held successor version's operative date, as_of_version carries that version's text.
offsetNoCharacter offset for paging long sections
citationYesSection as commonly cited: "83.49", "16-5-1", "174.02". Multi-code states (TX/CA/NY) need the code name too: "Tex. Penal Code 22.01".
max_charsNoMax characters of body text (default 40000)
jurisdictionYesWhich corpus: any two-letter state code (all 50 states + dc), or fl_statute (Fla. Stat.), fl_rule (FL court rules), fac (Florida Administrative Code, "6A-6.03019"), ga (O.C.G.A.), usc, cfr, fedrule, sg (sentencing guidelines). A state's COURT RULES live in the SAME corpus as its statutes — pass the state code and cite the rule as lawyers there do: "TRCP 166a" (tx), "MCR 2.116"/"MRE 403" (mi), "C.R.C.P. 56" (co), "CR 56"/"RAP 2.5" (wa), "Ohio Civ. R. 56" (oh), "Pa.R.C.P. 1035.2" (pa), "R. 4:46-2"/"N.J.R.E. 403" (nj), "Md. Rule 2-501" (md), "I.R.C.P. 56" (id), "Conn. Practice Book § 23-8" (ct), "N.C. R. App. P. 10" (nc), "Cal. R. Ct. 8.204" (ca), "22 NYCRR 1250.1" (ny), "Tenn. R. Civ. P. 56" (tn), "Ga. Sup. Ct. R. 41" (ga). Rules are in-corpus for all 44 of: ak al ar az ca co ct dc de fl ga hi ia id il in ky ma md me mi mn mo ms mt nc nd ne nj nm nv ny oh or pa ri sc tn tx ut va wa wi wv wy. ks la nh ok sd vt keep no separate rules set — theirs are codified AS statutes ("S.D. Codified Laws § 15-6-10(a)", "K.S.A. 60-256"), and so are the Hawaii evidence rules ("Haw. Rev. Stat. § 626-1, Rule 403").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / as_of / description
      Previous value: -"Optional operative date, YYYY-MM-DD (offense, contract, accrual or filing date). When the section was amended or enacted after it, the answer leads with temporal_warning (severity amended_after | enacted_after | text_older_than_as_of | unknown_history), the history note and, when this corpus kept it, the prior text (prior_text_available); otherwise as_of_check says no later change is recorded."New value: +"Optional operative date, YYYY-MM-DD (offense, contract, accrual or filing date). When the section was amended or enacted after it, the answer leads with temporal_warning (severity amended_after | enacted_after | text_older_than_as_of | unknown_history), the history note and, when this corpus kept it, the prior text (prior_text_available); otherwise as_of_check says no later change is recorded. On or after a held successor version's operative date, as_of_version carries that version's text."
  2. Changed1 schema field changed
    • addedInput schema / properties / as_of
      Added value: +{
+  "description": "Optional operative date, YYYY-MM-DD (offense, contract, accrual or filing date). When the section was amended or enacted after it, the answer leads with temporal_warning (severity amended_after | enacted_after | text_older_than_as_of | unknown_history), the history note and, when this corpus kept it, the prior text (prior_text_available); otherwise as_of_check says no later change is recorded.",
+  "type": "string"
+}
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: exactly which fields every answer carries, that temporal_warning or status_warning leads the response, and the full status taxonomy (current | sunset | future | expired | repealed | renumbered, plus omitted/removed/former_appendix cases) with what each returns. This is unusually rich disclosure of return-time behavior for a read tool.

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

Conciseness3/5

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

Information-dense and front-loaded with purpose, currency fields, then operative-date handling, but it is one long undelimited block and the tail (omitted U.S. Code sections, CFR removals, former appendix handling) is verbose relative to what an agent needs to select and call the tool. Much earns its place, but structure and length 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?

With no output schema, the description carries the burden of explaining return values, and it does so thoroughly (currency field list, temporal_warning/status_warning precedence, successor/prior text availability). For a temporally complex corpus this is complete enough for an agent to interpret results correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all five parameters in depth, including as_of semantics, citation formats, and jurisdiction corpora. The description restates and emphasizes as_of usage but adds little syntax or format detail the schema does not already supply, so the baseline 3 applies.

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?

Opens with a specific verb+resource: 'Fetch the full text of a statute, rule, or code section,' and names the scope ('the current codification in the edition this corpus holds'). This cleanly separates it from siblings like search_statutes (discovery) and get_case (case law) without needing to open any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives strong conditional usage guidance: for a crime, contract, limitations period or procedural step, establish the operative date first and pass it as as_of, and say so when the text postdates the facts. It explains the consequences of passing as_of vs not. It stops short of routing among siblings (e.g., no pointer to search_statutes for finding a citation first), so it is clear context rather than full when/when-not/alternatives.

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

All Syfert Legal Research toolsInspect
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