What can you do with this server?

A deterministic, embedding-geometry-based hallucination detection server that checks whether LLM responses are grounded in their source material — no second LLM involved, so the same inputs always produce the same scores. * groundlens_check — Auto-selects the best method (SGI if source context is provided, DGI otherwise) to evaluate grounding, returning a comprehensive assessment. * groundlens_sgi (Semantic Grounding Index) — Measures whether an LLM response actually engaged with a provided source document by comparing embedding distances between the response, question, and context. Ideal for RAG pipelines, document Q&A, and summarization audits. * groundlens_dgi (Directional Grounding Index) — Detects hallucination patterns without a source document by checking whether the question-to-response displacement aligns with patterns typical of grounded answers. Suited for open-ended chat and general Q&A. All tools return structured JSON with a plain-language verdict (e.g., "Supported by the document"), a numeric score, a risk level (ok / review / risk), and escalate/handoff fields that explicitly note what the check cannot verify — namely, that a passing score does not guarantee factual correctness.

Which integrations are available for this server?

Integrates with Windsurf (by Codeium) to provide hallucination detection capabilities, allowing users to check the factual grounding of AI responses.

How do I use groundlens-deprecated?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@groundlens-deprecated Check this response for hallucinations." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

groundlens-mcp

Moved. The GroundLens MCP server ships inside the groundlens package. This repository is archived, and the groundlens-mcp package on PyPI installs nothing but a message that says so.

pip install "groundlens[mcp]"
groundlens-mcp

{ "mcpServers": { "groundlens": { "command": "groundlens-mcp" } } }

With nothing installed, through uv:

{
  "mcpServers": {
    "groundlens": {
      "command": "uvx",
      "args": ["--from", "groundlens[mcp]", "groundlens-mcp"]
    }
  }
}

Keep --from "groundlens[mcp]": a bare uvx groundlens-mcp installs this old package instead of the server.

The server has three tools: verify_answer, verify_run and verify_records. GroundLens is guardrails for LLM answers: it checks an LLM answer against its sources without a model, decides PASS, REVIEW or FAIL under your policy, and keeps a signed record.

Source: https://github.com/groundlens-dev/groundlens
Site: https://groundlens.dev
MCP registry: io.github.groundlens-dev/groundlens

Apache-2.0.

Available Tools

3 tools

groundlens_checkA

Read-onlyIdempotent

Check whether an LLM response was drawn from its source. Grounding, not truth.

This is the main tool. It automatically selects the right method:

If context is provided: uses SGI (Semantic Grounding Index) to check whether the response actually engaged the source material.
If no context: uses DGI (Directional Grounding Index), a coarse signal with a known ceiling.

Both are deterministic — same inputs always produce the same score. No model in the scoring path. Scoring is embedding geometry.

IMPORTANT — how to report the result. A passing check means the response ENGAGED ITS SOURCE. It does NOT mean the facts are correct. A plausible wrong fact stated in the right frame (right topic, right terminology, one wrong number or date) will pass. Do not tell the user a passing check means the answer is "verified", "accurate" or "not hallucinated". Always surface the handoff field, and when escalate is true, say so: the case needs a second stage (an entailment check, a lookup against the source, or a judge).

Args: params (CheckInput): The question, response, and optional context.

Returns: str: JSON with a plain-language CHECK (Supported / Partly supported / Not supported by the document, or Looks grounded / Partly grounded / Not grounded), score, level, method, message, escalate, handoff, and the raw components.

Examples: - "Did this ChatGPT answer actually come from our policy document?" → provide question + response + the policy document as context - "Did this answer engage its source at all?" → provide question + response (no context needed)

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Disclosures beyond annotations include deterministic nature, no model in scoring path, and limitation that plausible wrong facts can pass. No contradiction with annotations (readOnlyHint, idempotentHint, etc.).

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 well-structured with sections, examples, and warnings. It is slightly lengthy but every sentence adds value. Front-loaded with core purpose.

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?

Given the complexity (two methods, output with multiple fields) and available annotations/schema, the description provides complete guidance on behavior, limitations, and expected output. No output schema provided but output fields are explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema descriptions cover individual fields (question, response, context), the description adds meaning about parameter behavior (auto-mode selection based on context presence) and output interpretation. The 0% schema coverage for the top-level params property is compensated by rich tool description.

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?

