Spectral — verified-knowledge oracle
Server Details
Cross-check a factual claim against a verified knowledge graph before you assert it. Never guesses.
- 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.3/5 across 3 of 3 tools scored. Lowest: 3.7/5.
Each tool has a distinct purpose: cross_check verifies a single claim, verify_claims batches multiple, and lookup_facts retrieves all facts about an entity. Despite cross_check's verbose description, the boundaries are clear.
All tools follow a consistent verb_noun pattern using underscores: cross_check, lookup_facts, verify_claims. No mixing of conventions.
With 3 tools, the server is on the minimal side but still covers the essential operations for a knowledge oracle: single claim check, batch check, and entity fact retrieval. Slightly more tools could expand functionality, but current count is reasonable.
The toolset covers core verification tasks but lacks entity search or discovery capabilities. Users cannot find entities by name or explore available relations, which limits completeness for a 'knowledge oracle'.
Available Tools
3 toolscross_checkAInspect
Cross-check ONE factual claim against a verified knowledge graph BEFORE you assert it — the "am I sure?" instant, just before a discrete fact leaves your mouth. Prefer this over stating such a fact from memory. Its whole job is to catch your own hallucination before it reaches the user: every call either CONFIRMS your claim with a citable source, CORRECTS it with the real value + source, or honestly ABSTAINS — it NEVER hands back a guessed value, so a call can only help or stay neutral. Honest abstention (UNVERIFIED over a confident guess) is the point, not a failure.
INVOKE only when BOTH gates hold: (1) the claim is a lookup-able, atomic subject–relation–object attribute of a real, named entity a public knowledge graph would hold — a who/what/when/where property such as date of birth, place of birth, author, capital, founder, publication date, director, spouse, population — keyed on a real person, place, creative work, organization, event, or species — and, at its highest-confidence tiers, the graph also carries exact values such as a physical constant (CODATA/NIST) or a machine-checked theorem (Metamath), which it verifies best of all; AND (2) being wrong would matter — you are about to state it, cite it, or act on it. Rule of thumb: if you'd attach a citation to it and an error would be consequential, check it here first. One call per uncertain fact, at the moment of doubt — not a per-token or per-sentence reflex.
INPUTS — subject: entity name ("Marie Curie") or Wikidata QID ("Q7186"), required; relation: the property as free text ("place of birth"), optional; value: your claimed value ("Warsaw"), optional — omit to just fetch the verified value(s); hint: a short disambiguator ("physicist", "1997 film") when the name is shared.
RETURNS {verdict, summary (one-line, ready to quote), confidence (high|medium|none — a coarse tier-derived signal, NOT a probability), subject_id (QID), verified_values, evidence[{rel,value,tier,source}], sources, note}. Verdicts:
- SUPPORTED — a verified fact matches; safe to state and cite. Matching is normalized/substring-tolerant, so "exact" means "never guesses," NOT literal string equality — read evidence[].value (or verified_values, present only when you passed NO value) to confirm exact wording.
- REFUTED — fires ONLY when the relation has exactly ONE verified value and it differs; verified_values holds the real value + source, so correct yourself and cite it.
- NOT_FOUND — the relation has several verified values and yours isn't among them; high-cardinality relations may be incomplete, so weight this softly — it is not a refutation.
- UNVERIFIED — not in the verified set, or the subject didn't resolve: it ABSTAINS rather than guess. Read this as "cannot confirm / unknown," NOT "false" — hedge, omit, or fall back to web_search; do not assert. It may queue the gap to learn for next time. This is the trust anchor: a first-class answer, never an error to retry-spam.
- AMBIGUOUS — the name maps to several entities (candidates returned); re-call with a hint or a QID.
- FACTS — a subject-only call returns that entity's verified facts.
Data is Wikidata-scale plus exact-oracle and machine-proven tiers, each fact carrying a source + tier badge; it is sourced, not hand-audited. Prefer cross_check over web_search AND over memory for stable, checkable encyclopedic attributes; use web_search INSTEAD for anything time-sensitive, recent, priced, prose/explanatory, multi-hop, subjective, or non-encyclopedic — and when this returns UNVERIFIED, fall back to web_search rather than asserting. A batch companion, verify_claims, takes a list of {subject, relation, value, hint} to sanity-check a whole draft in one pass. Backend defaults to http://localhost:8791 (override with SPECTRAL_URL); the hosted remote is currently offline — run against a local instance, or after relight.
DON'T INVOKE: never as a per-token/per-sentence reflex; never for opinions, evaluations, advice, or forecasts; never for anything you can DERIVE rather than look up (arithmetic, unit/date math, logic, deduction); never for code, API, or library behavior; never for meta-claims about your own reasoning/plan, the task, the user, or local files; never for entities too fictional, private, or obscure to sit in a public graph; never for low-stakes throwaway asides where an error is harmless; and never for time-sensitive, recent, priced, prose/synthesis, or multi-hop questions (those are web_search's job — this answers "is THIS attribute of THIS entity correct?", not "what's happening" or "tell me about"). Do not read UNVERIFIED as a refutation or retry-spam it; do not treat a lenient SUPPORTED as literal string equality without checking verified_values.
| Name | Required | Description | Default |
|---|---|---|---|
| hint | No | ||
| value | No | ||
| subject | Yes | ||
| relation | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It details behavioral traits: never guesses, honest abstention, return verdicts (SUPPORTED, REFUTED, etc.), matching rules, and backend dependency. It also notes the hosted remote is offline.
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 very long and contains redundant explanations (e.g., multiple mentions of not guessing). While comprehensive, it is not concise; it could be streamlined to improve readability without losing critical information.
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 and lack of output schema, the description provides complete context: input semantics, return fields, verdict interpretations, and operational constraints like when to invoke and when to avoid.
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 0%, but the description fully explains each parameter: subject (required, name or QID), relation (optional free text), value (optional claimed value), hint (disambiguator). Examples are given for each, and optional behaviors are described.
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's purpose: to cross-check a factual claim against a verified knowledge graph before asserting it. It differentiates from sibling tools like verify_claims and lookup_facts by explicitly mentioning them and distinguishing their use cases.
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?
Usage guidelines are explicit: prefer over memory and web_search for stable encyclopedic attributes, use web_search for time-sensitive or non-encyclopedic queries. It provides a comprehensive 'DON'T INVOKE' list and specifies when to fall back to web_search (e.g., when UNVERIFIED).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_factsAInspect
Get the verified facts known about an entity, each with a source — to ground a statement or see what's actually established before you write. subject: a name or QID; hint: a disambiguator.
| Name | Required | Description | Default |
|---|---|---|---|
| hint | No | ||
| subject | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description clearly indicates the tool is read-only (get verified facts) and returns sourced information. Does not disclose any side effects, which is appropriate for a read operation.
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?
Single sentence with no filler, front-loaded purpose, and inline parameter explanations. Every part earns its place.
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 no output schema and minimal parameters, description covers tool's purpose and parameter usage adequately. Could elaborate on return structure but not necessary.
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?
Adds meaning beyond schema: explains that subject is a name or QID, and hint is a disambiguator. This fully compensates for 0% schema description 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 verb 'Get' and resource 'verified facts known about an entity', with a specific use case (to ground a statement). Differentiates from siblings by emphasizing verified facts with sources.
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 says when to use (to ground a statement) and explains the subject and hint parameters. Lacks explicit comparison to sibling tools but provides enough context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_claimsAInspect
Cross-check MANY claims at once — sanity-check a whole draft or answer before you commit to it. Pass a list of {subject, relation, value, hint}; get one verdict per claim (see cross_check). Ideal as a final pass over anything factual you're about to output.
| Name | Required | Description | Default |
|---|---|---|---|
| claims | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes input format ({subject, relation, value, hint}) and output (verdict per claim). No annotations exist, so description carries full burden; it covers basic behavior but omits details like non-destructive nature, error handling, or rate limits.
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: purpose, input format, usage context. No fluff, information is front-loaded and 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?
For a simple verification tool with one parameter and no output schema, the description covers purpose, input format, and usage. Lacks details on output format beyond 'one verdict per claim' and error behavior, but is largely complete.
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?
Input schema has only one parameter 'claims' with no description and empty items. The description compensates by specifying the structure of each claim ({subject, relation, value, hint}), adding significant 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?
Description clearly states it cross-checks many claims at once for sanity-checking drafts/answers. It distinguishes from siblings by emphasizing batch processing and final pass usage, but does not explicitly differentiate from sibling tools like cross_check.
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?
Provides usage context ('final pass over anything factual') but does not explicitly state when not to use or how it differs from alternatives like cross_check. Guidance is adequate but lacks exclusions.
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!