Skip to main content
Glama
brittbart

Verum Signal MCP Server

by brittbart
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Verum Signal MCP Server

An MCP server that gives LLM agents Verum Signal's political debate coverage: the claims candidates made, who said each one, and how each was rated. It also searches the claims news outlets report. Requires a Verum Signal API key.

What the tools do

Tool

Returns

Explicitly does NOT

list_debates

Available debates with claim counts, dates, and status.

Include the claims themselves — call get_debate_verdicts for that.

get_debate_verdicts

Every rated claim from one debate, with the speaker, the rating, and whether the rating is still provisional. Paginates automatically to completeness.

Truncate silently. If a debate is large enough to hit an internal safety cap, the response includes an explicit truncated: true flag rather than quietly returning a partial result.

list_recent_claims

Claims reported by news outlets, with their ratings. Pass q to find claims about a topic; filter by outlet or rating; without q, most recent first.

Return quoted claims an outlet attributes to someone else, or any overall score for an outlet.

get_api_status

Corpus statistics: how much the corpus holds, what it covers, and how current it is.

Include per-claim detail — call the other tools for that.

Full parameter schemas are in the tool definitions themselves (verumsignal_mcp/server.py), and are also what any MCP client will show you directly. This table is a summary; the tool definitions are authoritative.

Related MCP server: agentfolio-mcp-server

Install & config

Requires Python 3.9+ and no third-party dependencies.

With uv (nothing to install first):

{
  "mcpServers": {
    "verum-signal": {
      "command": "uvx",
      "args": ["verumsignal-mcp"],
      "env": { "VS_API_KEY": "vs_live_..." }
    }
  }
}

With pip:

pip install verumsignal-mcp

then use "command": "verumsignal-mcp" with no args in the config above.

From a clone: git clone https://github.com/brittbart/verumsignal-mcp.git and use "command": "python3", "args": ["/absolute/path/to/mcp_server.py"].

These examples are for Claude Desktop's claude_desktop_config.json; other MCP clients take the same command, arguments and environment.

Verify it works: ask your agent "which debates does Verum Signal cover?" A correctly wired server returns a list of debates with dates and claim counts. If you see an authentication error, check the key; if you see a connection error, confirm outbound HTTPS access to api.verumsignal.com is allowed from wherever the server runs.

Getting a key

Keys are issued to Verum Signal account holders. See verumsignal.com/developers.

The data boundary

Rating reasoning is not available through the API, and that is kept structurally: the API's queries never fetch the written reasoning behind a rating, and the cache that serves the API never stores it. It isn't a filter applied after the fact — the data simply isn't in what this server can reach.

What this server sends out: an authenticated GET request to api.verumsignal.com (or an operator-configured VS_API_BASE) for each tool call.

What it sends back to the calling agent: whatever that API call returns.

What it never touches: this server makes no network connections to anything other than the configured API host, reads and writes no local files, and includes no telemetry or analytics of any kind. It uses only the Python standard library (json, os, sys, urllib).

Key handling

VS_API_KEY is read from the environment and is never hardcoded. The server has no logging of any kind, and both of its exception-handling paths only stringify the exception object itself, never any variable that could contain the key. There is no code path by which the key can reach output, a log, or a file.

You can provide the key two ways:

  1. In the MCP client's config file, as shown above. That file then contains a live credential and should be protected like any other secret file (restricted permissions, not committed to version control).

  2. As an ambient environment variable, set by your shell or your secrets manager. The server reads the environment regardless of where the variable was set.

Rate limits & quota

Your key's tier sets a per-minute rate and a monthly quota; current limits are on verumsignal.com/developers. Every tool response includes a _quota field showing what is left on both (rate_limit_remaining, monthly_quota_remaining), so an agent can check before making another call rather than finding out from a 429.

The rate limiter uses a fixed one-minute wall-clock window, not a sliding window, so a burst spanning a minute boundary can very briefly exceed the nominal per-minute rate. It's bounded, and you should hear it from us first.

Versioning