The description explicitly states the tool checks grounding against a source and distinguishes itself from siblings (groundlens_dgi, groundlens_sgi) by being the main tool that auto-selects method. It clearly identifies the verbs 'check' and 'drawn from'.

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?

Provides explicit guidance on when to use context (SGI) vs without (DGI), and warns about interpretation of results. Includes examples of appropriate use cases and alternative tools.

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

groundlens_dgiA

Read-onlyIdempotent

Coarse context-free grounding signal, for when no source is available (DGI).

DGI (Directional Grounding Index) compares the question-to-response displacement against the direction typical of answers written from a source. No context is needed, so it works for open-ended chat and general Q&A.

IMPORTANT: this is the weakest signal here and it has a measured ceiling. With authorship held constant it reaches AUROC 0.606, and the ceiling of the entire embedding-similarity class is about 0.68. It is a ranking signal for triage, not a detector, and it is not a risk verdict. Prefer groundlens_sgi whenever a source is available. Never report a DGI score as evidence that an answer is true or false.

Args: params (DGIInput): The question and LLM response.

Returns: str: JSON with a plain-language CHECK, the DGI score, the magnitude, escalate and handoff.

Examples: - Ranking a batch of chat answers so a reviewer starts with the worst - Screening outputs when no source document exists

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Discloses limitations: 'weakest signal', measured AUROC ceiling 0.606, ranking signal, not detector. Adds behavioral context beyond annotations (readOnlyHint, idempotentHint).

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?

Well-structured with sections, front-loaded summary, and each sentence adds value. Slightly verbose but efficient overall.

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?

Covers use cases, limitations, and return format. Output schema exists, so return details are optional. Given tool complexity, description is complete and appropriate.

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?

Description mentions 'params (DGIInput): The question and LLM response' but adds little beyond schema. Schema descriptions already cover parameters, so no major gap, but description doesn't compensate for low schema_description_coverage (0%).

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?

The description clearly states the tool's purpose: 'coarse context-free grounding signal' for when no source is available, and distinguishes it from sibling tools by recommending groundlens_sgi when a source exists.

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?

Explicitly states when to use (no source available), when not to use ('Never report as evidence'), and suggests alternative (groundlens_sgi).

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

groundlens_sgiA

Read-onlyIdempotent

Check whether an LLM response engaged a source document (SGI). Provenance, not truth.

SGI (Semantic Grounding Index) measures whether the response engaged with the provided context or stayed anchored to the question. This is the method to use for RAG pipeline verification — did the model actually use the retrieved documents?

The score is a ratio: dist(response, question) / dist(response, context). A high ratio means the response moved toward the context. A low ratio means it stayed near the question (possibly ignored the context).

IMPORTANT: this measures PROVENANCE. An answer that borrows the source's vocabulary and structure but changes one figure will pass. Surface the handoff field and escalate fact-level verification to a second stage.

Args: params (SGIInput): The question, source context, and LLM response.

Returns: str: JSON with a plain-language CHECK, the SGI score, and the two distances.

Examples: - Verifying a RAG chatbot used the retrieved documents - Checking if a summary is faithful to the source text - Auditing whether context was ignored in a customer support bot

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior5/5

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

The description goes beyond annotations by disclosing a critical behavioral trait: the tool measures provenance and can pass answers that borrow vocabulary but change facts. It advises surfacing the 'handoff' field and escalating fact checks, adding valuable context beyond the readOnlyHint, idempotentHint, and destructiveHint annotations.

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 well-structured with a clear purpose statement upfront, followed by explanation of SGI, usage importance, and examples. It is slightly verbose (e.g., the ratio formula could be concise), but overall efficient and front-loaded.

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?

Given the tool's simplicity (3 inputs, clear output schema present), the description fully covers its purpose, usage, return value (JSON with CHECK, score, distances), and example use cases. No gaps are evident.

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?

The input schema already provides detailed descriptions for all three parameters (question, context, response). The description repeats this info with minimal added value ('Args: params (SGIInput): ...'), so it does not significantly enhance parameter understanding beyond the schema.

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 description clearly states the tool checks whether an LLM response engaged a source document, with emphasis on provenance. However, it does not explicitly distinguish from sibling tools (groundlens_check, groundlens_dgi), though it implies a unique use case for RAG pipeline verification.

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 guidance on when to use this tool ('for RAG pipeline verification') and hints at when not to (escalate fact-level verification elsewhere). However, it does not explicitly name alternative tools, missing an opportunity to differentiate from siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updatev2026.7.13Jul 15, 2026

