Skip to main content
Glama
KyTheKitty

VerifyAPI MCP Server

by KyTheKitty
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

VerifyAPI MCP Server

Fact-check any claim before you act on it. One tool. Live web sources. Cryptographically signed receipts.

What it does: VerifyAPI is a Model Context Protocol server that verifies factual claims against live web sources and returns a citable verdict — including the source URL, published date, a verbatim quote, and an Ed25519-signed receipt so downstream systems can prove the check actually happened.

When to use it: Any time your agent is about to act on a factual claim it can't cite. Prices, dates, versions, quotes, statistics, product specs, event outcomes. If getting it wrong would cost time, money, or trust — verify first.

Quick install (Claude Desktop / Cursor / Cline / any MCP client)

{
  "mcpServers": {
    "verifyapi": {
      "command": "npx",
      "args": ["-y", "@verify-api/mcp@latest"],
      "env": {
        "VERIFYAPI_API_KEY": "csk_live_..."
      }
    }
  }
}

No API key? Leave VERIFYAPI_API_KEY unset for the free trial (limited to 3 calls per IP per 24h, signed receipts included). Get a free key at https://verify-api.dev/signup — no credit card required.

Related MCP server: fact-checker

The one tool: verify_claim

Input:

{
  "claim": "Python 3.13 was released in October 2024."
}

Output:

{
  "verdict": "supported",
  "confidence": 0.99,
  "source_url": "https://docs.python.org/3/whatsnew/3.13.html",
  "exact_quote": "Python 3.13 was released on October 7, 2024.",
  "reasoning": "Multiple authoritative sources confirm...",
  "receipt": {
    "jws": "eyJhbGci...",
    "kid": "pQAd73zRp9Xq9Y5U"
  }
}

Verdicts: supported, contradicted, unverifiable. Every supported/contradicted verdict comes with a JWS receipt signed by keys served at https://api.verify-api.dev/.well-known/jwks.json.

Why signed receipts?

Because "the AI checked" is not the same as "the AI verified." A signed receipt lets a downstream system — compliance auditor, user, another agent, a smart contract — cryptographically prove that a specific claim was verified against a specific source at a specific time by VerifyAPI's known public key. It's the difference between saying "trust me" and handing over a notarized document.

