Skip to main content
Glama
groundlens-dev

groundlens

Official
by groundlens-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
verify_answerA

Check an answer against the passages it was written from, before you send it.

    Every figure must be in the passages or follow from figures that are; no model
    is used. Returns PASS, REVIEW or FAIL with the reasons, and the signed record.

    sources: (id, text) pairs, {"id","text","provenance"} dicts, or bare strings.
    policy: a built-in name (e.g. "eu_ai_act_high_risk_v1"), a path, or YAML.
    scope: what the request is about, e.g. {"entity": "UPS"}; a figure taken
    from a source whose provenance is another entity fails.
    risk_class: the request's risk class, when the policy defines them.
    Returns the decision (PASS/REVIEW/FAIL), the evidence, the regulatory
    mapping and the record with its content hash.
verify_runA

Verify an MCP execution trace under an execution policy and return the run record.

    trace: the MCP session as JSON-RPC messages (JSON Lines).
    policy: the execution policy, as YAML/JSON text or a path.
    Returns the gate (ALLOW/REVIEW/DENY), any breaches, and the signed run record.
verify_recordsA

Verify a log of records offline: every hash, every link, every signature.

    records: the JSON Lines text of an answer-record or run-record log.
    Returns {"ok", "verified", "kind"}; fails if any record or link was altered.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation4/5

Each tool takes a clearly different input shape: a JSON-RPC session trace, answer passages, and a JSON Lines record log. There is mild overlap because verify_records can validate run records that verify_run also produces/validates, which could cause a brief hesitation, but the described inputs keep them separable.

Naming Consistency5/5

All three tools follow a strict verb_noun pattern (verify_run, verify_answer, verify_records), with the same verb used consistently for the same conceptual action.

Tool Count4/5

Three tools is on the lean side but each covers a distinct verification target (run trace, answer grounding, record log), so nothing feels redundant or padded.

Completeness4/5

The core verification lifecycle (verify runs, verify answers, verify logs offline) is covered, and records are produced by the verify calls themselves. A minor gap is that no tool enumerates available built-in policies (e.g. 'eu_ai_act_high_risk_v1'), though agents can work around this by passing policy text or a path.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources