Skip to main content
Glama

Ansvar: EU Compliance & Legal Intelligence

Validate Citation

validate_citation
Read-only

Verify a legal citation against the served corpus: confirms the cited provision exists and is retrievable, and returns its current served text so a quoted claim can be compared against what the provision says now. Use this when someone asks 'is this citation correct' or 'check whether Article 28 GDPR still says this' — answer the latter by comparing the returned text with the claim. It does NOT assert legal in-force status and does NOT consult amendment feeds; a valid verdict means the citation resolves in the corpus we serve. For a provision-level change comparison use diff. The text content is one JSON document. Its evidence_summary field carries the 'Sources used' markdown table (the audit receipt per returned row) or a labelled zero-result note. Result rows carry url/title/subtitle display fields alongside their citation when available. meta.render_contract carries the versioned evidence-curation contract.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "law": "<law>",
      "article": "<article>"
    },
    "name": "validate_citation"
  }
}

Input Schema

NameRequiredDescriptionDefault
lawYesInstrument named in the citation being checked, as a framework id ('GDPR') or the corpus's own law identifier.
articleYesArticle or section number named in the citation, such as '28'.
jurisdictionNoISO-2 code of the jurisdiction the citation belongs to, such as EU or SE. Omit only when the instrument is unambiguous across the fleet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / article / description
      Added value: +"Article or section number named in the citation, such as '28'."
    • addedInput schema / properties / jurisdiction / description
      Added value: +"ISO-2 code of the jurisdiction the citation belongs to, such as EU or SE. Omit only when the instrument is unambiguous across the fleet."
    • addedInput schema / properties / law / description
      Added value: +"Instrument named in the citation being checked, as a framework id ('GDPR') or the corpus's own law identifier."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint=false, but the description adds the crucial semantic caveat that a valid verdict means only corpus resolution, not legal validity — a distinction an agent would otherwise get wrong. It also documents the response shape (single JSON document, evidence_summary as audit receipt or zero-result note, url/title/subtitle display fields, meta.render_contract version).

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?

Purpose and trigger cases are front-loaded in the first two sentences, and every subsequent clause carries real information. The evidence_summary and render_contract details are denser than strictly necessary, but they substitute for a missing output 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?

With no output schema, the description fully carries the burden: it explains the returned text, evidence_summary contents, available display fields, and the versioned render contract, plus scope limits on what 'valid' means. Nothing an agent needs to interpret the result 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 law/article/jurisdiction are already well documented in the schema. The description adds no parameter-level guidance beyond that (e.g. it doesn't say how 'law' identifiers are matched or what happens on cross-fleet ambiguity), so 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?

States a specific verb and resource — verify a legal citation against the served corpus — and defines exactly what a positive verdict means (the provision exists and is retrievable, and its served text is returned for comparison). It distinguishes itself from siblings by naming diff as the tool for provision-level change comparison.

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?

Gives concrete trigger phrasing ('is this citation correct', 'check whether Article 28 GDPR still says this') plus the mechanics for answering — compare returned text with the claim. It also names explicit exclusions (no legal in-force determination, no amendment feeds) and routes change-comparison queries to diff.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.