Nalegalu MCP

related_cases

Read-only

List SAOS cases related to one statutory provision.

    Use after identifying a relevant provision. A related-case link is not
    proof of a legal rule: inspect the judgment with get_case before
    asserting its holding. Deterministic lookup by act address
    (e.g. WDU19740240141) and article
    key. Returns case number, court, date, relevance score when available,
    and a SAOS link per case; scored cases sort first. Newer data also
    carries citation context per case: mentions (how many times the
    article appears in the judgment text), mention_match ("exact" =
    found with a matching act marker; "ambiguous" = bare mention,
    possibly another act's article — discount it), and context (snippet
    around the mention). mentions=0 or a missing context means the link
    comes from SAOS metadata but the text scan could not confirm it —
    treat relevance as unverified rather than assuming the case is on
    point. If count is zero, it means this local provision-to-case link
    dataset has no rows; it is not an exhaustive SAOS or case-law search.
    sources counts matching local rows before cross-source deduplication
    and the display limit; read sources_note before interpreting them.

Input Schema

Name	Required	Description	Default
`limit`	No
`address`	Yes
`article_key`	Yes
`paragraph_key`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedJul 21, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false, destructiveHint=false), yet the description adds substantial behavior the annotations cannot convey: the lookup is deterministic, scored cases sort first, mentions=0/missing context means an unverified metadata link, count=0 means only this local link dataset is empty (not an exhaustive search), and sources counts pre-deduplication. This is exactly the extra context the lower bar asks for.

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?

Front-loaded with purpose and usage, then progressively detailed caveats; every clause is substantive. It runs long and grows a little dense toward the end (the sources/sources_note sentence is terse), but it avoids filler and does not bury the lede.

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?

Despite an output schema existing (so return values need not be explained), the description still adds interpretation the schema cannot: what mention_match 'exact' vs 'ambiguous' means, that mentions=0 implies unverified relevance, and how to read sources. The only omission is any guidance on the limit parameter, which is minor given the tool's focused scope.

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 0%, so the description carries the burden. It compensates partially by giving an address example (WDU19740240141) and explaining the article key semantics, but paragraph_key and limit are never mentioned, leaving half the parameters undocumented in either place.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'List SAOS cases related to one statutory provision.' It further specifies the lookup is deterministic by act address and article key, which clearly separates it from siblings like research_cases (semantic search), search_law, and get_case (fetch a single judgment).

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?

Explicitly states the trigger ('Use after identifying a relevant provision') and names get_case as the required follow-up before asserting a holding, which is strong routing guidance. It does not, however, contrast this tool against research_cases or search_law as alternatives for other case-discovery needs, so it stops short of full when/when-not coverage.

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

All Nalegalu MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.