Changedgroundlens_check2 fields changed

changedInput schema / $defs / CheckInput / description

Previous value: -"Input for the main hallucination check tool."New value: +"Input for the main grounding check tool."

changedInput schema / $defs / CheckInput / properties / response / description

Previous value: -"The LLM's response to evaluate for hallucination"New value: +"The LLM's response to check for grounding (was it drawn from the source?)"

3 tool updatesv0.1.0Jul 8, 2026
- First observedgroundlens_check
- First observedgroundlens_dgi
- First observedgroundlens_sgi

Deploy Server

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

TDQS

A4.3/5.0

Scored 2026-09-09 18:40 across 3 tools

Disambiguation3/5

groundlens_check is a wrapper that automatically dispatches to the same SGI and DGI methods exposed as separate tools, so the purposes overlap by design. The descriptions help clarify context vs. no-context usage, but an agent could still be unsure whether to call the main check tool or the method-specific one.

Naming Consistency4/5

All tools share the groundlens_ prefix and use lowercase snake_case, which is readable and predictable. The pattern is slightly inconsistent because check is a verb while sgi and dgi are method acronyms, but this is a minor deviation rather than chaotic naming.

Tool Count5/5

Three tools is a well-scoped count for a focused grounding-check server. The auto-selecting dispatcher plus the two explicit methods is compact and each tool has a documented role.

Completeness5/5

The set covers the full grounding-check lifecycle: automatic selection, context-based SGI, and context-free DGI. Fact-level verification is explicitly out of scope and delegated via handoff, so there is no obvious missing tool for the server's stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Rosey – Quality verification for human and AI contentOAuth
com.getrosey
Fact-checks generated content against your sources of truth showing what to trust, change, & verify.
Testing & QA Tools RAG Systems AI & Machine Learning
1
Citation Verification A
io.github.guptaprakhariitr
Real-time fact-check, citation verification, and source-freshness for AI agents.
Search RAG Systems
321
Brainiall NLP A
com.brainiall
Sentiment, toxicity, entity extraction, PII, translation, summary, QA, fraud scoring, safety audit.
AI & Machine Learning Text Summarization Language Translation
221
PortMemOAuth
com.portmem
Check AI-written drafts against your source documents, with the passage behind every verdict.
AI & Machine Learning Documentation Access Research & Data
1

Related MCP Servers

Kluster.ai Verify MCPofficial
Search RAG Systems Research & Data
kluster-ai
A
license
Not graded
quality
Not graded
maintenance
Enables fact-checking of AI responses against reliable sources and validation of responses against document content to ensure accuracy and reliability.
Updated a year ago (2025-07-04 15:08 UTC)
-
Arkheia Hallucinationofficial
AI & Machine Learning Testing & QA Tools Monitoring
arkheiaai
A
license
Not graded
quality
D
maintenance
Detect fabrication and hallucination in any LLM output. Score responses from GPT-4o, Claude, Gemini, Llama and 30+ models. Free tier included.
Updated 19 days ago (2026-09-30 09:10 UTC)
2
MIT
Correctover MCP Serverofficial
AI & Machine Learning Monitoring Testing & QA Tools
Correctover
A
license
A
quality
A
maintenance
Verifies AI outputs in real-time across 6 dimensions, with automatic retry and failover to ensure correct, complete, and reliable LLM responses before they reach the user's editor.
Updated 3 months ago (2026-07-27 05:12 UTC)
5
164 npm
1
Apache 2.0
groundcheck
RAG Systems AI & Machine Learning
offquestxo
A
license
A
quality
D
maintenance
An MCP server that lets any AI agent evaluate RAG outputs -- faithfulness scoring, hallucination detection, and retrieval quality metrics -- with zero API keys, using MCP sampling.
Updated 3 months ago (2026-07-22 18:55 UTC)
6
MIT

groundlens-mcp

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Kluster.ai Verify MCPofficial

Arkheia Hallucinationofficial

Correctover MCP Serverofficial

groundcheck