ndlaw

by jet52

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.4.0
Disambiguation3/5
Several clusters overlap: four opinion-search tools (search_opinions, search_boolean, search_faceted, search_by_case_type) and multiple citator/citation-graph tools (check_treatment, get_citing_opinions, check_draft, detect_overruled_in_draft) have blurred boundaries. Most individual descriptions are clear, but an agent could easily pick the wrong search or citator variant.
Naming Consistency4/5
The dominant get_/search_/lookup_/verify_/check_ verb_noun pattern is consistent and predictable, and the AG and JEAC tool families mirror each other exactly. A few noun-only names (justice_info, case_summary, constitutional_amendments, more_like_this) and gerund forms (authoring_justice_on_issue) are minor deviations in an otherwise coherent scheme.
Tool Count2/5
Forty tools is well past the 25+ threshold; even with a legitimate multi-corpus legal-research scope, the surface is heavy and several tools could be consolidated (e.g., search_opinions/search_boolean/search_faceted, find_opinions_construing/get_notes_of_decisions). An agent must navigate a very large namespace for what are often variations of search and citation workflows.
Completeness5/5
The server covers the full research lifecycle: opinion lookup/search/text, citation verification and citator, statutory/rule/constitutional lookup with history and point-in-time text, AG opinions, JEAC opinions, citation graphs in both directions, and drafting checks. No obvious dead ends or missing core operations for North Dakota primary-law research.
Average 4.3/5 across 40 of 40 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on August 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Creative Commons Zero v1.0 Universal.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully discloses that partial matches are supported and gives example case type values. It leaves read-only safety implicit in the word 'Search' and does not mention output behavior, ordering, rate limits, or access requirements, though the output schema covers return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The example values illustrate the parameter meaning, and the partial-match sentence adds necessary behavior information. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Between the rich input schema, the output schema, and the description's examples and partial-match note, an agent has what it needs to construct a valid call. The only notable gap is guidance on choosing this tool over the numerous sibling search tools, which is more a usage-guidelines concern than a completeness one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters clearly, giving 100% schema coverage. The description adds value by providing concrete example case type values and confirming partial-match behavior, going slightly beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Search opinions by case type classification.' It gives example values that clarify the meaning of case type in this corpus. It does not explicitly contrast itself with sibling search tools such as search_faceted or search_opinions, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied: use this tool when you need to find opinions by case type, and partial matches are supported. However, it does not name alternatives or say when not to use this tool versus the many sibling search tools, so the guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses ordering by date, that matching is based on text references, and the prerequisite extraction step. However, it does not mention read-only behavior, failure modes, empty-result handling, or potential cost/performance aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a clear one-line purpose followed by two useful sentences on behavior and prerequisite. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a simple two-parameter tool, especially with an output schema present. It covers the main behavior, ordering, and the key prerequisite. Minor omissions like empty-result behavior or failure modes prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description does not add parameter-level meaning beyond the schema; it references the extraction prerequisite but not how parameters interact with it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb ('find') and resource ('opinions that cite a given opinion'), and the second clarifies results are opinions referencing the citation in text. This also distinguishes the tool from reciprocal siblings like get_cited_authorities and general lookup/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need opinions that cite a known citation. It adds a clear prerequisite (citation extraction must have been run), but it does not name alternatives or give explicit when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose the nature of the operation ('Get', 'Returns') and the broad output contents, which implies a read-only stats call. However, it does not explicitly state read-only behavior, auth expectations, or any caveats about the statistics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core purpose is first, followed by a useful output summary. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with an output schema, the description is sufficient: it says what the tool does and what the output contains. It is slightly light on when to use it versus siblings, but that is already captured in the usage-guidelines dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema provides no semantic load. Per the baseline for zero-parameter tools, the description does not need to add parameter meaning, and it correctly focuses on what the call returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get summary statistics about the opinion database.' It also previews the exact contents (counts, date range, top authors), making the purpose unmistakable and clearly distinct from the search/lookup siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over the many sibling search/lookup tools. The description implies it is for aggregate database-level stats, but it never states exclusions or names alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses result ordering but says nothing about date inclusivity, pagination, whether full opinions or metadata are returned, or edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the core purpose and add the useful ordering detail without filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the core purpose and ordering are stated, parameters are fully documented in the schema, and an output schema exists. It is adequate, though it could mention alternatives or edge-case behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all four parameters with descriptions, defaults, and constraints (100% coverage). The description adds no extra parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the action ('List'), the resource ('opinions'), and the scope ('within a date range'), and explicitly notes the reverse-chronological order. This clearly distinguishes it from sibling tools like lookup_opinion and search_opinions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as search_opinions or lookup_opinion. The date-range framing implies the main use case, but selection logic 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and does well by disclosing that FTS5 has no sentence/paragraph unit, so /s and /p are token-distance approximations. It also says the translated FTS query and approximation notes are returned for transparency, which is a meaningful behavioral disclosure beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and every line earns its place: a one-line purpose, a compact connector legend, and a brief caveat. The formatting makes the syntax scannable without boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The syntax is fully specified, and the presence of an output schema means return values don't need detailing. The only completeness gap is the lack of explicit when-to-use guidance versus sibling search tools, which is more of a usage-guideline issue than a call-correctness issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description adds useful query-syntax semantics for the query parameter but contributes nothing about limit, author, or date filtering, which are already well documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Westlaw-style Boolean / proximity search', naming a specific search mode and, through the schema's opinion filters, the resource type. It doesn't explicitly distinguish itself from siblings like search_opinions or search_faceted, but the Boolean/proximity emphasis marks it as the specialized structured query tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The connector reference implies this tool is for queries requiring Boolean operators or proximity, but the description never states when to choose it over search_opinions, search_faceted, or corpus-specific sibling searches. There are no exclusions or alternative routing cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses key behavioral and data-reliability traits: it searches full text, covers opinions from 1990 onward, and warns that the Code of Judicial Conduct has been restructured so cited rule/canon references may be outdated. This goes beyond a simple operation statement and helps the agent interpret results correctly, though it does not detail result ordering or read-only guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core function, the second adds useful topical context, and the third gives a critical caveat. Every sentence earns its place, and the note is positioned at the end where it can amplify rather than obscure the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is well-rounded for a search tool: it gives temporal scope, subject areas, and a crucial caveat about Code restructurings. The presence of an output schema covers return-value details, and the schema covers parameters. The main gap is a lack of explicit guidance on how this search differs from sibling search tools, but the domain-specific name largely compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters (query, year, limit) fully. The description adds domain context (topics like recusal and campaign conduct) but does not add any parameter-specific semantics beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Full-text search') and resource ('ND Judicial Ethics Advisory Committee opinions') with a temporal scope (1990–present). It clearly identifies what the tool does, though it does not explicitly differentiate it from sibling search tools like search_opinions or search_ag_opinions, relying instead on the domain-specific name and content context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when searching the full text of North Dakota judicial ethics advisory opinions—and gives helpful topic context. However, it does not explicitly state when not to use it or mention alternatives, leaving the agent to infer the selection criteria from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses that results are ranked by relevance and include snippets, and that the search spans all opinions. It does not address rate limits, authentication, or how broad/missed queries behave, but for a read-style search tool this is acceptable but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three short sentences, with the core action front-loaded and no filler. Each sentence contributes: scope, behavior/return format, and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the input schema fully describes all parameters, the description provides sufficient context for a typical search use case. It could be more complete by distinguishing against sibling search tools, but the overall picture is clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters clearly. The description adds no extra parameter-level semantics beyond stating the tool is full-text search, which is fine but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a full-text search across all opinions returning relevance-ranked results with snippets. It is specific about the resource and action, though it does not explicitly distinguish itself from siblings like search_boolean or search_faceted, which likely perform similar full-text searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool to find opinions on a topic, legal issue, or factual pattern, which gives an agent clear context for when it is appropriate. It does not mention alternatives or exclusion conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses ordering by date, the presence of a relation hint, and the likelihood of companion opinions and duplicates, including a clear caveat to verify relationships. This goes well beyond a bare functional statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core definition, followed by useful examples and a caveat. There is minor redundancy between the first sentence and the second sentence ('sharing the case's docket' vs 'same docket number'), but overall every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is largely complete: it clarifies what kind of results to expect, how they are ordered, and that verification is needed due to potential duplicates. It does not need to explain return values because the output schema exists, and no critical usage condition is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single 'citation' parameter as 'A citation or case name identifying the opinion.' The tool description adds no additional parameter-level detail, which matches the baseline of 3 for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it finds other opinions on the same docket number, covering rehearings, supplemental opinions, companions, and duplicates. This clearly distinguishes it from sibling tools like get_citing_opinions or get_authority_history by focusing on docket-linking rather than citation relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a research aid and advises verifying the relationship because duplicates and companion opinions may appear. However, it does not explicitly name alternatives or state when not to use this tool versus a sibling, so the guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior, and it does disclose the key return categories: metadata, extracted cross-links to ND primary-law authorities, and optional text. However, it does not mention edge-case behavior such as invalid or nonexistent opinion numbers, or explicitly state that the operation is read-only, which would be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the operation and key parameter, the second summarizes the return value. Every sentence adds useful information, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple, read-style lookup with three well-documented parameters and an output schema, so the description does not need to enumerate return fields. It adequately covers what the tool returns and the optional text parameter, though it does not clarify how this tool relates to the sibling get_opinion_text or handle not-found cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains all three parameters, including the meaning and defaults of include_text and text_limit. The description only reinforces the role of opinion_number and hints at include_text through 'optionally its text', adding little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') with a specific resource ('ND Attorney General opinion') and a precise lookup key ('by its number'), with an example format. This clearly distinguishes it from search-style siblings like search_ag_opinions and citation-focused siblings like get_ag_opinions_citing, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: use this tool when you have a specific AG opinion number and want the opinion's metadata, cited ND primary-law authorities, and optionally its text. It does not explicitly state when not to use it or mention alternatives, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses chronological coverage, full-text search scope, relevance ranking, and snippet-based return behavior. For a read-only search tool, this is adequate; it does not claim or hide any mutating behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler. The core function is front-loaded in the first sentence, the domain context in the second is informative, and the return behavior closes it efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% parameter documentation and an existing output schema, the description covers invocation and expected results well. It adds useful domain context about the legal materials the opinions construe. The only notable gap is explicit guidance on competing sibling search tools, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents query, year, limit, and opinion_type. The description does not add parameter-level meaning beyond clarifying that matching is 'full-text' and results include 'snippets,' so the rubric baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Full-text search across ND Attorney General opinions (1942–present).' It also states the output ('matching opinions ranked by relevance with snippets'), making the tool's purpose unmistakable and differentiating it from lookup or faceted sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need full-text relevance search across AG opinions, especially on ND statutes, constitution, court rules, or open-records law. However, it never explicitly names alternatives like lookup_ag_opinion for known citations or search_boolean/search_faceted for advanced query modes, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that tables are reconstructed from a geometry-bearing source, notes the two table types, and clarifies that the same content exists inline as a fixed-width block under a '[Table N]' anchor. This gives the agent useful context beyond the basic action, though it does not say what happens for opinions with no tables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: the core action is front-loaded in the first sentence, and the following sentences provide useful context about table types and the relationship to plain text without being redundant. It is moderately sized and every sentence contributes to understanding or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is fairly simple with two serializable parameters and an output schema, so the description need not explain return values. It sufficiently covers why tables need reconstruction, when text-cell tables exist, and how the structured output relates to the opinion's text_content, making it complete enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds contextual background but no parameter-level meaning beyond what the schema provides; the format parameter and citation examples are already covered in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return the reconstructed data tables in an opinion, structured for reading.' It clearly distinguishes this tool from flat-text retrieval tools by emphasizing structured, reconstructed table output and even contrasts it with the opinion's inline fixed-width text_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when this tool is useful: when an opinion contains tables that flat text renders as a scrambled run of cells, and when a cleaner rendering is needed for display or parsing. It references the alternative presentation in the opinion's own text_content, giving implicit guidance to prefer this tool for structured table access, though it does not explicitly name a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses that 'disposition' and 'syllabus_points' are derived/heuristic and should be verified, and that synthetic parallel cites are listed separately. It could also state read-only behavior, but the data-quality caveats are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, opening with the tool's role and then listing return fields in a structured way. The caveat about derived fields is placed at the end without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the main return fields and important caveats. It does not explicitly discuss when to prefer sibling tools, but overall it gives enough context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description already fully covers the single 'citation' parameter as 'A citation or case name identifying the opinion.' The tool description adds no additional syntax or interpretation details, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning 'bench-memo front matter for a case' and enumerates specific fields (caption, parallel cites, date, panel, disposition, etc.). This distinguishes it from full-text and search-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'One-call bench-memo front matter' gives clear context: use this when you need consolidated case summary data in a single call. It does not explicitly name alternatives or exclusions, but the intended use is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does well by explaining that in-corpus ND opinions are resolved to name/date/oid while others receive a source URL, and that official-source links are included where available. It does not address behavior for invalid citations or empty results, but the output schema covers the return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: a compact purpose statement followed by a detailed but efficient breakdown of result types. The most decision-relevant fact is front-loaded, and every sentence adds substantive value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one well-documented parameter and an output schema, the description is largely complete for selecting and invoking the tool. It explains the categories returned and the link-resolution behavior. It is slightly thin on error/unresolved-citation behavior, but that is not a critical gap for a read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter citation has 100% schema description coverage, so the baseline is 3. The description adds context that the citation identifies a case and that the tool maps authorities around it, but it does not add format or syntax details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Outbound authorities a case relies on, grouped by type,' which names the exact resource and scope. It is clearly distinct from sibling tools like get_citing_opinions (which would be inbound) and lookup_authority (which looks up a single authority). The follow-up details further specify what is returned: cited cases, statutes, court rules, constitutional provisions, and regulations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'outbound' and the phrase 'authority graph around a case' make the intended use clear: retrieve the authorities a given opinion relies on. It does not explicitly name alternatives or when-not-to-use conditions, but the directional framing distinguishes it from sibling tools such as get_citing_opinions without being misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden and does well: it states that results are returned newest first, that both docket-style and date-style citations are captured, and that the relationship is inbound from court opinions to AG opinions. It does not mention read-only semantics or error/empty-result behavior, but the key behavioral traits are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main action is front-loaded in the first sentence, and the following two sentences provide valuable context about citation direction and citation formats with no filler. The 'see ag_backlink' note is slightly cryptic but does not undermine the overall efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the input schema fully documents both parameters and an output schema exists, the description supplies the remaining essential context: the graph direction, the specific opinion types involved, the citation forms handled, and the sort order. It is nearly complete, though it could have briefly named the reverse-direction sibling for even clearer routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters already have clear descriptions in the schema, including the default and max for 'limit' and an example format for 'opinion_number'. The tool description adds no additional parameter-level detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') and names the exact resource: ND Supreme Court / Court of Appeals opinions that cite an AG opinion. It also clarifies the graph direction as 'inbound,' which distinguishes it from reverse-direction siblings such as get_ag_opinions_citing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need court opinions that cite a specific AG opinion. It gives useful context about the 'inbound direction' and the two citation styles, but it does not explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It does so well by disclosing the two ranking signals, co-citation and keyword overlap, and noting that each result reports both sub-scores for explainability. It does not mention error behavior or edge cases, but that is not a critical gap for a read-style similarity search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. The first states the tool's purpose; the second explains the ranking mechanism. No filler, no repetition of schema details, and the key differentiator is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter similarity search tool with an output schema, the description is nearly complete. It explains the ranking methodology, seed input, and explainable sub-scores. The only minor omission is explicit guidance on citation formats or edge cases, but the schema already documents the citation parameter as accepting a citation or case name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with clear descriptions for both citation and limit. The description adds 'seed opinion' to clarify the citation parameter, but does not provide additional format or usage detail. The schema carries the load, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Find opinions doctrinally similar to a given case.' It immediately distinguishes this from text search or citation-lookup tools by naming 'hybrid ranking' and its two signals. An agent can tell this apart from siblings like search_opinions or get_citing_opinions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: find doctrinally similar opinions based on shared cited authorities and salient terms. It does not explicitly name alternatives or say when not to use this tool, but the hybrid-ranking explanation provides enough contextual guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It transparently discloses FTS relevance ranking vs newest-first ordering, partial matching for disposition, and the 1997+ voting-data constraint affecting dissent/concurrence/unanimity filters. It does not discuss error handling, rate limits, or AND/OR combination semantics, but covers the key decision-relevant behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The core purpose is front-loaded, followed by the most important behavioral caveats. Every sentence earns its place and the text remains easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 optional parameters, no annotations, full schema coverage, and an output schema, the description includes the crucial behavioral nuances: ranking behavior, default ordering, partial matching, and the voting-data date limitation. It is slightly incomplete because it does not explicitly state how multiple facets combine or provide routing guidance relative to similar search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema by clarifying that query triggers FTS relevance ranking, that disposition is a partial match with a concrete example, and that voting-based filters only apply to 1997+ opinions. This enriches an otherwise schema-driven understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Faceted opinion search' and immediately specifies the resource (opinions), the operation (search), and the differentiator (filtering by metadata plus optional full text). This clearly distinguishes it from general search tools like search_opinions and search_boolean.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that any combination of facets may be supplied and describes the default ordering and relevance ranking, which implies when the tool is appropriate. However, it does not explicitly state when to prefer this tool over siblings such as search_opinions or search_boolean, nor does it mention when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does substantial work: it discloses that the tool confirms existence, returns specified fields in Redbook order, catches wrong volume/page/year, and compares the expected name against canonical to flag drift. It does not describe not-found/error behavior, but the core behavioral characteristics are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: a front-loaded purpose, a compact list of exact return contents, and the conditional behavior for expected_case_name. Every sentence carries distinct useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's behavior is simple enough that this description, together with an output schema and a fully described two-parameter input schema, is largely complete. The only notable omission is what happens when the citation or case cannot be verified, but that is a minor gap for an otherwise well-specified verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning: it gives example query formats ('2024 ND 156') and clarifies expected_case_name's role as a draft name checked against canonical for drift. This goes beyond the schema's terse field docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Verify' and the resource 'a citation or case name,' and immediately defines the deliverable: 'return its canonical form.' It details exact outputs (case name, filing date, authoring justice, parallel cites, formatted citation), which clearly distinguishes it from sibling lookup/search tools even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when a citation or case name needs canonical verification, and when expected_case_name is provided, name drift is flagged. However, it does not explicitly state when to prefer this tool over alternatives like lookup_opinion, get_parallel_citations, or verify_quotation, nor does it give any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It transparently explains that this tool returns text in chunks and how pagination behaves by moving offset forward by limit. It does not discuss edge cases like empty results or invalid citations, but the core read-only, paginated behavior is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the purpose front-loaded and usage instructions following. The second sentence slightly restates the first, but overall the description is tight and every sentence contributes actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated text reader, the description covers the key operational concern (how to page through long text) and the output schema removes the need to explain return values. It is slightly light on error/edge-case guidance, but nothing essential is missing for a correct first call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds practical semantic value beyond the schema by explaining the relationship between offset and limit for pagination, turning the parameters into a usable sequence rather than just individual fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('read') and resource ('opinion text'), and the chunking behavior clearly distinguishes it from sibling tools like lookup_opinion, get_opinion_figures, and get_opinion_tables. An agent can immediately understand what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool (long opinions) and gives an explicit pagination recipe: start at offset=0 and advance by the limit. It does not name alternatives or state exclusions, but the usage guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that text is excluded by default, explains the reason (keeping responses manageable), defines the truncation behavior via text_limit, and points to get_opinion_text for chunked reading. This adds meaningful behavioral context beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it starts with the core lookup action and citation forms, then states return contents, then handles text behavior. Every sentence earns its place without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, parameter coverage is complete, and sibling tools are available, the description supplies the missing behavioral guidance: what is returned, the default text exclusion, truncation semantics, and the chunked-reading alternative. An agent has enough context to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter already has a clear description and default. The description adds some useful framing around include_text and text_limit ('first text_limit characters', 'read in chunks'), but mostly reinforces what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Look up') plus resource ('an opinion') and defines the input scope ('by any citation') with concrete examples like '2024 ND 156' and '585 N.W.2d 129'. It also clarifies what is returned ('metadata and all known citations'), making it easy to distinguish from search_opinions and get_opinion_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this tool is for looking up an opinion when you have a citation, and it explicitly routes text-heavy needs to include_text=True or get_opinion_text() for chunked reading. It does not explicitly say when to prefer search_opinions over this tool, but the citation-based scope strongly implies the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully reveals that statutory/constitutional citations are canonicalized against installed corpora and that shorthand forms like '44-04-18' resolve. This goes beyond the schema and provides meaningful behavior without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence and supporting normalization details in the following sentences. Every sentence earns its place and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a lookup tool with an output schema, the description covers the essential input semantics, citation normalization, and supported authority types. It does not discuss zero-result behavior or limitations of the installed corpora, but these are minor gaps given the output schema and simple parameter set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by clarifying which citation types are accepted, how canonicalization works, and that shorthand citations resolve. This is genuinely helpful beyond the raw parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find ND Attorney General opinions that cite a given authority.' The 'Reverse index' phrase clarifies the direction of the lookup and distinguishes it from general opinion search tools like search_ag_opinions or get_court_opinions_citing_ag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the triggering use case: you have a citation and want AG opinions that cite it. It does not explicitly name alternatives or exclusions, but the context is concrete enough that an agent can decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that this is a reverse citation index and that old-form Canon citations are indexed at canon granularity, both of which meaningfully affect query behavior. It does not mention result ordering or failure behavior, but the output schema and examples help fill that gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. The primary purpose is front-loaded, followed by the most useful context and an important indexing caveat. Every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with an output schema, the description covers the tool's purpose, typical use, and a notable edge case. It does not explicitly position itself against sibling tools like get_ag_opinions_citing, but the ND JEAC scope in the name and description makes the boundary sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that any citation format works and by giving a specific example of old-form canon granularity, which the schema does not fully convey. This exceeds baseline without duplicating schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') and a clear resource: ND Judicial Ethics Advisory Committee opinions that cite a given authority. It also calls itself a 'reverse index', which differentiates it from ordinary search tools and from siblings like search_jeac_opinions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the most useful scenario (Code of Judicial Conduct provisions) while noting that any rule/statute/case citation works. It does not explicitly name alternatives or state when NOT to use it, but the context is clear enough for an agent to select it appropriately among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses that signals are heuristic and non-authoritative, tells the user to read the returned context and full opinion before relying on them, explains subsection parsing validity, and notes which provision version was in force. This is unusually transparent about output trustworthiness and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the length is earned: it front-loads the purpose, follows with per-opinion field definitions, and ends with an important reliability caveat. It is somewhat dense, but every paragraph carries substantive, non-redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — 8 parameters, rich output, no annotations — the description covers the essential behavioral and output semantics thoroughly: grouping, ranking, per-opinion fields, subsection validation, version context, and heuristic limitations. The output schema exists, so detailed return-structure documentation is not required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter documentation already handles most meaning. The description adds contextual value around concepts like subsection pinpoints and ranking signals, but it does not substantially expand on the parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (statutes, rules, constitutional provisions, admin-code sections) and a specific deliverable: annotated notes of decisions with citing sentences, subsections, and depth-of-treatment signals. It also distinguishes itself from find_opinions_construing's 'bare list,' so an agent can tell them apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context that this is the richer, grouped-and-ranked research view, and explicitly names find_opinions_construing as the sparser alternative. It does not state hard when-not-to-use conditions, but the alternative is clear enough for an agent to make a reasonable selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns one viewable image per call and that this keeps responses manageable, but it does not specify the image format (e.g., base64, URL, binary), error behavior for invalid indices, or any size/encoding constraints. This is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no wasted words. It front-loads the core behavior, then provides the necessary prerequisite step and rationale for one-image-per-call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter retrieval tool with a clear prerequisite workflow, the description gives an agent enough to call it correctly. The main gap is the lack of an output schema or explicit statement of how the image content is returned, but the provided workflow guidance largely compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents citation and fig_index with 100% coverage, so the baseline is 3. The description adds value by clarifying that fig_index selects 'a specific figure' and by directing the agent to use get_opinion_figures first to determine valid indices and choose based on captions/kinds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return one figure's image from an opinion, as viewable image content.' This clearly distinguishes it from siblings like get_opinion_figures (which lists figures) and get_opinion_text (which returns text).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to call get_opinion_figures(citation) first to see how many figures exist and their captions/kinds, then call this tool for a specific figure. It also explains the one-image-per-call policy, making the intended workflow unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it handles this well. It explains the output ordering (Redbook order), the completeness of the returned set, and a subtle non-obvious behavior: synthetic back-assigned [YYYY ND nnn] identifiers are returned separately and never folded into the formatted citation. This is exactly the kind of behavioral detail an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficiently structured: the first sentence states the core behavior, the second provides the practical use case, and the third flags an important edge-case behavior. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is complete enough for an agent to call it correctly. It covers acceptable input forms, the returned data's scope and ordering, and the unusual synthetic-identifier behavior. No critical operational information appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single 'citation' parameter, so the baseline is 3. The description adds meaningful semantics by clarifying that the parameter can accept 'any one citation' in formats like '44 N.W. 301' or '1 N.D. 1', and even a case name, going beyond what the schema literally states. This earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action — returning the complete parallel-cite set for a case in Redbook order — which clearly identifies the tool's function. It does not explicitly name or contrast sibling tools, so it falls just short of full differentiation, but the function is unambiguous and distinct from related tools like verify_citation or get_pinpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is clear: feed any citation or case name to obtain parallel cites, specifically to auto-fill missing neutral or N.W. parallels in a draft. It provides solid contextual guidance but does not explicitly state when this tool should not be used or which alternative tool to pick instead, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does so well: it discloses conditional mode selection, aggregate-stat content (authorship count, dissent rate), optional date filtering, and data-coverage limits. It does not detail error behavior or side effects, but the operation is clearly a read-only lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences. The mode distinction comes first, the filtering and coverage constraints follow, and no sentence is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema is present and only four parameters with one required, the description covers the main behavioral branches, date-range filtering, and temporal coverage. It doesn't mention behavior for invalid citations, but that is a minor edge case for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how 'citation' switches the mode and how 'date_from'/'date_to' apply specifically to aggregate stats, which is not obvious from parameter descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('justice information') and immediately specifies two concrete behaviors: a voting record for a cited opinion, or aggregate statistics across cases. This distinguishes it from sibling opinion-lookup and citation tools even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit branching guidance: 'If citation is provided, returns the voting record... Otherwise, returns aggregate stats.' It also states a clear temporal boundary (1997–present). It does not name sibling alternatives for cases outside that range, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses the search scope, the author filter, the newest-first ordering, snippet output, and the limitation that only authored majority/lead opinions are reflected. This is strong behavioral disclosure for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with the purpose front-loaded and the caveat placed last. Every sentence earns its place, and there is no repetition of schema boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the rich schema and presence of an output schema, fully supports correct invocation. It defines the inputs, behavior, output style, and a key historical limitation, and it situates the tool's purpose with the bench-memo signal context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that `issue` is searched full-text and `justice` filters by author, but it does not add meaning beyond the schema; `limit` is already well documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it 'searches issue and filters to opinions authored by justice, newest first, with snippets.' It clearly differentiates from sibling opinion-search tools by focusing on opinions authored by a specific justice and framing it as a bench-memo signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when an agent needs opinions a justice authored on an issue, especially as a predictive bench-memo signal. It also notes the attribution limitation for separate writings before 1997, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and handles it well: signals are disclosed as conservative, non-authoritative, heuristic, and scanned from the citing sentence alone. It also reveals ordering behavior (possible-negative and distinguished surfaced first) and the risk that treatment words may refer to a different case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the one-line definition, followed by mechanics, ordering behavior, and a necessary caveat. Every sentence earns its place; the only slight redundancy is between 'conservative, non-authoritative' and 'heuristic,' but that emphasis is justified for a legal-research tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and parameter coverage is complete, the description supplies the missing contextual risk factors: heuristic signals, non-authoritativeness, sentence-level scanning, and not being a good-law verdict. An agent has enough to decide when to use this tool and how to interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level details beyond the schema, though its discussion of truncation and ordering is relevant to the limit parameter. No compensation needed because the schema already documents citation, limit, and scan_limit clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb and resource: 'how later opinions have treated a case' and describes the specific output: citing sentence, paragraph, and treatment signal. The KeyCite/Shepard's-style framing gives it a distinct identity among sibling tools like get_citing_opinions or get_subsequent_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong usage boundaries: explicitly warns it is NOT a 'still good law' verdict and instructs the agent to read the returned sentence and full citing opinion before relying on it. It does not name alternative tools for other citator needs, so it stops short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it excels: it discloses that signals are heuristic and sentence-local, not a 'still good law' verdict, that unresolved citations were not checked, and that absence of a flag is not assurance. It also tells the user to always read flagged entries and the full citing opinion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then delivers process and caveats in a logical order. Every sentence earns its place: the extraction/resolution pipeline is explained briefly, and the extended caution is essential given the legal-safety implications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does, how it processes the draft, what output categories to expect, and the limitations of the results. Combined with the provided output schema and complete parameter schema, an agent has everything needed to invoke it correctly and interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions for draft_text, max_cases, and scan_limit are already clear and sufficient. The description does not add additional parameter-specific semantics, but it does not need to because the schema has already done the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'flag cited cases that later opinions may have overruled, superseded, abrogated, or distinguished.' It clearly states the tool's scope as a proofreading pass over a draft, which differentiates it from siblings like check_treatment or verify_citation that operate on individual citations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when to use the tool: for proofreading a draft to detect potentially overruled or distinguished citations. It gives strong contextual guidance, but it does not explicitly name alternative tools for single-citation checks or state when not to use this tool, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does disclose a key limitation: 'Version text is truncated here; full text comes from lookup_authority.' It also explains what each history entry contains. It could add detail about read-only guarantees or potential output size, but the essential behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact paragraphs, with the core purpose in the first sentence and the follow-up workflow in the second. Every sentence adds value, and there is no filler or repetition of schema boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one fully documented required parameter and an output schema, so the description needs only to clarify purpose, scope, and the truncation/full-text workflow. It does all of this succinctly, and even names the sibling tool to use next. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The schema already describes citation as 'A constitutional, statutory, court-rule, or admin-code reference,' and the description repeats this domain without adding new format examples, syntax, or disambiguation. It adds context about how the parameter relates to history lookup but not much beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Show the amendment history of a ND constitutional, statutory, court-rule, or administrative provision.' It names exactly what content is returned (every version with effective dates and enacting authority). It also differentiates itself from the sibling lookup_authority by noting that full text comes from there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'Use this to see how a provision changed over time.' It then directs the agent to a concrete alternative, lookup_authority, with the specific parameter as_of_date, and clarifies that version text is truncated here but full text comes from lookup_authority. This is clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and handles it well. It discloses what metadata is returned (index, kind, caption, PDF page, dimensions), that captions are editorial rather than the court's text, and that an empty list is returned both when an opinion has no figures and when figures.db is not installed. This gives an agent important expectations without needing structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely informative with no filler. The primary action and scope appear in the first sentence, followed by return-type details, a clear pointer to the image-fetching sibling, and edge-case behavior. Every sentence adds meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter listing tool with an output schema present, the description is complete. It covers what the tool returns, how it differs from the image-fetching sibling, caption provenance, and empty-list behavior including the missing-database case. An agent has enough information to decide when to use it and what result to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the citation parameter. The tool description does not add new parameter details beyond mentioning citation in the sibling call, but it doesn't need to because the schema already provides the citation format. This matches the baseline expectation for a fully covered schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List the figures reproduced in an opinion,' and clarifies the scope with concrete examples like plat maps, survey drawings, photos, diagrams, and tables-as-image. It also explicitly distinguishes itself from the sibling get_opinion_figure_image by stating that this tool returns metadata and that the sibling fetches actual bytes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context: it is for listing figure metadata, and it directs the agent to get_opinion_figure_image(citation, fig_index) for actual image bytes. It does not explicitly list exclusions or formal when-not-to-use conditions, but the sibling pointer effectively routes between the two figure-related tools. The mention of tables-as-image also implies a distinction from get_opinion_tables, though this is not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals what each mode returns—text plus pinpoint cite, or located paragraph with verbatim status—and flags the pre-1997 limitation. It stops short of explicitly stating non-mutating read-only behavior, though 'Resolve' and 'returns' strongly imply it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: the core mapping is front-loaded, mode behaviors are separated clearly, and the limitation sentence earns its place. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool with an output schema and clear mode logic, this description is complete enough for an agent to decide when and how to call it. It covers mode selection, return behavior for both modes, and the key data-coverage limitation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic value by establishing the mutual-exclusivity relationship between paragraph and quote, explaining the result each produces, and noting the ¶-marker constraint that affects the paragraph parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Resolve a pinpoint' and immediately specifies the two directional mappings: paragraph number to text, or quote to paragraph. This precise verb+resource framing clearly distinguishes it from sibling lookups like get_opinion_text or verify_quotation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit operational guidance: 'Provide exactly one of paragraph or quote' and explains the behavior for each mode. It also adds a concrete precondition and limitation about ¶ markers, but it does not explicitly name alternative sibling tools or state when to prefer them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what is returned (metadata, question digest, authorities, optionally text) and documents input normalization behavior for two-digit and four-digit years. It does not mention behavior for missing opinion numbers or permission requirements, but for a read-only lookup the disclosed behavior is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then details returns and normalization. Every sentence adds necessary information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a lookup tool with a rich output schema, the description covers the essential call behavior: what the tool retrieves, what it returns, the supported input number formats, and the optional text parameter. No critical missing information prevents an agent from invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value beyond the schema by explaining that '96-1' and '1996-1' resolve equivalently, which clarifies opinion_number formatting. It also aligns with include_text and text_limit by describing optional text output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and a specific resource ('ND Judicial Ethics Advisory Committee opinion'), and clarifies the lookup is by number with concrete examples. This clearly distinguishes it from sibling tools like search_jeac_opinions and lookup_opinion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this tool is for retrieving a specific opinion by its number, which implies use when the opinion number is already known. It does not explicitly mention alternatives or when not to use it, but the context is strong enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the default is the currently in-force version, explains as_of_date semantics, describes corpus restriction, and details the excerpt format including the >>>term<<< convention and fallback to citation/heading when the match is only in those fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: scope, default behavior, historical search, corpus filtering, and result excerpt semantics are all covered without filler. The primary purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value shape is already covered. The description supplies everything else needed to invoke correctly: scope, default-versus-historical behavior, corpus filter values, and excerpt marking. Remaining details like limit and query syntax are already in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mostly restates as_of_date and corpus_name information already present in the schema, adding only minor extra context like ISO format and allowed values. The excerpt-format details are output-oriented rather than parameter semantics, so no meaningful boost is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Full-text search across ND primary law (Constitution, court rules, statutes, administrative code).' It further clarifies that it searches provision text and headings, which distinguishes it from opinion-search siblings like search_opinions, search_ag_opinions, and search_jeac_opinions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when to use this tool: for full-text search of North Dakota primary law, with optional as_of_date for historical versions and corpus_name to restrict scope. It does not explicitly name alternatives or state when not to use it, but the scope is clear enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it excels: it discloses normalization rules (whitespace, curly quotes, dashes), flags word changes with a diff, and notes paragraph-marker availability. This gives an agent accurate expectations about edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then efficiently expands into the key tolerances and return behavior. Every sentence contributes meaningful, non-redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, fully-described parameters, and existing output schema, the description covers the essential behavioral boundary conditions and return semantics. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both 'citation' and 'quote'. The description adds useful behavioral context but does not add new per-parameter semantic detail, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Confirm') and resource ('quoted passage appears verbatim in a case') and adds a concrete outcome ('with pinpoint ¶'). It clearly distinguishes this from related tools like verify_citation or get_pinpoint by focusing on verbatim quotation checking and pinpoint return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need to confirm a quote's existence and locate it in a case. It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and handles it well. It discloses the authoritative source (ndconst.org), temporal scope (1889–present, ~167 amendments), returned fields, optional date filtering, and a critical caveat about pre-1996 section numbering not mapping to current citations. This is substantial transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, return contents and scope, then a necessary caveat. The key action and resource are front-loaded, and the caveat about renumbering is placed at the end where it adds nuance without obscuring the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its straightforward parameter set and rich output schema, the description covers everything needed to invoke the tool correctly: source, date range, fields returned, optional filters, and the important historical caveat. No critical behavioral or scoping information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that date_from/date_to refer to 'effective-date' filtering (not election dates or other dates) and by specifying the ISO YYYY-MM-DD format. It stops short of elaborating on limit behavior, but the schema already documents the default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List the chronology of amendments to the ND Constitution.' It then enumerates the returned fields, date range, source, and count, making the tool's purpose unmistakable. This clearly differentiates it from the opinion- and authority-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: whenever ND constitutional amendment chronology or amendment details are needed. It does not explicitly name alternatives or exclusion criteria, but the domain is distinct enough from all listed siblings that an agent can route correctly. A brief 'use for ND constitutional amendments, not court opinions' would make it fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and meets it: it states the result includes the matched authority (or authorities when ambiguous), the citing opinions sorted newest first, and the provision text when available. This discloses ordering, ambiguity handling, and a conditional output without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is front-loaded with the core purpose, then gives the most useful input examples and return behavior in a compact block. Every sentence contributes; there is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter lookup tool with a full input schema and an output schema, the description is complete: it explains the authority input formats, match behavior, ordering, and conditional extra output. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful value by listing concrete accepted formats for the authority parameter (e.g., '14-09-06.2', 'N.D.R.Crim.P. 12'). It does not add anything for the limit parameter, whose schema description is already sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action and resource: it finds opinions citing or construing an N.D.C.C. section, court rule, or constitutional provision. This distinguishes it from siblings like get_citing_opinions, which are likely case-oriented, and from generic search_opinions, without relying on the tool name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is the tool for statutory, court-rule, and constitutional authority references by giving the accepted reference forms. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description takes on full responsibility for revealing behavior. It discloses the key non-obvious behavior: references are usually descriptive prose rather than formal citations, matching is done on surrounding text, and omitted opinion_number returns unresolved prose references. This goes well beyond what the schema alone reveals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the purpose appears in the first sentence, followed by the distinguishing direction and the key usage nuance. The illustrative quote earns its place and no sentences are redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the optional parameter, the existing output schema, and the fully described call patterns (with and without opinion_number), an agent has everything needed to select and invoke the tool correctly. It even anticipates the unusual citation style that would otherwise make results confusing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining why a JEAC opinion number is often not useful ('courts rarely cite these by number'), giving an example ('2005-2'), and clarifying that omitting the parameter returns ALL committee references including unresolved prose. This is a modest but real increment over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Find') and a precise resource ('ND Supreme Court / Court of Appeals opinions') that reference a JEAC opinion or the committee, which immediately separates it from the many other citation tools. It then names the relationship as 'the inbound direction of the JEAC citation graph,' making the distinction from outbound tools (e.g., get_jeac_opinions_citing) clear enough without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational guidance: call with no opinion_number for all committee references, and provides context that courts rarely cite by number. It implies the alternative outbound direction but does not explicitly name a sibling tool as the alternative or state when not to use this tool, so it stops short of fully explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and exceeds it: it discloses point-in-time edge semantics, default current version, handling of unresolved targets (resolved=false rather than dropped), and cross-corpus scope. This is precisely the behavioral nuance an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense paragraphs that are front-loaded with the definition, then organized into outbound/inbound, point-in-time, and edge-case behavior. Every clause adds information; the parenthetical examples are illustrative, not padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what counts as a provision, both citation directions, installation-dependent resolve behavior, point-in-time semantics, defaults, and unresolved-target policy. Combined with the output schema, an agent has everything needed to call and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes each parameter, so baseline is 3; the description adds real value by binding as_of_date to in-force versions on that date and explaining how unresolved citations behave. It also clarifies the scope of citation (primary-law provisions) with concrete examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Cross-references between primary-law provisions,' then enumerates outbound/inbound directions and the source types (statute, court rule, constitutional, admin-code). This clearly distinguishes it from opinion-focused siblings like get_citing_opinions and search_opinions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong context: use it for statute/rule/constitution/admin-code cross-reference analysis, with inbound referencing across all corpora. However, it never names when-not-to-use or points to a sibling (e.g., get_citing_opinions for opinion citations), so the guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden, and it delivers: it discloses the automatic 1889<->1981 constitutional renumbering behavior, the requested_citation/returned_provision/relation/note linkage, the returned fields, and the fallback message when the corpus is not installed. This is exemplary 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into four focused paragraphs: core action, as-of-date usage, constitutional renumbering, and return contents. Each sentence contributes necessary operational detail, and the most important information is front-loaded in the first line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers all essential context: what can be looked up, how to cite, how historical versions work, how constitution renumbering is handled, what the response includes, and what happens if data is unavailable. The presence of an output schema makes this even more sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema: citation format examples, the ISO YYYY-MM-DD requirement, the historical-version semantics of as_of_date, and the constitutional renumbering special cases. It transforms generic parameter descriptions into practically usable guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Retrieve the text of a ND constitutional, statutory, court-rule, or administrative provision.' It enumerates the authority types and gives concrete citation examples, making the tool's role distinct from opinion-search and authority-history siblings. The purpose is unmistakable and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: when to use as_of_date, what happens when it is omitted, and how this supports reading a statute 'as the court applied it' in older opinions. It does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does so thoroughly: it calls itself 'Heuristic and NON-authoritative,' explains regex-based extraction and unverified foreign/federal authority, warns about nearest-cite misattribution and sentence-local treatment signals, and gives the severity ranking. This is far beyond a generic mutation/read hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every block earns its place: a front-loaded summary, a bulleted breakdown of the four checks, a severity ladder, and a caveats paragraph that prevents misuse. It is structured so an agent can skim the first sentence and drill into details as needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a composite, six-parameter tool with no annotations, the description covers purpose, customization, output severity semantics, failure modes, and alternatives. An output schema exists for return details, so the absence of a return-format description is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description raises this by explaining the offense/contract-date semantics of as_of_date and expanding on what each check-mode value actually validates. It does not add detail for max_quotes or scan_limit, but those are already described adequately in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line names a specific composite operation ('One-call cite-check of a draft opinion, memo, or brief') and enumerates the exact verifications. It also differentiates itself from the sibling detect_overruled_in_draft by noting that tool is the 'cheap treatment-only pass.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly routes treatment-only needs to detect_overruled_in_draft and tells the agent when per-authority lookup_authority calls are required instead of relying on a single as_of_date. The check list with default-all behavior also tells the agent how to narrow the call via the checks parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ndlaw MCP server](https://glama.ai/mcp/servers/jet52/ndlaw/badges/card.svg)](https://glama.ai/mcp/servers/jet52/ndlaw)

Score Badge

Copy to your README.md:

[![ndlaw MCP server](https://glama.ai/mcp/servers/jet52/ndlaw/badges/score.svg)](https://glama.ai/mcp/servers/jet52/ndlaw)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jet52/ndlaw'

If you have feedback or need assistance with the MCP directory API, please join our Discord server