This server is at v0.2.0, an honest pre-1.0 number. It targets API version v1. Ratings carry the methodology version they were made under. See CHANGELOG.md for version history.

Known limitations

  • Outlet-level scores are not served. The tools return individual claims and their ratings only.

  • No rating reasoning. A deliberate boundary — see "The data boundary" above.

  • Debate ratings can be provisional. Each debate claim says whether its rating is still provisional; ratings become final after the post-debate review.

  • Data freshness: the API's cache refreshes every 5 minutes. This server's data is exactly as fresh as that cache.

Available Tools

4 tools
get_api_statusA

Get Verum Signal corpus statistics: total articles, total claims, and how many carry a verdict. Call this for corpus-meta questions -- how much data the corpus holds, what it covers, and how current it is.

NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does establish this is an aggregate read that returns counts and recency information. It does not state whether results are cached/live, how 'current' is measured, or any rate or auth constraints. Adequate for a zero-parameter read but not rich.

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?

Two sentences: the first states the returned metrics, the second states the call condition. It is front-loaded with the payload and has no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-param, no-output-schema stats tool, the description effectively stands in for a return schema by enumerating the metrics. Only the response shape/format is left unspecified, which is a minor gap given how simple the output is.

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 tool takes no parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies no scoping inputs are needed.

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 names a concrete resource and enumerates the returned metrics (total articles, total claims, verdict-carrying claims), so the agent knows exactly what it gets. It implicitly separates itself from the listing siblings (list_debates, list_recent_claims) by framing this as corpus-meta rather than content retrieval, though it never names them. It also usefully overrides the misleading tool name, which suggests API health rather than corpus statistics.

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?

'Call this for corpus-meta questions' plus three concrete question shapes (how much data, what it covers, how current) gives a clear use condition. No explicit exclusions or named alternatives are given, so the agent must infer that per-claim or per-debate lookups belong to the siblings.

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

get_debate_verdictsA

Get ALL rated claims from a political debate. Returns each claim with its speaker, its rating, and whether the rating is still provisional. Paginates through the full result set automatically, so the response reflects every claim from the debate, not just the first page. Use this for claims made during a specific debate.

NameRequiredDescriptionDefault
slugYesDebate slug, e.g. 'colorado-gov-rep-2026-r3'. Use list_debates to find slugs.

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden; it discloses automatic pagination, full-result completeness, and the returned fields (speaker, rating, provisional status). It does not mention authentication, rate limits, or explicitly state read-only behavior, but the 'Get'/'Returns' framing is clear.

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 compact and front-loaded: purpose and scope first, then return fields, then pagination behavior, then usage guidance. The repetition of 'ALL'/'every claim' reinforces the key scope rather than adding unrelated filler.

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?

For a simple one-parameter read tool with no output schema, the description provides enough context: what is returned, that pagination is automatic, and when to use it. Only edge/error behavior is absent, which is minor at this complexity level.

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?

Schema description coverage is 100%, and the schema already documents the required slug with an example and a pointer to list_debates. The description only adds 'specific debate' context and does not add syntax or meaning beyond the schema, so the high-coverage baseline of 3 applies.

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 states a specific verb ('Get'), resource ('rated claims from a political debate'), scope ('ALL'), and return fields, so an agent can distinguish it from list_recent_claims by the 'specific debate' framing. It is not a tautology and clearly identifies the resource.

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?

It says to use this 'for claims made during a specific debate,' giving clear context, and the schema points to list_debates for finding slugs. It does not explicitly name when-not to use it or name list_recent_claims as the alternative in the description body.

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

list_debatesB

List available political debates with claim counts and status.

NameRequiredDescriptionDefault

No parameters

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, but "List" reasonably implies a read-only enumeration and the phrase "with claim counts and status" discloses part of the response shape even though no output schema exists. It does not say whether all debates are returned, any ordering, or pagination/limit behavior.

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?

A single front-loaded sentence with no filler — the resource and the returned fields come first. Slightly softened by the vague qualifier "available", which earns no information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter list tool with no output schema, the description does state what comes back (claim counts, status), which is the main missing structured data. It remains silent on result size, ordering, and how it differs from get_debate_verdicts, which an agent needs to pick 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The description correctly signals a no-argument, enumerate-everything call.

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?

