Verify legal citations, case treatment, quotes and whole briefs against 10.7M U.S. opinions
Scored across 18 tools
Most tools map to a distinct resource+action (get_case, search_statutes, verify_quote, get_treatment), and the descriptions include explicit routing rules ('proposition -> find_authority; doctrine -> find_issues; party name -> search_cases'). However, search_quotes is openly 'Same tool as find_authority' and find_case is a strict subset of search_cases, so two pairs are functionally duplicative and an agent must rely on the prose to pick correctly.
All 18 tools follow a strict snake_case verb_noun pattern: find_*/get_*/search_*/check_*/verify_*/suggest_*/export_* with a clear object noun (case, statute, treatment, quote, brief, citation). No camelCase or stylistic mixing anywhere.
18 tools is slightly above the ideal 3-15 band but each one covers a real, non-trivial operation in legal research (citation audit, citator, treatment flags, quote verification, statute currency, document export). The surface is broad but not padded, so it earns most of its size.
The set covers the full research-and-verify lifecycle: discovery (search_cases, search_statutes, find_issues, find_authority), retrieval (get_case, get_statute, export_document), citator/validity (get_treatment, get_citing_cases, get_propositions, find_related_cases), verification (check_citation, verify_quote, check_brief), support (find_court) and feedback (suggest_treatment). No obvious dead ends for the stated legal-research purpose.
Audit ALL citations in a draft brief, motion, or memo at once (wraps syfert.com Brief Check). Extracts every reporter citation, verifies each exists, checks the case name the document claims against the real case (hallucination detection), checks each quoted passage word for word against the cited opinion's own text (misquote = not in that opinion; unquoted_by_courts = the text could not be compared and no court has quoted those words from the case: check it with verify_quote), traces an unmatched quote to the case the language actually ORIGINATES in (quote_origin: attribute with "(quoting …)" or cite the source), and returns treatment flags with replacement suggestions for red-flagged authority. Also audits every STATUTE, REGULATION and COURT-RULE citation in the document against the corpus that holds it, reported separately under "statutes" (verified=false means not found in that corpus, which is not proof the section is wrong). ALWAYS run this on a finished draft before delivering it. Use mode=attack on an OPPONENT's brief to get ammunition: distinguishing and criticizing citers for each of their cites. Text over the size cap (128KB anonymous, 512KB with a token) is cut before the audit and the response then carries stats.truncated_bytes plus an INCOMPLETE AUDIT warning. corrections lists every quote the cited opinion does not carry verbatim, with replace_with (the opinion's own words, or, for verdict statute_text / statute_misquote / rule_text, the statute's or rule's own words) and star_page, and every unresolved or name-mismatched citation. Each unresolved citation carries verdict (exists_unindexed = a real case our index lacks, confirmed by a citing opinion or by name -- keep it; not_indexed = unknown, weigh volume_coverage (thin 2019+ volumes make a miss weak evidence); interior_mismatch/strong = likely fabricated), so do not report every unresolved cite as a hallucination (MCP13_20260925). A pinpoint page written as a citation of its own is status pin_reference (stats.pin_references, not unresolved) and its correction gives cite_as (first page, then pin). Public-domain cites ("2023 IL App (1st) 220520", "2023-Ohio-1234") are read like reporter cites, and a paragraph pinpoint ("¶ 45", "¶¶ 12-14") is checked against the opinion's paragraph numbers: cites[].para_pin.verdict interior_pin / interior_mismatch, quote_checks[].para_pin.inside says whether a quotation sits in the pinned paragraph; a mismatch is also a correction (MCP17_20260925). Each verified statute finding carries currency (edition, current-through, last amendment where recorded) and statutes.corpus_currency the edition of each corpus: a brief about past conduct needs the text in force on the operative date (check_citation or get_statute with as_of). Pass forum (the court you will file in, e.g. forum="ca9" or forum="fl") to have each unpublished cited case checked against the citation rules of that court: cites[].citability.forum.may_cite is yes / persuasive / conditional / no, or unsure when our verified rules data cannot settle it for that court (it says why: another court system, a district court applying a circuit rule, a pre-2007 federal disposition in another circuit, or a rule that is an open question on the citability review page). An unresolved citation printed in the corpus only by opinions that say it does not exist (sanctions / show-cause orders on fabricated citations) is verdict strong, verdict_evidence cited_as_fabricated, with fabricated_citers.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | defend (default): audit your own draft. attack: treat the text as the opponent's brief and return ammunition against their cites. | |
| text | Yes | The full document text (up to 512KB) | |
| forum | No | Optional. The court the document will be filed in: a court id (fla, ca9, texapp, flsd, scotus) or a two-letter state code / state name (fl, TX, New York). Unpublished cited cases are then checked against the citation rules that apply in THAT court (cites[].citability.forum); without it the issuing court's own rule is reported. | |
| max_cites | No | Max citations to process (default 100, max 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the description doesn't need to restate safety. It adds rich behavioral context beyond annotations: hallucination detection, treatment flags, statute/regulation/rule auditing (separate output under 'statutes'), truncation behavior with stats.truncated_bytes and INCOMPLETE AUDIT warning, verdict taxonomy (exists_unindexed, not_indexed, interior_mismatch/strong), pinpoint handling, quote_origin tracing, fabricated_citers, and citability via forum. However, it's somewhat sprawling and could be better organized; it doesn't contradict annotations. A 4 reflects strong but not perfectly structured transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and an ALWAYS instruction, but the single paragraph is extremely long (over 400 words) with many parenthetical asides and internal codes (MCP13_20260925, MCP17_20260925) that clutter. It's information-dense but lacks structure (bullet points, paragraph breaks), making it harder to scan. It's appropriately sized for a complex tool but not optimally organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—multi-faceted citation audit with hallucination, quote, statute, pin, treatment, and citability checking—the description covers all major behaviors, output structures (cites[], quote_checks[], statutes, corrections), edge cases (truncation, public-domain cites, paragraph pinpoints), and integration points (forum, check_citation, get_statute). No output schema exists, and the description still adequately explains return structure. Nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters including mode enum and forum examples. The description elaborates on mode=attack and forum's effect (cites[].citability.forum), adding practical meaning, but doesn't go beyond the schema for text or max_cites beyond what the schema states. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear specific verb+resource+scope: 'Audit ALL citations in a draft brief, motion, or memo at once.' It distinguishes itself from check_citation by emphasizing the entire document at once and wrapping syfert.com Brief Check, and from verify_quote by handling all citations rather than one. However, it doesn't explicitly contrast with check_citation beyond being batch-oriented, so it falls short of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: 'ALWAYS run this on a finished draft before delivering it.' Explicit alternative usage: 'Use mode=attack on an OPPONENT's brief to get ammunition.' It also routes the agent to verify_quote for unquoted_by_courts and mentions check_citation or get_statute with as_of for currency. Clear context and exclusions are both present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a legal citation actually exists before using it. CASES: returns the real case at that citation, its treatment flag, and (if expected_case_name given) whether the name matches. This catches hallucinated or miscopied citations. A reporter cite that is not indexed comes back with a verdict, and the verdict is what to act on (MCP13_20260925): exists_unindexed = the case is REAL (a court in the corpus prints this exact citation, see cited_by_corpus, or the case is found by name and year, see name_candidates) and only our reporter index lacks it -- never call it a hallucination; not_indexed = no evidence either way, read volume_coverage: for 2019+ volumes of the state regional reporters we often index under 30% of the cases (coverage_pct), so a miss there is weak evidence; interior_mismatch / strong = the page provably sits inside a differently named case, or the volume is complete and nothing turns up by name -- treat as likely fabricated; name_mismatch = opinions in the corpus print this citation for a DIFFERENTLY named case (cited_by_corpus.examples[].printed_as): the cite is real but not the case you named -- fix the name or the cite. Local misses are also re-checked LIVE against CourtListener. STATUTES, REGULATIONS AND COURT RULES: a citation that is not a reporter cite is checked against the corpus that holds it (50 states + DC, 44 states' court rules, the Florida Administrative Code, USC/CFR/federal rules/USSG) and comes back with type, verified, the canonical citation, title, url and link_md; verified=false carries nearby sections and a coverage note, and is NEVER proof the section does not exist. ALWAYS use this to verify any citation that will appear in a legal document. With quote, the quoted words are checked against the opinion the cite resolves to (quote_check, the verify_quote block). PROPOSITION-LEVEL TREATMENT (MCP14_20260925): pass proposition (what you cite the case for; quote is used when proposition is absent) and treatment.proposition names the one proposition citing courts cite it for that matches, with its OWN flag, and treatment.proposition_note says when that point is flagged although the case is green (or unflagged although the case is red); "no proposition-level signal for this use" means only the case-level flag applies. PUBLIC-DOMAIN CITES AND ¶ PINPOINTS (MCP17_20260925): vendor-neutral cites are read as the courts print them ("2023 IL App (1st) 220520", "2023-Ohio-1234", "2022-NMCA-063", "2021 IL App (1st) 200563-U", "2019 S.D. 9"); a paragraph pinpoint ("¶ 45", "¶¶ 12-14", "at ¶ 7") on a resolved cite is checked against the opinion's own paragraph numbers: paragraph_pin.verdict interior_pin = that paragraph exists (paragraph_text shows it), interior_mismatch = past the last numbered paragraph, a number the opinion skips, or (with quote) the quotation sits in another paragraph (found_at, suggested); null = the text carries no paragraph numbers, not checked. The top-level verdict stays found. A verified statute, regulation or rule also returns currency + temporal_note (the edition held, current-through, last amendment where recorded); with as_of, temporal_warning comes first when the section changed after that date. 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. A statute whose status is sunset, future, expired or repealed leads with status_warning (sunset_date, successor). So does a U.S. Code section omitted from the Code (status omitted). A citing opinion that says the cited case does not exist (a sanctions or show-cause order about fabricated citations, Mata v. Avianca) is never counted as evidence: such citers are listed in fabricated_citers, and when they are the only ones the verdict is strong with verdict_evidence cited_as_fabricated (likely fabricated). Clusters that look like one decision filed twice but share no docket number are listed as twin_candidates (not folded). A CFR section removed from the eCFR is status removed (status_warning REMOVED, currency.sunset_date = the removal's effective date).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | 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. | |
| quote | No | Optional: words you quote from this case; returns quote_check (verbatim | near | absent, best_match, star_page) | |
| state | No | Optional two-letter state code, used only for statute/rule cites: settles a form two states both recognise, and resolves forms the corpus registry cannot classify. Ignored for case citations | |
| citation | Yes | The citation, e.g. "819 So. 2d 732", "Siegle v. Progressive, 819 So. 2d 732 (Fla. 2002)", "Fla. Stat. § 83.49", "Fla. R. Civ. P. 1.510", "42 U.S.C. § 1983", "N.C. R. App. P. 10" | |
| proposition | No | Optional: the point you cite this case for (a sentence of your draft or a paraphrase); returns treatment.proposition and treatment.proposition_note, the treatment of that proposition | |
| expected_case_name | No | Case name the citation is claimed to belong to, for mismatch detection. Also lets a citation newer than the reporter index resolve by name + decision date: same-name cases in the window come back as name_candidates |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnly/idempotent annotations: it enumerates verdict semantics (exists_unindexed, not_indexed, interior_mismatch, name_mismatch), warns that coverage can be under 30% for 2019+ regional reporters so misses are weak evidence, discloses a live CourtListener re-check, and notes that fabricated_citers never count as evidence. This is exactly the kind of behavioral disclosure annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, but the body is an extremely long, densely parenthesized block with internal MCP ID tags and all-caps section headers. It is organized but not economical; several sentences could be tightened without losing signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity verification tool with no output schema, the description covers case cites, statute/rule cites, temporal/operative-date behavior, proposition-level treatment, paragraph pinpoints, and fabricated-citer handling — an agent has enough to call it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the description adds genuine interpretive value: it explains when to pass proposition vs. quote, that as_of establishes the operative date for crimes/contracts/limitations, and that expected_case_name drives mismatch detection and name-based resolution. Only the 'state' parameter's role is left largely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Verify a legal citation actually exists') and immediately scopes what it returns for cases (real case, treatment flag, name match). An agent can distinguish this from siblings like find_case, get_case, or verify_quote because the tool's role as a pre-citation-check is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear directive — 'ALWAYS use this to verify any citation that will appear in a legal document' — and separates case-cite handling from statute/regulation/rule handling. It stops short of naming which sibling to use instead for retrieval vs. verification, so it is strong context without explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Optional. If your client can save files locally and you want a readable copy of a case or statute, this returns the complete document to save; otherwise use get_case / get_statute as before. The document is the syfert.com page as the website renders it (caption, headings, footnotes, star-page markers such as [*551], links to the cited cases): Markdown with YAML front matter (default) or one self-contained HTML file. Returns filename, format, bytes, document and note; the MCP cannot write to disk, so saving document under filename is up to you. A case: cluster_id, or citation (+ case_name). A statute or rule: jurisdiction + citation, as get_statute takes them. A document longer than one response comes in parts (truncated, next_offset): call again with offset and append the parts in order.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | markdown (default) or html | |
| offset | No | Byte offset of the next part (next_offset from the previous call) for a long document | |
| include | No | Sections. Cases: text (the opinion), treatment (flag and strongest signal), propositions (what courts cite it for), cited_by_top (leading citing cases with their parentheticals), scope (how far a red or yellow flag reaches). Statutes: text, cited_by_top (Notes of Decisions), scope (source and scrape date). Default ["text","treatment","scope"]. | |
| citation | No | A case's reporter citation ("875 F.2d 994"; used if cluster_id is absent), or, with jurisdiction, the section or rule ("90.803", "Nev. J. Ct. R. Civ. P. 70") | |
| case_name | No | Case name; lets a citation newer than the reporter index resolve by name + date | |
| cluster_id | No | Cluster id of the case | |
| jurisdiction | No | For a statute or rule: the corpus, as get_statute takes it (two-letter state code, usc, cfr, fedrule, sg, fac …) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavioral context beyond the annotations: the MCP cannot write to disk so persistence is the caller's job, and long documents are paginated via truncated/next_offset requiring ordered appending. The readOnly/idempotent/non-destructive profile is already fully covered by annotations, so no contradiction and no redundancy penalty, but permissions or rate-limit behavior is left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the key routing decision ('Optional. If your client can save files locally...') and nearly every clause carries information. It is a dense single block with several ideas packed together, which slightly hurts scannability, but there is little filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 return contract itself (filename, format, bytes, document, note) plus the pagination protocol and the no-disk-write caveat. For a 7-parameter tool with 0 required params, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3; the description goes further by explaining parameter interaction (citation used when cluster_id is absent, case_name to resolve citations newer than the reporter index, jurisdiction required for statutes/rules) and the append-in-order rule for offset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (export/save a readable copy of a case or statute) and explicitly positions itself against siblings: 'otherwise use get_case / get_statute as before'. The description also enumerates exactly what the exported artifact contains (caption, headings, footnotes, star-page markers, links).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with the selection condition ('If your client can save files locally and you want a readable copy') and the negative case ('otherwise use get_case / get_statute as before'). It also gives per-resource invocation routes (cluster_id or citation for cases; jurisdiction + citation for statutes) so the agent knows which sibling semantics to mirror.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the case to cite for a proposition. Paste the proposition or the language you need authority for VERBATIM; do not convert it to keywords. The result names the source case to cite (source_case), the verbatim passage, and how many courts have adopted it (quoted_by_cases); match_kind says how it matched: exact_phrase (the passage contains your words), relaxed (it shares your distinctive words), proposition (a rule later courts cite that case for). A miss means no court has quoted or been cited for that wording; try find_issues for the doctrine, or search_cases with 3-4 distinctive words. Routing: a proposition or quoted language -> find_authority (pasted verbatim); a doctrine name or fact pattern -> find_issues; a party name, statute number or keywords -> search_cases. Quotation marks mean pasted from a tool result (opinion text, passage, best_match). If you typed a quote from memory, run verify_quote and use best_match. Run check_brief on the finished draft and apply its corrections. Copy cite_as for the citation (first page, then pin). The first 3 rows carry star_page and cite_as.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional two-letter state code: relaxed and proposition matches are limited to that state's courts (falls back to all courts when it has none); verbatim exact-phrase matches from any court are kept, that state's first | |
| proposition | Yes | The proposition or quoted language, verbatim (three or more words; up to ~300 characters are used) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, destructive=false, openWorld=false), and the description adds genuinely non-obvious behavior: the three match_kinds and what each means, that a miss implies no court quoted that wording, the state fallback rule, and which fields the first 3 rows carry. This is rich behavioral context beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core instruction (paste verbatim), followed by routing and workflow guidance in tight sentences with no filler. It is dense and somewhat long, but nearly every sentence carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain returns, and it does: source_case, the verbatim passage, quoted_by_cases, match_kind, star_page and cite_as. Combined with the routing and downstream steps, an agent has everything needed to call and act on this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning the schema does not: paste VERBATIM rather than keywords, quotation marks signal pasted-from-tool text, and the state parameter's relaxed/proposition scoping versus kept verbatim matches.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Find the case to cite for a proposition') and immediately distinguishes itself from siblings by naming find_issues and search_cases as the alternatives for different inputs. An agent can identify this tool's niche without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing rules: proposition/quoted language -> find_authority (verbatim), doctrine name or fact pattern -> find_issues, party name/statute/keywords -> search_cases. It also states when-not (a miss means no court quoted that wording) and gives a fallback plus a downstream workflow (verify_quote, check_brief).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast direct lookup: give a citation or a case caption and get THE case (or 'not decisive' with up to 5 candidates) without a full-text search. Use search_cases for topics and words. A citation ("384 U.S. 436", "Miranda v. Arizona, 384 U.S. 436, 444 (1966)", "449 F. App'x 901", "2019-Ohio-10") resolves through the reporter index; when a case name is given (in the query or as expected_case_name) and the case at that citation carries a different name, the answer is NOT decisive (problem name_mismatch) and names the case that is really there. A caption ("Miranda v. Arizona", or one distinctive name such as "Celotex") is decisive only when the top match is at least twice as strong as the runner-up; common captions ("Smith v. Jones", "State v. Johnson") are not decisive by design. The answer carries case (bluebook, url, link_md, treatment_flag), kind (citation|caption), decisive, candidates, and a note when not decisive.
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | Optional court id filter for a caption (same syntax as search_cases court); takes precedence over state | |
| query | Yes | A citation or a case caption, e.g. "410 U.S. 113", "Roe v. Wade, 410 U.S. 113 (1973)", "Roe v. Wade", "Celotex" | |
| state | No | Optional two-letter state code (or name) narrowing a caption to that state's own courts | |
| expected_case_name | No | The case name the citation is supposed to be; the answer is not decisive when the case at the citation carries a different name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds substantial extra context: resolution through the reporter index, the name_mismatch problem when expected_case_name disagrees, the up-to-5 candidate limit, and the decisiveness heuristic. This is behavioral disclosure well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and the alternative tool, then the resolution rules. It is long and packs many clauses, but nearly every sentence encodes an invariant an agent must know; only the parenthetical example list is slightly heavy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description enumerates the answer fields (case with bluebook/url/link_md/treatment_flag, kind, decisive, candidates, note). Combined with the decisiveness rules, an agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining how citation strings resolve and what expected_case_name actually triggers (non-decisive answer with name_mismatch). Court and state precedence are already covered in the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (find/lookup) and resource (one case) with the scope 'by citation or caption', and explicitly contrasts itself with search_cases. The single-case resolution goal is unmistakable to an agent scanning siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use search_cases for topics and words instead, and lays out the conditions under which a caption lookup is decisive (top match at least twice as strong as runner-up) versus not (common captions by design). This is genuine when-to-use/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a court name to court_id values usable in the search_cases court filter. Also resolves whole GROUPS of courts (tribal courts, veterans, bankruptcy, all U.S. district courts) to the single aggregate token that filters on all of them: see court_groups in the result.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Court name or group, e.g. "Florida", "Eleventh Circuit", "Texas Supreme", "Navajo Nation", "tribal courts", "veterans", "bankruptcy" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds genuinely new behavior beyond them: that group inputs collapse to a single aggregate token and that a court_groups field appears in the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the core purpose front-loaded before the group-resolution nuance. Every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description names the key returned field (court_groups) and explains the aggregate-token behavior, which is the main thing an agent could get wrong. It leaves return shape only lightly sketched, so it is strong but not fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter already documents its own examples ('Florida', 'Eleventh Circuit', 'tribal courts', 'veterans'). The description reinforces that group names are valid inputs but adds no format, matching, or ambiguity-handling detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Resolve a court name to court_id values') and names the downstream consumer ('usable in the search_cases court filter'), which separates it cleanly from lookup siblings like find_case, find_citation, and find_authority.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Makes the use case explicit: call this to obtain identifiers for the search_cases court filter, including whole groups like tribal courts or bankruptcy. It gives clear context but no explicit 'do not use this for X' exclusion, so it stops just short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ENTRY BY ISSUE. Use this FIRST when the question arrives as facts or an issue rather than a case name ("can the appellate court affirm on a ground the trial court never reached", "impact rule emotional distress", "Fabre defendant"). Returns (1) the doctrine as courts in that STATE actually name it, with the cases on EACH side (followed_by / questioned_by, from how each citing opinion treated the case), example sentences judges wrote, the statutes those opinions construe, and every state where the phrase is alive with its year span (a doctrine retained in one state and abandoned elsewhere shows as a stalled span); and (2) the matching mined propositions (the rule text courts quote) with per-passage flags. Doctrine name is not case health: an issue can be alive while its anchor case is red. Read questioned_by before relying on followed_by. A q of more than 8 substantive words is read as a proposition: propositions (matched against all of it) come first. The default answer holds 3 issues and 5 statutes and stays under ~12,000 characters (issues_omitted counts the rest); max_issues or detail=true returns more. Routing: a proposition or quoted language -> find_authority (pasted verbatim); a doctrine name or fact pattern -> find_issues; a party name, statute number or keywords -> search_cases.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | The issue or doctrine in 2-6 words as a lawyer would name it: "tipsy coachman", "economic loss rule", "Stand Your Ground immunity", "Richardson hearing" | |
| state | No | Two-letter state code of the CITING courts (fl, ga, tx, ny ...). Strongly recommended: the map is keyed per state. Omit to search all states. | |
| detail | No | true = the full-size answer: 8 issues, 8 statutes each, no character budget | |
| max_issues | No | Default 3 (8 with detail=true), max 20 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the fields returned (doctrine naming, followed_by/questioned_by from citing opinions, example sentences, statutes, state liveness spans, mined propositions), the default budget (3 issues, 5 statutes, ~12,000 chars, issues_omitted counting the rest), and the query-length parsing rule. It does not contradict annotations, but much of this is answer-format description rather than tool behavior, keeping it at a solid 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The routing rule is front-loaded well and earns its place, but the long parenthetical about followed_by/questioned_by, stalled spans and per-passage flags is dense, run-on, and mixes output-format exposition into the description. It is over-long for an entry-point tool and buries the critical routing guidance amid answer-shape detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, high-stakes legal-research entry tool with no output schema, the description conveys what the answer contains, how the default budget and issues_omitted work, and how query shape changes interpretation. The main missing piece is an explicit note on the reliability caveat for followed_by/questioned_by (which it gestures at) and any latency expectation, but nothing essential to calling it correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 q, state, detail and max_issues in detail, including the 2-6 word naming convention and the default/max values. The description adds interpretive value for q (the >8 substantive word proposition rule, and that propositions are matched and returned first) and for state (it is keyed per state, so strongly recommended), but detail and max_issues only restate schema content. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete routing rule ("ENTRY BY ISSUE... Use this FIRST when the question arrives as facts or an issue rather than a case name") and gives three literal example queries. It distinguishes itself sharply from siblings by naming find_authority and search_cases and the exact input shapes that route to each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (facts or issue rather than case name), when to route elsewhere (proposition/quoted language -> find_authority, party name/statute/keywords -> search_cases), plus an automatic behavior boundary: a q longer than 8 substantive words is treated as a proposition. This covers when, when-not, and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one case: metadata, parallel citations, treatment flag, and full opinion text (paginated via offset/max_chars). cited_by is CourtListener's citation count; for a decision filed as several twin clusters it is summed over them (cited_by_note says so), and a duplicate or stub twin id is answered with its survivor (note says so). Citations inside the returned text are checked against the reporter index (embedded_citations); citation_warnings names any the court itself got wrong. Identify the case by cluster_id (from search_cases results) or by reporter citation. find_text returns passages: up to 5 sentence-bounded windows holding a phrase (or its closest match) with star_page and offset, so a long opinion need not be paged (pass include_text=false to get only those); quotable=true adds quotable_passages, the passages of this opinion other courts quote. Quotation marks mean pasted from a tool result (opinion text, passage, best_match). If you typed a quote from memory, run verify_quote and use best_match. Run check_brief on the finished draft and apply its corrections. Copy cite_as for the citation (first page, then pin).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Character offset for paging long opinions (use next_offset from a prior call) | |
| citation | No | Reporter citation, e.g. "819 So. 2d 732" (used if cluster_id absent) | |
| quotable | No | With include_text, also return quotable_passages: the passages of this opinion other courts quote, with star_page | |
| case_name | No | Case name; used only when the citation is not in the reporter index (newer than it): resolves by name + decision-date window and returns candidates if several cases share the name | |
| find_text | No | A phrase to locate in the opinion: returns passages (exact, or the closest match) with star_page and offset | |
| max_chars | No | Max characters of opinion text to return (default 40000, max 150000) | |
| cluster_id | No | Cluster id from search results | |
| include_text | No | Include opinion text (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only/idempotent safety, but the description adds substantial non-obvious behavior: cited_by is summed across twin clusters, duplicate or stub twin ids resolve to their survivor, embedded citations are validated against the reporter index, citation_warnings flags court-level misquotes, and find_text returns up to five sentence-bounded windows. This is deep behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core deliverable, then progressively narrower detail. It is dense and long, and a few parenthetical asides could be trimmed, but essentially every sentence conveys operational information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 8 optional parameters, the description carries the full burden and does so: it describes the return payload, paging fields, citation-validation artifacts, and the unnamed-by-schema quote-verification workflow. An agent has enough to call this correctly in the intended flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: the cluster_id/citation precedence, that case_name only applies when the citation is outside the reporter index, that include_text=false yields only find_text passages, and that quotable=true adds quotable_passages. Only minor gaps remain, such as not restating max_chars limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ('Fetch one case') and then enumerates exactly what comes back: metadata, parallel citations, treatment flag, and full opinion text. It is clearly distinguishable from search_cases, get_citing_cases, and verify_quote, which are named as sources or alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: identify the case by cluster_id (from search_cases) or reporter citation, use find_text instead of paging a long opinion, call verify_quote when quoting from memory, and run check_brief on the finished draft. When-to-use and which-sibling-to-use conditions are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full citator list: every ranked case citing this one, with judge-written parentheticals (usable verbatim in a brief), verbatim quotes, pin cites, and the citing court's own Bluebook signal. Filter by flag color. Best for FINDING SUPPORTING AUTHORITY and parentheticals; for comprehensive negative-treatment checking use get_treatment (this list covers only each case's top-ranked ~50 citers).
| Name | Required | Description | Default |
|---|---|---|---|
| citation | No | Reporter citation (used if cluster_id absent) | |
| case_name | No | Case name; lets a citation newer than the reporter index resolve by name + date (candidates returned if several share the name) | |
| cluster_id | No | Cluster id of the case | |
| max_citers | No | Default 25, max 100 | |
| flag_filter | No | Comma list of flag colors to include: red,yellow,green,neutral,procedural. Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes further by revealing the shape of the result (parentheticals written by judges, verbatim quotes, pin cites, signals) and the important limitation that only top-ranked ~50 citers are included. Pagination/ordering beyond that is not spelled out, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with the payload description front-loaded and the sibling routing plus coverage caveat trailing. Every clause carries information; none is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe returns, and it does so thoroughly (signals, quotes, pin cites, parentheticals plus flag colors). Combined with the stated citer-coverage limit, an agent has everything needed to call it and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 citation, case_name, cluster_id, max_citers, and flag_filter. The description only reinforces the flag-color filtering, adding no syntax or resolution detail beyond the schema, which matches the baseline-3 rule when structured fields do the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Full citator list: every ranked case citing this one') and enumerates the exact payload (parentheticals, verbatim quotes, pin cites, Bluebook signals). It is clearly distinguishable from get_treatment, which is named as the sibling for a different job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('Best for FINDING SUPPORTING AUTHORITY and parentheticals') and when not to ('for comprehensive negative-treatment checking use get_treatment'). It also discloses the coverage boundary (only each case's ~50 top-ranked citers), which is exactly the kind of routing caveat an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is this case actually cited FOR? Returns the distinct legal propositions courts cite the case for (headnote-grade), each with its OWN treatment flag and counts. A case can be good law on one proposition and overruled on another. Use before citing a case for a specific point, and to find the strongest proposition to cite it for. passage is the opinion's own wording of the proposition with its star_page; passage null means citing courts paraphrase it. Pass proposition (your use of the case) to get proposition_match, the one proposition it matches, and proposition_note (MCP14_20260925). Quotation marks mean pasted from a tool result (opinion text, passage, best_match). If you typed a quote from memory, run verify_quote and use best_match. Run check_brief on the finished draft and apply its corrections. Copy cite_as for the citation (first page, then pin).
| Name | Required | Description | Default |
|---|---|---|---|
| citation | No | Reporter citation (used if cluster_id absent) | |
| case_name | No | Case name; lets a citation newer than the reporter index resolve by name + date (candidates returned if several share the name) | |
| cluster_id | No | Cluster id of the case | |
| proposition | No | Optional: the point you cite this case for; returns proposition_match + proposition_note | |
| max_propositions | No | Default 10, max 25 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety (readOnlyHint, idempotentHint, destructiveHint false). The description adds substantial behavioral detail beyond that: what the output contains (distinct propositions each with own treatment flag and counts), the meaning of a null passage, the proposition parameter's return fields (proposition_match, proposition_note), and the quotation-mark convention for pasted text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core question and purpose, but the final three sentences about quotation marks, verify_quote, and check_brief are tangential workflow instructions that inflate length. Most sentences carry useful detail, but the structure could be tighter and more scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain return values; it does so for propositions, treatment flags, passage, and proposition_match/proposition_note. It covers the main use case and key outputs, but omits max_propositions behavior and the full response shape. Adequate for a read-only lookup tool whose annotations already cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema for the 'proposition' parameter by explaining it is 'your use of the case' and triggers proposition_match/proposition_note. It also clarifies 'passage' as an output field, though citation, case_name, cluster_id, and max_propositions receive no additional elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns') and resource ('distinct legal propositions courts cite the case for') plus key attributes (headnote-grade, own treatment flag and counts). The phrase 'A case can be good law on one proposition and overruled on another' clearly distinguishes this tool's proposition-level granularity from sibling get_treatment, which likely gives case-level treatment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it: 'Use before citing a case for a specific point, and to find the strongest proposition to cite it for.' It also cross-references verify_quote and check_brief for adjacent workflow steps. However, it does not name a when-not scenario or an alternative tool that performs the same job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | 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. | |
| offset | No | Character offset for paging long sections | |
| citation | Yes | Section 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_chars | No | Max characters of body text (default 40000) | |
| jurisdiction | Yes | Which 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"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), yet the description adds rich behavior beyond them: temporal_warning leading the response for amended/enacted sections, status_warning with successor for repealed/renumbered sections, the currency.status enumeration, U.S. Code omission semantics, and CFR 'removed' handling with the eCFR point-in-time link. This is exactly the kind of edge-case disclosure the dimension rewards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded correctly, but it is a single dense paragraph of run-on sentences with repeated ALL-CAPS labels, and it redundantly re-explains as_of behavior already documented in the schema ('leads with temporal_warning... prior_text_available'). The content is largely justified given no output schema, but the structure and duplication keep it below a clean 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 returns — and it does so thoroughly (currency fields, temporal_note, warning types, status values, successor, as_of_version, CFR removal link). For a complex retrieval tool, nothing an agent needs to call it correctly appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage the baseline is 3, but the description adds real meaning: it explains what as_of triggers (temporal_warning FIRST, prior_text_available, as_of_version), and clarifies that a state's court rules live in the same corpus code, citing examples like 'CR 56' for WA. These add interpretive value, though much overlaps with the already-rich as_of schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause 'Fetch the full text of a statute, rule, or code section' gives a specific verb (fetch full text) and resource, and distinguishes the tool from search_statutes (search) and get_case (cases) by scope. An agent immediately understands this is a retrieve-by-citation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives strong conditional guidance ('For a crime, a contract, a limitations period or a procedural step, establish the operative date first and pass it as as_of'), which is clear workflow context. However, it never explicitly routes the agent to or away from siblings such as search_statutes or get_case, so it stops short of the 5-level when/when-not/alternatives standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is this case still good law? Returns the Syfertize treatment flag (red = overruled/superseded, yellow = questioned/distinguished, green = followed, procedural = cert/rehearing denied) plus the citing cases behind each signal with quoted context. A case can be green overall and red on the proposition you need it for (MCP14_20260925): propositions_summary lists the propositions courts cite it for (most-cited first), each with its OWN flag; pass proposition (your use of the case) and proposition_match returns the one that matches, with its negative_citers, and treatment.proposition_note states the result ("no proposition-level signal for this use" = only the case-level flag applies).
| Name | Required | Description | Default |
|---|---|---|---|
| citation | No | Reporter citation (used if cluster_id absent) | |
| case_name | No | Case name; lets a citation newer than the reporter index resolve by name + date (candidates returned if several share the name) | |
| cluster_id | No | Cluster id of the case | |
| max_citers | No | Max citing-case detail rows (default 25, max 100; negative signals sort first) | |
| proposition | No | Optional: the point you cite this case for, in your words or as quoted; returns proposition_match (that proposition's own flag and negative citers) and treatment.proposition_note |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive, and closed-world behavior, and the description adds substantial detail beyond them: color semantics for red/yellow/green/procedural, case-level vs proposition-level treatment, quoted citing context, and negative-citer sorting. This is rich, non-contradictory disclosure of the tool's output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core answer and return format are front-loaded, and most detail is relevant for a complex treatment lookup. It is dense and could be more structured than one long paragraph, but it does not contain much wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 return-value burden and does so well by explaining flags, citers, and proposition-level nuance. It omits an explicit statement that at least one identifier (citation, case_name, or cluster_id) is needed despite zero required parameters, which is a small completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented and the baseline is 3. The description goes further by explaining the proposition parameter's purpose and return semantics (proposition_match, negative_citers, treatment.proposition_note), adding meaning beyond the schema's brief parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: returns the Syfertize treatment flag with color meanings plus the citing cases behind each signal. It is clearly about treatment, but it never names or contrasts sibling tools such as get_citing_cases or get_propositions even though it also returns citing and proposition data, so sibling differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the title/question and by guidance on passing the proposition parameter when citing the case for a specific point. However, there is no explicit when-to-use/when-not-to-use statement or alternative routing to sibling tools. An agent must infer that this is the treatment tool rather than get_citing_cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search over 10.7M U.S. court opinions (all states + federal, via syfert.com). Call this to find case law on a topic, locate a case by name, or find cases citing a statute. Routing: a proposition or quoted language -> find_authority (pasted verbatim); a doctrine name or fact pattern -> find_issues; a party name, statute number or keywords -> search_cases. Each hit carries bluebook and url (snippet up to 240 chars); a hit whose snippet quotes an earlier case carries passage_origin, the case to cite for that language. A q that is one citation or an "X v. Y" caption naming one case decisively also returns that case as direct_hit above the results (find_case does only that lookup). Query syntax: boolean AND/OR/NOT, "exact phrases", proximity (term1 w/5 term2), wildcards (neglig*), and field filters inside q (name:, judge:, syllabus:). Statute-style numbers like 83.49 are matched as citations to that statute. total may be null: a court or date filter makes the exact count too expensive to compute, and total_pages + total_note then carry the scale. partial: true means the time budget was hit; see partial_note. tier names the caller's plan; _source names the backend that served the search: xeric = the dedicated index, cloud = the cloud index behind a short queue. When no opinion holds every word of a long query, the answer may carry relaxed=true with relaxed_note and relaxed_terms_kept / relaxed_terms_dropped: its rows (closest_match) hold only the kept words.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query. Examples: "premises liability" AND negligence; name:miranda; 768.28 sovereign immunity | |
| page | No | Page number, default 1 | |
| sort | No | Default relevance (authority-weighted). | |
| court | No | Court id filter, comma-separable, trailing * for prefix. E.g. fla* (all Florida), scotus, ca11, fladistctapp1. Also takes a group token covering a whole set of courts: us-circuits, us-districts, us-bankr, fl-fed-districts, fed-veterans, fed-military, fed-immigration, fed-taxtrade, tribal-navajonation, tribal-cherokee. Use find_court to resolve either. Takes precedence over state. | |
| judge | No | Judge name filter | |
| state | No | Two-letter state code (fl, tx, ny, ca ... all 50 states + dc). Scopes the search to that state's OWN courts — supreme, appellate, circuit and county. Federal district and bankruptcy courts sitting in the state count as federal here, not as state courts, so they are excluded; add them with the court argument. Ignored if court is also given. | |
| status | No | published or unpublished | |
| compact | No | true = shorter rows (bluebook, url, date_filed, cited_by, status if not published, treatment flag and red/yellow counts, snippet, holding, passage_origin); default false | |
| date_to | No | YYYY-MM-DD | |
| per_page | No | Results per page, default 10, max 20 | |
| date_from | No | YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, yet the description adds substantial behavioral context beyond them: total may be null when court/date filters make counting expensive (total_pages/total_note compensate), partial:true means the time budget was hit, and relaxed=true rows hold only kept words. This is exactly the edge-case disclosure the annotations cannot provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-organized with labeled 'Routing:' and 'Query syntax:' segments and purpose front-loaded. Long for a single paragraph, but the detail is warranted by an 11-parameter tool with no output schema; a few clauses could still be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 full return-value burden and does so thoroughly (bluebook, url, snippet up to 240 chars, passage_origin, direct_hit, total/partial/relaxed fields, tier and _source backends). Nothing an agent needs to call or interpret results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by spelling out the query syntax (boolean AND/OR/NOT, exact phrases, proximity w/5, wildcards, name:/judge:/syllabus: field filters) and the statute-number-as-citation behavior, which the brief schema examples omit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Full-text search over 10.7M U.S. court opinions') and immediately scopes it against siblings via explicit routing rules. An agent can distinguish it from find_authority, find_issues, and find_case without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use branches: 'a proposition or quoted language -> find_authority; a doctrine name or fact pattern -> find_issues; a party name, statute number or keywords -> search_cases.' Also clarifies find_case's narrower role. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find every case that has quoted a phrase. Phrase-matched search over 4.3M distinct passages quoted by two or more opinions, ranked by how many cases quote them. Use it to (a) find the true source of half-remembered language BEFORE attributing it, and (b) locate the canonical wording of a rule. Returns the passage, its source case, and adoption counts. When no passage has the exact phrase it falls back to passages sharing its distinctive words (match_kind relaxed), and it adds the mined propositions later courts cite a case for (match_kind proposition). Same tool as find_authority. Routing: a proposition or quoted language -> find_authority (pasted verbatim); a doctrine name or fact pattern -> find_issues; a party name, statute number or keywords -> search_cases. Quotation marks mean pasted from a tool result (opinion text, passage, best_match). If you typed a quote from memory, run verify_quote and use best_match. Run check_brief on the finished draft and apply its corrections. Copy cite_as for the citation (first page, then pin). The first 3 rows carry star_page and cite_as.
| Name | Required | Description | Default |
|---|---|---|---|
| quote | Yes | The phrase to search for (three or more words; matched as a phrase, not keywords) | |
| state | No | Optional two-letter state code: relaxed and proposition matches are limited to that state's courts (falls back to all courts when it has none); verbatim exact-phrase matches from any court are kept, that state's first |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say read-only/idempotent, but the description adds substantial behavior: the relaxed fallback when no exact phrase exists, the proposition match kind, the ranked-by-adoption ordering, and the returned fields (passage, source case, adoption counts). It also notes first-3-rows carry star_page and cite_as.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and fallback behavior are front-loaded well, but the text is dense and blends in tangential cross-tool workflow (verify_quote, check_brief, 'copy cite_as', 'quotation marks mean pasted') that dilutes focus on this tool's own invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search with no output schema, the description supplies the return shape, the two fallback modes, ranking semantics, and routing, leaving nothing an agent needs in order to call it correctly or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both the quote ('three or more words, matched as a phrase') and state parameters, including the verbatim-vs-relaxed state scoping. The description adds no syntax or format detail beyond that, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('find every case that has quoted a phrase') with concrete scope (4.3M passages, ranked by adoption count). The routing rules explicitly distinguish it from find_authority, find_issues, and search_cases, so an agent can place it among its 16 siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use cases ((a) sourcing half-remembered language, (b) locating canonical rule wording) plus a full routing block mapping proposition/quoted-language, doctrine/fact-pattern, and party/statute inputs to three different sibling tools. It also names follow-ups (verify_quote, check_brief).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search statutes, COURT RULES and codes by citation or topic, for EVERY U.S. state plus federal. For a specific state, pass state="wi" (any two-letter code, all 50 states + DC) and a topic or section number; add kind="rule" for that state's court rules or kind="statute" for its code. Without state it searches only the kinds named in kinds (default: Florida). Handles citation lookups ("83.49", "174.02") and topic queries ("dog bite strict liability"). Each result carries currency (text_last_changed and, where recorded, last_amended_year / effective_date / status / successor) and corpus_currency gives each corpus's edition and current-through date. 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. (as_of is taken by get_statute and check_citation.)
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Citation or topic query, max 200 chars | |
| kind | No | With state: scope to one source — "rule" (that state's court rules) or "statute" (its code). Omit to search both; the response's sources field lists what the corpus holds and how many rows of each. | |
| kinds | No | Used only when state is absent. Comma list of corpus kinds: statute (FL statutes), rule (FL court rules), fac (Fla. Admin. Code), ocga, usc, cfr, fedrule, sg, plus any state's own kind ("nc", "tx") and rules kind ("nc-rule", "tx-rule"). Default "statute,rule" is FLORIDA ONLY. | |
| limit | No | Max hits (default 5, max 25) | |
| state | No | Two-letter state code to search that state's corpus (e.g. wi, tx, ny, ca). Covers all 50 states + dc. That corpus holds the state's COURT RULES too in 44 of the 51 — all but ks, la, nh, ok, sd, vt, whose rules of procedure are codified as statutes. Also accepts state="fac" for the Florida ADMINISTRATIVE Code (agency rules such as 6A-6.03019) — state="fl" is the Florida Statutes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds real value beyond that: result fields (text_last_changed, last_amended_year, effective_date, status, successor), corpus_currency, and the operative-date caveat that text is the held edition rather than the law on every date. However, it does not describe result ordering, pagination beyond limit, or how source coverage is surfaced in the response, so it stops short of full behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Core purpose and the state/kind routing are front-loaded, and every sentence carries actionable content. It is somewhat dense and leans on all-caps emphasis plus a long parenthetical, but the length is justified by the multi-jurisdiction behavior it must convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter search tool with no output schema, the description covers defaults, jurisdiction resolution, result currency fields, and the operative-date pitfall. Nothing essential for correct invocation or result interpretation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds meaning on top of it: examples of state codes, the rule/statute semantics of kind, the conditional use of kinds, and citation-vs-topic query examples. It also clarifies that as_of belongs to get_statute/check_citation rather than this tool, which prevents a common misuse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (statutes, court rules, codes) with explicit scope (every U.S. state + federal). It is clearly distinguishable from siblings like search_cases, find_authority, and get_statute, which retrieve other document types or a single known provision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use routing: pass state for one jurisdiction, kind to scope to rule vs statute, kinds only when state is absent, and the default is Florida-only. It also names alternatives for the as_of workflow (get_statute, check_citation), so the agent knows where operative-date lookups belong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crowdsourced AI feedback on a Syfertize treatment flag. When the evidence in front of you (an overruling, abrogating or reinstating opinion, or a later court holding the case is still good law) shows a case's flag is wrong, propose red (no longer good law) or green (still good law) with the SHORTEST possible one-line reason, ideally naming the authority. Only red or green is accepted, not yellow. Identify the case by cluster_id, or by citation (+ case_name). The reason must concern the case's legal status only, never the user's facts, question, client or document. Returns the current flag and what was recorded; a proposal equal to the live flag is not recorded. By calling this you help syfert.com improve its treatment flags through AI feedback. Nothing about your session, user, query or documents is logged: only the case id, the flag you propose, your one-line reason, the authority you name and the date are stored, for human review. Your suggestion does not change the live flag.
| Name | Required | Description | Default |
|---|---|---|---|
| flag | Yes | The flag the case should carry: red = no longer good law (overruled, abrogated, superseded); green = still good law | |
| reason | Yes | One line, as short as possible (max 280 characters), e.g. "Overruled by Dobbs v. Jackson Women's Health Org., 597 U.S. 215 (2022)." | |
| citation | No | Reporter citation of the case (used if cluster_id absent), e.g. "410 U.S. 113" | |
| authority | No | Optional: citation of the case or statute the reason relies on (max 200 characters) | |
| case_name | No | Optional case name; checked against the case the citation resolves to | |
| cluster_id | No | Cluster id of the case whose flag is wrong |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it clarifies that the suggestion does not change the live flag, that a proposal equal to the live flag is not recorded, what is returned (current flag and what was recorded), and exactly what is or is not logged (case id, flag, reason, authority, date; no session, user, query or document data). That data-retention and no-op disclosure is precisely the context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and trigger lead, and the dense constraint sentences each carry weight. Minor bloat remains in the closing promotional sentence about helping syfert.com improve its flags, which adds no invocation guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write-ish, 6-parameter tool with no output schema, the description covers identity paths, allowed values, reason format and length limits, return contents, and the no-op/equality edge case. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage the baseline is 3, but the description adds real meaning: identity may be supplied either by cluster_id or by citation with an optional case_name cross-check, and it restates the red/green enum restriction in plain language. The authority field's role (the case or statute the reason relies on) is also framed functionally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (propose/suggest) and resource (a red/green treatment flag correction) with the exact evidence trigger for it. It is clearly distinguishable from read-side siblings like get_treatment, check_citation and get_citing_cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use conditions (an overruling, abrogating or reinstating opinion, or a later holding that the case is still good law) plus hard exclusions (only red or green, never yellow; the reason must concern legal status only, never the user's facts, question, client or document). Nothing about selecting this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check one quotation against the full text of the opinion it is attributed to, before it goes in quotation marks. Returns verdict (verbatim | near | absent), percent, best_match (the opinion's own sentence, up to ~600 characters), star_page (the last *page marker before it, null when the text carries none), offset (get_case offset), case and advice. near means the opinion says it in other words: paste best_match instead. absent means the words are not in this opinion. Identify the case by cluster_id or reporter citation (case_name helps a citation newer than the reporter index). Quotation marks mean pasted from a tool result (opinion text, passage, best_match). If you typed a quote from memory, run verify_quote and use best_match. Run check_brief on the finished draft and apply its corrections. Copy cite_as for the citation (first page, then pin).
| Name | Required | Description | Default |
|---|---|---|---|
| quote | Yes | The quoted words exactly as you intend to use them (three or more words) | |
| citation | No | Reporter citation of that case, e.g. "376 So. 2d 230" (used if cluster_id absent) | |
| case_name | No | Case name; lets a citation newer than the reporter index resolve by name + date | |
| cluster_id | No | Cluster id of the case the quote is attributed to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description goes further by enumerating the return fields (verdict, percent, best_match, star_page, offset, case, advice) and interpreting the verdict enum. However, 'percent' is never explained, so a key piece of returned behavior is left ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core check is front-loaded in the first sentence, then return values, then case identification, so scanning order is sensible. It is dense and mixes in agent-workflow rules (quotation-mark conventions, running check_brief) that make it longer than strictly needed, though each rule is actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 return-value burden and mostly does so, including how to act on 'near' and 'absent'. Gaps remain: the meaning of 'percent' and the handling of quotes shorter than the schema's three-word minimum are unaddressed, which matters for a tool whose whole value is the verdict.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds real meaning by explaining how the case is identified — cluster_id or reporter citation, with case_name as the fallback for citations newer than the reporter index. That precedence rationale goes beyond the schema's terse per-field text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a precise verb and resource — checking one quotation against the full text of the opinion it is attributed to — and scopes it with a trigger ('before it goes in quotation marks'). It is clearly distinguishable from siblings like search_quotes (finding quotes) and check_brief (draft-level review).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use rules ('before it goes in quotation marks', 'if you typed a quote from memory, run verify_quote and use best_match') and names the alternative workflow for text that was pasted from a tool result, plus a downstream routing instruction to check_brief. Alternatives and conditions are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_brief1 field changedInput schema / properties / forumAdded value: +{
+ "description": "Optional. The court the document will be filed in: a court id (fla, ca9, texapp, flsd, scotus) or a two-letter state code / state name (fl, TX, New York). Unpublished cited cases are then checked against the citation rules that apply in THAT court (cites[].citability.forum); without it the issuing court's own rule is reported.",
+ "type": "string"
+}check_citation1 field changedInput schema / properties / as_of / descriptionPrevious 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."get_statute1 field changedInput schema / properties / as_of / descriptionPrevious 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."check_citation1 field changedInput schema / properties / as_ofAdded 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"
+}get_statute1 field changedInput schema / properties / as_ofAdded 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"
+}export_documentcheck_briefcheck_citationfind_authorityfind_casefind_courtfind_issuesfind_related_casesget_caseget_citing_casesget_propositionsget_statuteget_treatmentsearch_casessearch_quotessearch_statutessuggest_treatmentverify_quoteVerifies legal citations vs primary sources: existence, quote match, proposition support.
Check if a US legal citation exists, names its case and has a valid pin cite; or find a case. Free.
Resolve, search and verify legal citations against the official sources, with provenance.
Search U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Add one secure layer between your agents and this server.