Pricing

  • Free trial: no signup, no card. Limited to 3 calls per IP per 24h. Includes signed receipts.

  • With API key: $0.02 per verified claim. Unverifiable / out-of-scope calls are free (you don't pay for "I couldn't find enough evidence").

  • Freshness tiers: standard verification $0.02, real-time (fresh-fetch) $0.05.

  • Auto top-up: save a card, set a threshold, keep flowing. POST /v1/balance/autorefill.

Example use cases

LangChain / LlamaIndex agents: wrap verify_claim as a Tool. Have your agent call it before returning any factual answer.

Cursor / Cline coding agents: verify version numbers, API existence, deprecation status before writing imports.

Claude Desktop workflows: "Verify this quote is real before I put it in the deck."

Multi-agent systems: pass receipts between agents to prove groundedness up the chain.

Compliance-sensitive automation: keep the JWS receipts as audit trail for every factual decision the agent made.

Environment variables

Variable

Required

Default

Description

VERIFYAPI_API_KEY

No

(unset = trial)

Your VerifyAPI key (csk_live_...). Get one free at https://verify-api.dev/signup

VERIFYAPI_BASE_URL

No

https://api.verify-api.dev

Override the API base URL. Useful for self-hosting or testing.

Programmatic API (skip MCP, call directly)

curl -X POST https://api.verify-api.dev/v1/verify \
  -H "Authorization: Bearer csk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"claim": "Bitcoin ETFs were approved by the SEC in January 2024."}'

Full OpenAPI spec: https://api.verify-api.dev/openapi.json

x402 payment support built in — see https://verify-api.dev/agents.txt for the agent-native discovery manifest.

Links

Built by

Circuit Savers LLC — Wausau, Wisconsin.

License

MIT

Available Tools

1 tool
verify_claimA

Fact-check a single factual claim against live web sources. Returns one of supported, refuted, insufficient_evidence, or out_of_scope, with confidence, source_url, published_date, and a verbatim exact_quote from that source. Every response is signed with an Ed25519 receipt (verifiable at https://api.verify-api.dev/.well-known/jwks.json).

Pricing (see /v1/pricing): $0.02 base per supported/refuted verdict; recent tier (<24h old cache) 2x; fresh tier (cache bypassed, guaranteed live) 5x. insufficient_evidence, out_of_scope, malformed, and cache hits within your account are free. Use freshness="cached" (default) for maximum savings; freshness="fresh" when you need a guaranteed-current answer (breaking news, live standings, latest release); set max_age_seconds for HTTP Cache-Control-style bounded staleness.

Running without an API key uses the FREE TRIAL (3 calls per IP per 24h, cached tier only, still returns signed receipts). Set VERIFYAPI_API_KEY in the mcpServers env block to remove the limit and unlock the recent/fresh tiers. Get a key at https://verify-api.dev/signup (no credit card).

Use this before committing to any factual claim you are not sure about — dates, statistics, prices, attributions, event outcomes.

ParametersJSON Schema
NameRequiredDescriptionDefault
as_ofNoOptional ISO date (YYYY-MM-DD). Use for time-sensitive facts, e.g. prices or standings.
claimYesA single factual claim, ideally under 300 characters. If you have multiple claims, call verify_claim once per claim.
freshnessNoOptional freshness tier. `fresh` bypasses both caches and runs the full pipeline (5x price) — use when you need a guaranteed-current answer (breaking news, live standings, latest release version). `cached` (default) honors both cache tiers. See GET /v1/pricing for exact multipliers. (Ignored in trial mode — trial is cached-only.)
max_wait_msNoOptional soft deadline in milliseconds. Default 15000. If the pipeline cannot finish in time you'll get insufficient_evidence.
max_age_secondsNoOptional maximum age (in seconds) for a cached verdict. Acts like HTTP Cache-Control: max-age. Values below 3600 trigger the `fresh` tier; below 86400 trigger the `recent` tier (2x price). If both `freshness` and `max_age_seconds` are set, `freshness` wins. (Ignored in trial mode.)

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains return values, signed receipts, pricing tiers, cache semantics, trial limits, API key requirements, and the consequence of hitting max_wait_ms. No contradictions exist between description and 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 front-loaded with the core purpose and output shape before moving into pricing and trial details. It is longer than average, but the pricing, caching, and authentication information all support correct invocation and cost-aware decision-making.

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 there is no output schema, the description fully explains the return fields and verdict values. It also covers authentication, rate limits, pricing, caching behavior, and when to use fresh vs cached mode, leaving no critical gap for an agent to invoke the tool correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantic value beyond the schema: it explains cost multipliers for freshness choices, trial-mode restrictions, and how max_age_seconds interacts with tiers. This helps an agent choose parameter values, not just parse them.

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 names a specific verb and resource: fact-check a single factual claim against live web sources. It also enumerates the exact verdict values returned, which makes the tool's purpose unmistakable even without siblings to differentiate from.

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 gives explicit guidance: use it before committing to uncertain factual claims, and choose freshness tiers based on whether a current answer is needed. It does not state explicit exclusions or compare against alternative tools, but with no siblings and clear contextual triggers, this is strong usage guidance.

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. 1 tool updatev0.1.9
    • First observedverify_claim
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.7/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no possibility of confusion between tools. The tool's purpose is clearly and uniquely defined, so an agent can unambiguously select it.

Naming Consistency5/5

The lone tool name `verify_claim` follows a clear verb_noun pattern. With only one tool, naming is perfectly consistent and predictable.

Tool Count4/5

The server exposes exactly one tool, which is below the typical 3-15 range but not trivial. The tool is substantial and directly serves the server's narrow fact-checking purpose, so the low count is reasonable, though slightly thin.

Completeness5/5

The domain is fact-checking a single claim, and the tool covers that end-to-end: it accepts a claim, returns a verdict with confidence, source, date, exact quote, and a signed receipt, and offers freshness controls. There are no obvious missing operations for this stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • fact-checker

    Br0ski777
    A
    license
    Not graded
    quality
    C
    maintenance
    Facilitates fact-checking claims by searching the web and returning evidence snippets, with pay-per-call via x402 micropayments on Base L2.
    MIT

  • footnote

    adwitiyashukla
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables agents to verify their own output mid-task by checking every claim against provided sources, returning supported, partial, unsupported, or contradicted verdicts with exact citations.
    MIT