Specific verb+resource ("List available political debates") with a note on what each entry carries (claim counts and status). It does not distinguish itself from siblings like get_debate_verdicts, so an agent must infer that this is the enumeration entry point rather than the per-debate detail tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use statement and no mention of alternatives such as get_debate_verdicts (for verdict data) or list_recent_claims (for claim-level data). Usage is only implied by the word "available", leaving routing between siblings to inference.

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

list_recent_claimsA

Search and list claims from Verum Signal's corpus. Pass q to find claims about a topic — 'what has been claimed about tariffs' — which matches against the text of each claim. Without q it returns claims in recency order, most recent first. Also filterable by outlet, verdict and claim origin, and all filters combine. Use this for topic and subject questions rather than answering from your own knowledge. Returns claims reported by news outlets, each with its rating. Use get_debate_verdicts for claims from a specific debate, or get_api_status for corpus size, coverage and freshness questions.

NameRequiredDescriptionDefault
qNoFind claims whose text contains this term, case-insensitive. Use for topic questions, e.g. 'tariffs' or 'immigration'.
limitNoNumber of results (1-50, default 10)
outletNoFilter by outlet domain, e.g. foxnews.com
verdictNoFilter by verdict: supported, disputed, overstated, not_supported, etc.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations the description carries the full burden, and it does disclose the key behaviors: default recency ordering when `q` is absent, that all filters combine conjunctively, and what comes back ('claims reported by news outlets, each with its rating'). Gaps remain around result-set size limits, whether there is a total count, and any rate limiting, so it is strong but not complete for an unannotated tool.

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?

Front-loaded with the primary mode and its trigger, then fallbacks and routing, which is the right order. Slightly longer than needed: the topic-question guidance is stated twice ('Pass `q` to find claims about a topic' and 'Use this for topic and subject questions'), and the nonexistent origin filter is wasted text.

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?

There is no output schema, so the description must characterize returns, and it does ('claims reported by news outlets, each with its rating'); there are no annotations, yet the tool is a read-only list with no destructive surface to disclose. For a 4-parameter, zero-required discovery tool this covers the decision-relevant facts an agent needs.

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?

Schema coverage is 100%, so the baseline is 3, and the description does add one genuinely useful semantic ('all filters combine'). However it advertises filtering by 'claim origin', which is not a parameter in the schema, creating a mismatch that could send an agent looking for a nonexistent argument, while `limit` goes unmentioned in prose.

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?

States a specific verb and resource ('search and list claims from Verum Signal's corpus') and immediately explains the two operating modes: keyword search with `q`, recency-ordered listing without it. It explicitly names the siblings it is not (get_debate_verdicts, get_api_status) and their domains, so an agent can route without opening any schema.

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?

Gives explicit when-to-use guidance ('use this for topic and subject questions rather than answering from your own knowledge') and names two alternatives with the exact conditions that select them: get_debate_verdicts for a specific debate, get_api_status for corpus size/coverage/freshness. Exclusions and alternatives are both present.

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. 4 tool updatesv0.2.0
    • First observedget_api_status
    • First observedget_debate_verdicts
    • First observedlist_debates
    • First observedlist_recent_claims
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/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: debate listing, debate-specific claim retrieval, corpus-wide claim search/filtering, and corpus metadata. The descriptions explicitly route users between debate-specific retrieval and topic search, avoiding overlap.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: get_debate_verdicts, list_debates, list_recent_claims, get_api_status. The two verbs (get/list) are used predictably across the set.

Tool Count5/5

Four tools is well-scoped for a read-only political claim/debate lookup server. Each tool earns its place, and there is no redundant or filler tool.

Completeness4/5

The surface covers core read-only workflows: discovering debates, retrieving all debate verdicts, searching claims by topic/filters, and checking corpus status. Minor gaps exist around direct claim lookup by ID or outlet/verdict facet listing, but these are not dead ends for typical queries.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers