Citation Safe Verifier
Server Details
Verifies legal citations vs primary sources: existence, quote match, proposition support.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 5 of 5 tools scored. Lowest: 3.9/5.
Each tool targets a distinct operation: citation verification on pasted text, on document URLs, batch verification, retrieving past results, and searching sanctions. No overlap in purpose.
All tool names follow a consistent verb_noun pattern with underscores (e.g., verify_citation, batch_verify_citations, search_sanctions), making the tool set predictable.
Five tools is well-scoped for citation verification: single, document, batch, retrieval, and sanctions search. No redundant or excessive tools.
Core verification workflows (single, document, batch, retrieval) are covered. A listing endpoint for all verifications is missing but not critical for typical use.
Available Tools
8 toolsbatch_verify_citationsVerify legal citations across multiple texts (batch)AInspect
Runs the same 3-layer citation verification as verify_citation across multiple texts in a single call. Each item is billed against your CitationSafe usage exactly like an individual verify_citation call — batching never bypasses your plan's monthly limit. Max 10 items per batch, 64,000 characters per item. Requires a signed-in CitationSafe account (Authorization: Bearer ) — anonymous batch calls are not supported, use verify_citation for anonymous single-text checks.
| Name | Required | Description | Default |
|---|---|---|---|
| texts | Yes | Array of texts to verify, each processed as a separate verification (max 10 items, 64,000 chars each) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal, but description adds key behavioral context: requires signed-in account, no anonymous batch calls, per-item billing. Missing return format details, but acceptable for a batch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words, front-loaded with core purpose, then billing, then requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage limits, prerequisites, and billing. Lacks return format description, but output schema is absent and sibling verify_citation likely provides that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining billing per item and that batching doesn't bypass limits, which informs usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs the same 3-layer citation verification across multiple texts in a single call, distinguishing it from the single-text sibling verify_citation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (batch of texts), billing details, character limits, and when not (anonymous single-text checks should use verify_citation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_verificationGet a past CitationSafe verification report by IDARead-onlyInspect
Retrieves a previously run CitationSafe verification (by the verificationId returned from verify_citation/verify_document, or from a citationsafe.com/v/{id} share link) and returns its full per-citation results.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Verification ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that it returns 'full per-citation results' and can accept IDs from share links, providing useful behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, annotations present, no output schema), the description is complete enough. It explains what the tool does, what it returns, and how to get the ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'id' fully with description, format, and pattern. The description adds context that the ID can come from sibling tools or a share link, enhancing meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a past verification report by ID, specifying the source of the ID (from sibling tools or share link) and that it returns full per-citation results. This distinguishes it from siblings that create verifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (when you have a verification ID) and implies alternatives (for creating, use sibling tools). It does not provide explicit exclusions but is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
is_this_case_realCheck whether a single case citation is realARead-onlyInspect
Deterministic existence check (Layer 1 only, no LLM) for one legal citation against CourtListener's primary-source database. Answers the single question "is this case real" for one citation — for multi-citation quote-checked verdicts across a whole brief, use verify_brief instead. Free tier: 5 checks/day per IP, no key required. For unlimited access, pass an API key as "Authorization: Bearer " (contact support@citationsafe.com to request one).
| Name | Required | Description | Default |
|---|---|---|---|
| citation | Yes | A single citation, e.g. "410 U.S. 113" or "Roe v. Wade, 410 U.S. 113 (1973)" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals beyond annotations that it is 'deterministic', 'no LLM', and 'Layer 1 only', adding context about its reliability and scope. It also discloses free-tier limits and authentication requirements. There is no contradiction with annotations (readOnly, non-destructive).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loading the core purpose. Every sentence earns its place: purpose, alternative tool, and usage/authentication details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers all necessary aspects: purpose, use case, alternative, limitations, and authentication. It is complete and leaves no ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the 'citation' parameter with examples. The tool description reinforces the purpose (single citation) and adds example formats, but does not add significant new semantic meaning beyond what the schema provides. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a deterministic existence check for a single legal citation against the CourtListener database. It explicitly distinguishes from the sibling tool 'verify_brief' for multi-citation cases, using specific verbs 'check' and 'existence check' tied to a single resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (single citation check) and when-not-to-use (for multi-citation verdicts, use verify_brief). It also details usage tiers (free 5/day/IP and unlimited with API key) and authentication method, offering clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_phantomsSearch known AI-hallucinated (phantom) case citationsRead-onlyInspect
Searches CitationSafe's phantom-citation registry — fabricated case names/citations that have shown up in real, sanctioned AI-hallucination incidents — by case name or the AI system that produced them. Read-only, public data. Returns an empty array (not an error) if nothing matches or the registry has no entries yet.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text match against the phantom case name or the AI system that generated it |
search_sanctionsSearch the AI-hallucination court sanctions databaseARead-onlyInspect
Searches CitationSafe's database of real court sanctions/orders arising from AI-hallucinated legal citations, by court name, party/case name keyword, or free-text keyword. Read-only, public data — same dataset backing citationsafe.com/sanctions-database.
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | Filter by court name (partial match, e.g. "S.D.N.Y.") | |
| query | No | Free-text keyword to match against the case name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint. The description reinforces that it is read-only and public, and adds context about the underlying dataset source. No hidden behaviors are omitted, though rate limits or result format are not discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first front-loads the purpose and filter options, the second adds safety and data source. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description is sufficient. It explains the data source, safety, and filtering scope completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The description rephrases the filter options without adding new semantic information beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a database of court sanctions related to AI-hallucinated citations, specifying the resource (sanctions database), verb (searches), and filters (court name, keyword). It is distinct from sibling tools that focus on citation verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is read-only and uses public data, implying it is for querying known sanctions. Although it doesn't explicitly list alternatives, the sibling tools are for different tasks (verification), so usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_briefVerify every citation in a brief or excerptRead-onlyInspect
Runs existence (Layer 1) and quote-match (Layer 2) checks — both deterministic, no LLM — on every citation found in the given text and returns one verdict per citation. The multi-citation counterpart to is_this_case_real. Proposition support (Layer 3) is not included on this free/API-key surface; sign in at citationsafe.com for full 3-layer verification via verify_citation. Free tier: 5 checks/day per IP (one verify_brief call = one check, regardless of how many citations the text contains); an API key bypasses the daily cap.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Raw text (brief excerpt, motion, memo) containing one or more legal citations |
verify_citationVerify legal citations in textAInspect
Checks every legal citation in the given text against primary sources: does the cited case exist (Layer 1, CourtListener database lookup — deterministic, no LLM), does a quoted passage appear in the source opinion (Layer 2), and — on paid CitationSafe tiers — does the case support the proposition it's cited for (Layer 3). Returns VERIFIED / UNCONFIRMED / UNCONFIRMED — OUTSIDE COVERAGE / SOURCE UNAVAILABLE per citation, never a bare true/false, with source links. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Raw text containing one or more legal citations to verify |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses Layers 1-3, determinism (no LLM), tier limitations, and that it's not legal advice. However, annotations mark readOnlyHint=false, implying possible side effects, which the description does not address, creating a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with layered explanation and output details, but slightly long. Every sentence adds value, though minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (layers, tiers, deterministic behavior) and lack of output schema, the description covers key aspects but omits details like output format or source link structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description adds no new meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool verifies legal citations against primary sources with three distinct layers, distinguishing it from siblings like get_verification or verify_document. The verb 'verifies' and resource 'legal citations' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes what the tool does but does not explicitly state when to use it over alternatives like get_verification or verify_document. No when-not or comparison guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_documentVerify legal citations in a document URLAInspect
Fetches a document (PDF, DOCX, or plain text) from a URL and runs the same 3-layer citation verification as verify_citation. Use this when you have a link to a brief rather than pasted text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the PDF, DOCX, or text document to fetch and verify |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses supported formats (PDF, DOCX, plain text) and confirms it runs the same 3-layer verification as verify_citation. Annotations already indicate open-world hint (external fetch) and non-read-only, so description adds value with format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence defines functionality and supported formats; second provides usage context. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single required parameter and no output schema, the description covers all necessary information: what, how, and when to use. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (url) with 100% schema coverage. The description doesn't add extra semantics beyond the schema's format and description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (fetches and verifies) and resource (document from URL). It distinguishes from sibling verify_citation by noting it works with a URL rather than pasted text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use: 'Use this when you have a link to a brief rather than pasted text.' This contrasts with the sibling verify_citation, offering clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!