Skip to main content
Glama

Ansvar: EU Compliance & Legal Intelligence

Verify Citations

verify_citations
Read-only

Verify submitted legal citations against what this gateway actually serves, so a report can record which of its citations are established evidence and which are not. For each subject you supply a reference (and the source_id the row's citation.lookup hint carried, plus the quotation your text relies on), the gateway re-retrieves that provision under YOUR scope through the source-pinned exact lookup, checks the PRODUCER-declared identity of the row it got back against the reference you asked for, and only then compares your quotation with the retrieved body. A displayed reference is never used to decide which row answers a subject. Verdicts per subject: quote_checked (reference resolved and the quotation is in the body), reference_resolved (reference resolved, no quotation was submitted), quote_mismatch, no_quotation_submitted (a quote-bearing subject whose quotation was empty — a refusal, NOT a mismatch), identity_mismatch (the row's producer identity names a different provision), identity_absent, reference_unparseable, not_served, withheld and unavailable. Coverage is advertised, never assumed: producer identity exists TODAY ONLY on the source-pinned exact lookup paths, so a subject with no source_id, or one on a corpus they do not cover, returns identity_absent rather than passing. Entity subjects are the second such path: when source_id names a controls, framework, standards or threat-technique catalog, reference is that row's entity id (a control, clause or technique id such as AC-4(5), A.5.1 or T1059) and the gateway re-retrieves it from that catalog by id — the lane follows the source, not the shape of the string. Court decisions and preparatory works are the third: when source_id names a decision or preparatory-works corpus, reference is that row's single opaque address (an ECLI, a neutral citation, the corpus's own case id, a proposition number) and the gateway re-retrieves it FROM THAT CORPUS — never from another decision corpus of the same jurisdiction — and additionally requires the producer's own court, case number and decision date before a decision verifies. Both lanes compare references byte for byte: these id spaces carry no equivalent spellings. For those two lanes source_id is the ROUTED CORPUS ID the row came from (for example dutch-court-decisions or swedish-preparatory-works), because a decision hint carries the reference and the jurisdiction, not the corpus. It is not the citation's mcp_server, which is that corpus's display name and resolves to no routed id; the response's coverage block lists the corpus ids each of these lanes covers today. Regulatory updates are the fourth: when source_id names the regulatory-update service, reference is the record id that service emitted and the gateway re-fetches that record from it, byte for byte. Because a regulatory update is a live feed rather than a built corpus, such a verdict also carries a freshness block — the record's own publication and observation dates, the feed it came from and that service's own reported data age — and a verdict this gateway cannot date refuses (identity_absent) instead of establishing. A quotation on this lane is compared with the publisher's own title text, which is the only verbatim text the record carries: the service serves no summary and no provision body. CVE records are the fifth: when source_id names the CVE service, reference is the CVE id (CVE-2021-44228) and the gateway re-fetches that record from it, byte for byte, comparing a quotation with the publisher's own description. Such a verdict carries a freshness block too — the record's publication and modification dates, and the declared sync state, age and interval of the feed it was served from — and because that service publishes its own freshness contract, a feed it reports as no longer current, or one older than the sync interval it declares for itself, answers identity_absent with reason cve_pin_feed_stale instead of establishing anything — and so does a miss from such a feed, because an absence read from a stale mirror is not an absence. A KEV listing or an EPSS score is NOT verified on that lane: they are other feeds' assertions about the CVE rather than publisher text of it, and a quotation of one reads quote_mismatch. Their two feeds' ages are stated on the verdict but do not refuse it — the one deliberate exception to the stale-feed rule, scoped to feeds the checked text does not come from. The response's coverage block lists which corpora each lane covers today; a subject on a corpus a lane does not yet cover answers identity_absent. First-party doc:// document pinpoints are not verified here (reference_unparseable). withheld means licensing or tier suppression and never means the law does not exist; not_served means no corpus in your scope serves that reference. No verdict asserts legal in-force status, currency, pinpoint correctness, or that the provision supports your conclusion. Limits: 60 subjects a call, one lookup a subject under a shared 25-second budget with concurrency 6; on exhaustion the response is marked bounded and the unreached subjects are unavailable, never verified and never reported as absent law. Lookups run under your own tier and entitlements and count against your normal lookup quota. With attest=true, premium and above receive signed evidence attestations for permitting subjects: integrity and provenance, never legal validity; free and solo keep ordinary verdicts with attestation_refused=tier.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
attestNoRequest signed evidence attestations (premium and above); defaults to false.
subjectsYesArray of subject objects, each checked independently and echoed back in this order. Keys: subject_id (required, your own opaque id, unique within the call, returned verbatim); reference (required, the canonical reference to verify, e.g. the canonical_ref a search row's citation.lookup hint carried); source_id (optional but needed for a verifiable result — the routed corpus id from that same lookup hint; without it the lookup is unpinned, carries no producer identity and the verdict is identity_absent); quotation (optional — supply the exact text your report relies on and it is compared with the retrieved body; omit the key entirely for a reference-only claim. Supplying it empty declares a quote-bearing claim with nothing to compare and returns no_quotation_submitted. A quotation shorter than 25 characters (6 for Chinese, Japanese or Korean text), elision marks excluded, is too short to be evidence and returns no_quotation_submitted too, unless it is the provision's whole text; quote a full clause. Maximum 60 subjects a call; a quotation is capped at 16384 UTF-8 bytes. Unknown keys are refused, not ignored.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / attest
      Added value: +{
      +  "default": false,
      +  "description": "Request signed evidence attestations (premium and above); defaults to false.",
      +  "title": "Attest",
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint, openWorldHint, and destructiveHint annotations, the description explains source-pinned lookup, producer identity checks, byte-for-byte comparison, verdict semantics, stale-feed refusal behavior, attestation provisions, and tier restrictions. This gives an agent a rich, accurate picture of what will and will not happen.

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 very long, but the density is justified by five distinct lookup lanes, many verdicts, freshness rules, and tier semantics. It is front-loaded with purpose and contains little filler, though the single unbroken block of text makes scanning harder than a structured format would.

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?

Everything an agent needs to invoke this tool correctly is present: verdict vocabulary, lane routing rules, coverage and freshness behaviors, authentication and tier requirements, quotas and concurrency, and explicit boundaries. With an output schema also available, no critical operational detail is missing.

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?

Schema coverage is complete, but the description adds essential meaning: source_id must be the routed corpus id rather than the citation's mcp_server, reference semantics differ by lane, empty quotation is a refusal rather than a mismatch, and quotation length rules are elaborated. This materially improves correct invocation beyond the schema alone.

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 opening sentence states the tool 'Verify submitted legal citations against what this gateway actually serves' with a clear resource and goal, and the verdict list makes its behavior concrete. However, it does not explicitly distinguish itself from the sibling tool validate_citation, which likely overlaps in purpose, so it misses the top tier for sibling differentiation.

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 provides clear context for when the tool applies, including limits, quota effects, tier-gated attestation, and explicit exclusions such as 'First-party doc:// document pinpoints are not verified here' and KEV/EPSS quotations not being verified on the CVE lane. It does not name alternative sibling tools or provide direct 'use X instead' guidance, 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.