Skip to main content
Glama
SamYatesSmith

tru8-mcp

by SamYatesSmith
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

tru8-mcp

MCP server for Tru8 Evidence Research — structured evidence research tools for AI agents.

Submit a claim or URL, get back source-traced evidence organized by tier (primary/reporting/commentary) and type (data/official/news/analysis/opinion/academic), with element decomposition and relationship mapping.

Two ways to connect

Hosted (nothing to install). Point any MCP client that supports remote servers at:

https://api.trueight.com/mcp

Authenticate with your Tru8 API key, sent either as an X-API-Key header or as Authorization: Bearer. Each request is authenticated on its own, so one endpoint serves every user without their keys ever meeting.

Local (this package). Runs on your own machine over stdio, which means your API key never leaves it. Use this if you would rather not send a credential through anyone else's infrastructure.

Both serve the identical tools from the identical code — pick whichever suits.

Related MCP server: Atom of Thoughts

Quick Start

pip install tru8-mcp

Or run without installing:

uvx tru8-mcp

Set your API key:

export TRU8_API_KEY=tru8_sk_...

Create an API key at your Tru8 dashboard under Settings > Developer.

Configuration

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "tru8": {
      "command": "tru8-mcp",
      "env": {
        "TRU8_API_KEY": "tru8_sk_..."
      }
    }
  }
}

Cline / Cursor

Add to your MCP settings:

{
  "mcpServers": {
    "tru8": {
      "command": "uvx",
      "args": ["tru8-mcp"],
      "env": {
        "TRU8_API_KEY": "tru8_sk_..."
      }
    }
  }
}

From source

git clone https://github.com/SamYatesSmith/tru8-mcp.git
cd tru8-mcp
pip install -e .
tru8-mcp

Tools

Tool

Description

Typical time

tru8_check

Evidence research for a claim or article URL

15-120s

tru8_get_result

Retrieve completed check with computed analytics

<1s

tru8_get_result_raw

Retrieve raw check data without computed analytics

<1s

Environment Variables

Variable

Required

Description

TRU8_API_KEY

Yes

API key (tru8_sk_...). Create at dashboard > Settings > Developer.

TRU8_API_URL

No

API base URL. Default: https://api.trueight.com

Security

Store API keys in environment variables or a secrets manager. Never hardcode keys in source code. If a key is compromised, revoke it immediately at your dashboard.

Available Tools

3 tools
tru8_checkA

Evidence research for a factual claim or article URL.

Submit a claim as text or paste an article URL. URLs are auto-detected and trigger article mode: the pipeline extracts claims from the page and auto-selects up to 5 for evidence research.

Tiers (in fallback order):

  • lookup (~£0.02, instant) — cached prior analysis

  • consensus (~£0.03, instant) — cross-user aggregate landscape (k≥3 checks)

  • quick (~£0.07, ~15s) — web search + heuristic classification

  • full (~£0.15, ~60-90s) — 30+ sources, LLM classification, coverage recovery

Charges based on tier actually executed, not tier requested. Set max_tier to control maximum spend per call.

Output structure:

  • claims[].claimMap.elements[] — verifiable sub-claims with state (supported/disputed/unresolved)

  • claims[].claimMap.elements[].evidenceRefs[] — evidence mapped to elements with relationship (supports/challenges/context) and reasoning

  • claims[].evidence[] — sources classified by tier (primary/reporting/ commentary) and type (data/official/news/analysis/opinion/academic)

  • claims[].claimMap.orientation — mechanical summary from element states

  • _meta — execution metadata: executedTier, chargedPence, limitations

