mcpbeat

Experimental Legal Grounding MCP Server

io.github.tokenfix/legal-grounding
not responding

Experimental Legal Grounding is listed as active in the registry but did not answer our last check. It exposes 3 tools.

Experimental GDPR grounding: rules, preconditions, exceptions, exact quotes, and citation checks.

Uptime history 43 hours of history · worst hour 0%
43 hours agonow
0.0%
Uptime 24h
0 of 91 checks
3
Tools
read from the server
113 ms
Response time
average over 24h
open, no key
Access
streamable-http

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 3 min ago.

run in your terminal
claude mcp add legal-grounding --transport http https://legal-grounding-199120533535.europe-north2.run.app/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "legal-grounding": {
      "url": "https://legal-grounding-199120533535.europe-north2.run.app/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.legal-grounding]
url = "https://legal-grounding-199120533535.europe-north2.run.app/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "legal-grounding": {
      "url": "https://legal-grounding-199120533535.europe-north2.run.app/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "legal-grounding": {
      "url": "https://legal-grounding-199120533535.europe-north2.run.app/mcp"
    }
  }
}

Available tools 3

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

catalog
get_catalog
Vocabulary map of the corpus: obligation clusters (with support status), regulation terms, everyday-phrase bridges, concept bridges (recurring legal phrases the corpus uses but never defines — "public interest", "high risk" — routed to their operative clusters), and corpus boundaries (topics governed by law OUTSIDE this corpus, e.g. cookie consent under ePrivacy). Call this first to translate a user's question into cluster/term selectors, and to learn where honest answers require referral rather than assertion.
retrieve
retrieve_evidence
Evidence packets for legal topics. Selectors (union): cluster ids and/or term keys from get_catalog, and/or free_text (deterministic lexical+bridge matching only — no semantic search). Each packet returns primary rules PLUS their preconditions and exceptions with byte-exact quotes and stable rule ids. Every served rule includes its enumerated items and conditions with citable ids. Explicit term selectors return their definitions in packets or term_definitions. related_clusters names approved adjacent topics and explains each link. Mandatory packet content is never truncated. Use every part: presenting a duty without its packet's exceptions or preconditions will fail validate_claims. corpus_coverage tells you when the governing law is outside the corpus — qualify or refer, don't guess. If free_text matches nothing exactly, the response carries routing_candidates: clusters whose corpus vocabulary (section headings, cluster names, concept labels) overlaps your text. Inspect matched_vocabulary, choose semantically, and re-request that cluster explicitly — the service names candidates, it never guesses for you. Measured host loop (raises answerable coverage 25%→75%): if no packet returns, ask the user ONE intent question, then re-request with BOTH the chosen cluster AND the clarified free_text — combined selectors surface supplemental rules (e.g. Article 6(4) compatibility) that either selector alone misses. When clusters and free_text are combined, the text refines only within the explicit clusters and never adds another cluster. Before answering, check the substantive rule you need is actually in the response; if the packet is unavailable or incomplete, say so and refer — do not fill the gap from model memory.
validate
validate_claims
Verify a drafted answer's legal citations before presenting it. Each claim: {claim_id, assertion, cluster_id, claim_type, claim_concept, citations: [{rule_id, quote}], propositions: [{duty_rule_ids, exception_rule_ids}]}. ALWAYS supply cluster_id for legal propositions — v0.3.8: WITHOUT it a claim cannot be grounded at all (verdict unclustered_claim), because membership, packet preconditions, required conditions and corpus-boundary warnings are all cluster-scoped. claim_type "exception_scope" is HOST-DECLARED, never inferred: use it only for a claim about an exception itself; it is valid only when every citation is exception-typed (else the claim receives invalid_claim), it exempts the exception-only/unanchored/precondition checks, and it is flagged in the result as host_declared_exception_scope. Any skipped ids are listed in exempted_by_declaration. Consumers MUST inspect that flag and treat a grounded declared claim as resting on the host's own declaration, not on ordinary grounding. claim_concept (optional) requires a concept-labeled cluster. concept_check lists matched, mismatched, and unlabelled citations; use all_citations_match as the strict signal. Verdicts (first match): invalid_claim (this claim violated a claim-scoped declaration rule; sibling claims still get results), unknown_reference (fabricated id), misquoted (canonical quote returned — fix and re-validate), wrong_provision (citation off-topic for the cluster), wrong_concept (you declared claim_concept and no cited labeled rule carries it — recheck your citations or your concept), outside_corpus (abstain/refer to the named external law), qualified_by_exception / qualified_by_precondition (add the returned exception/precondition citations and re-validate, or qualify your prose), exception_only_citations (ALL citations are carve-out rules and claim_type is not exception_scope; they cannot support an affirmative claim), unanchored_exception_citations (an exception's known target is not cited), unclustered_claim (no cluster_id — re-submit naming the claim's topic), mispaired_exception (a declared exception does not target its declared duty), unbound_propositions (strict linkage was requested for an ambiguous citation set without complete proposition declarations), citation_graph_consistent, unsupported. An exception's own conditions must be cited with it. Every cited condition requires its own parent rule. Every cited item of a non-exception rule requires its parent rule; exception items remain independently citable. This includes curated ids standing for items: an Article 6(1) basis requires the Article 6(1) chapeau cited with it. Conditions listed in required_conditions apply only to their named rule. If a submitted id is normalized, citation_checks returns the normalized rule_id and preserves the submitted id in cited_as. Known exception targets apply even when cluster_id is omitted. Every result also carries citation_status (valid/invalid/none) and semantic_status (always not_evaluated). IMPORTANT: citation_graph_consistent certifies that your CITATION SET contains valid relationships — it never certifies that your prose describes those relationships correctly, and it cannot detect prose that cross-pairs a cited exception with the wrong cited duty (round-11 "camouflage" finding: the same citation set can carry a true and a false sentence). Before presenting any claim involving an exception, COMPARE the reconciliation field's exception->limits edges against what your prose actually asserts; if your sentence pairs an exception with a duty that reconciliation does not list for it, your sentence is wrong even though the verdict is citation_graph_consistent. Prefer one claim object per duty-exception proposition over compound claims. Set strict_linkage true when every ambiguous exception-to-duty relationship must be declared and mechanically verified.

Endpoints

URLTransportStateLatencyChecked
https://legal-grounding-199120533535.europe-north2.run.app/mcp streamable-http answering 113 ms 3 min ago

Experimental Legal Grounding — questions

Answers built from our own checks of this server.

What can Experimental Legal Grounding do?
It exposes 3 tools, read directly from the server on our last check. Among them: get_catalog, retrieve_evidence, validate_claims. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is Experimental Legal Grounding working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 0 of 91 checks got a reply (0.0%), average response time 113 ms. The bar chart above shows every period we have measured.
The registry lists Experimental Legal Grounding as active — why does it not respond?
The official MCP registry stores what the author submitted; it does not verify that the server still runs. We check the endpoint ourselves, and this one does not answer. Catalogues that copy the registry without checking will show it as working.
How do I connect Experimental Legal Grounding?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does Experimental Legal Grounding need an API key?
No. Experimental Legal Grounding completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 3 of them are readable on this page. This is what we observed, not what the docs claim.