Args: claim: A factual claim ("The Earth's average temperature rose 1.1°C since 1880") or an article URL (https://example.com/article). URLs are auto-detected and the pipeline extracts claims from the page content. max_tier: Maximum tier to attempt — "lookup", "consensus", "quick" (default), or "full". max_age_hours: Skip cache hits older than this many hours. If set, lookup hits that are stale will be discarded and the pipeline re-runs at the next tier up to max_tier. compact: If True, strip full evidence arrays from response (smaller payload).

ParametersJSON Schema
NameRequiredDescriptionDefault
claimYes
max_tierNoquick
max_age_hoursNo
compactNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: auto-detection of URLs, tier fallback with costs and timing, caching behavior (max_age_hours), and output structure. It is transparent about what happens during execution without needing 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 sections for tiers and output, and it is front-loaded with the purpose. It is slightly verbose due to detailed tier and output explanations, but every sentence adds value; minor redundancy is acceptable for clarity.

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 complexity, lack of annotations, and 0% schema coverage, the description covers all necessary aspects: input, behavior, parameters, output structure (including nested objects), and execution details. It is fully complete without relying on the output schema.

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 description coverage is 0%, so the description must compensate. It thoroughly explains each parameter: claim (text or URL, auto-detection), max_tier (options and default), max_age_hours (purpose), and compact (stripping evidence arrays). This adds significant meaning beyond the bare schema.

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 as evidence research for a factual claim or article URL, using a specific verb and resource. It distinguishes itself from sibling tools (tru8_get_result, tru8_get_result_raw) which are for retrieving results, thus avoiding ambiguity.

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 explains when to use the tool (for claims or URLs), details the tier system and fallback order, and mentions max_tier for cost control. It provides clear context but does not explicitly state when not to use it or list alternative tools, though the sibling differentiation is implicit.

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

tru8_get_resultA

Retrieve a previously submitted check with pre-computed analytics.

Returns the full result including a _computed block with tier/type distributions, corroboration groups, diagnostic values, timeline analysis, element state summaries, and per-claim dispositions.

Use this over tru8_get_result_raw when you want structured analytics ready for summarisation or comparison without post-processing.

Args: check_id: UUID returned by tru8_check.

ParametersJSON Schema
NameRequiredDescriptionDefault
check_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It describes the return value in detail but does not explicitly state that the operation is read-only or non-destructive. However, the term 'retrieve' implies reading, and no side effects are mentioned. A bit more explicitness could improve confidence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. It starts with a clear purpose sentence, then describes the return value, then gives usage guidance, and finally lists the argument. No unnecessary words.

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 has an output schema (though not shown), the description explains what the output contains in detail (computed block, distributions, etc.). It covers the single parameter well and provides context for when to use the tool. It feels complete for a retrieval tool.

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?

There is only one parameter, check_id. The schema has type 'string', and the description adds semantic meaning by stating it is a UUID returned by tru8_check. This helps the agent understand the parameter's source and format.

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 retrieves a previously submitted check with pre-computed analytics, using specific verb and resource. It also distinguishes itself from sibling tool tru8_get_result_raw by emphasizing structured analytics.

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?

Explicit guidance is provided: use this over tru8_get_result_raw when you want structured analytics for summarisation or comparison. This directly helps the agent decide which tool to use.

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

tru8_get_result_rawA

Retrieve a previously submitted check without computed analytics.

Returns claims, elements, evidence, and claim maps only. No _computed block. Smaller response payload. Use this when you will compute your own aggregations or only need specific fields from the raw data.

Args: check_id: UUID returned by tru8_check.

ParametersJSON Schema
NameRequiredDescriptionDefault
check_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

Discloses no computed block, smaller payload, and lists returned components, though could mention idempotency or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise with summary, returned fields, usage note, and parameter description; no wasted words.

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 purpose, usage, parameter, and expected return types; output schema exists so no need to detail return values further.

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?

The description adds that check_id is a UUID from tru8_check, adding meaning beyond the schema's type string.

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 retrieves a check result without computed analytics, distinguishing it from tru8_get_result which likely includes computed data.

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 advises use when computing own aggregations or needing only specific raw fields, providing clear alternative context.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedtru8_check
    • First observedtru8_get_result
    • First observedtru8_get_result_raw
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation4/5

The three tools have distinct purposes: check submits a claim, get_result returns analytics, and get_result_raw returns raw data. The two retrieval tools are very similar but explicitly differentiated by descriptions, causing minimal ambiguity.

Naming Consistency5/5

All tools follow the pattern tru8_<verb>_<modifier> with consistent snake_case. The verbs 'check' and 'get' are clear, and modifiers 'result' and 'result_raw' are descriptive and uniformly applied.

Tool Count5/5

Three tools is well-suited for the narrow domain of fact-checking: one for submitting a claim and two for retrieving results in different formats. No unnecessary tools, and the count is sufficient for the core workflow.

Completeness4/5

The tool surface covers the primary workflow (submit and retrieve results with or without analytics). However, there is no tool to list or manage previous checks, which is a minor gap for users who need to track multiple checks.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SamYatesSmith/tru8-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server