Skip to main content
Glama
blasrodri

mcp-truth-check

by blasrodri
OverviewSchemaRelated ServersScoreDiscussions
Rust
Local

verify_turn

Verify factual claims about code changes against repo diffs, command logs, and git history. Submit claims and message for cited support or contradiction.

Instructions

Fact-check your own claims about code you changed, BEFORE telling the user a change is done — to catch over-claims (wrong values, routes or functions you said you added/removed, files you said you edited, 'I only changed X' scope claims, renames, and 'tests pass'). HOW TO CALL: extract the concrete factual claims from what you're about to say and pass them in claims (one short sentence each) — you parse them far more reliably than truth can re-parse prose, and it's free since you're already writing the message. Also pass the raw message as a backstop. Each claim is checked against the indexed repo + working-tree git diff + recorded command runs + logs and gets a cited supported / contradicted / refused verdict. 'tests pass' is only supported when a matching run recorded via truth run -- <cmd> exited 0 AFTER your last edit. Deterministic: the verdict comes from evidence, not from a model — so listing a claim can't make it pass. 'refused' means unverifiable, NOT confirmed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repoNoAbsolute path to the repo root being worked on. Strongly recommended: truth opens <repo>/.truth and diffs that working tree. If omitted, the server's working directory is used, which may be wrong.
claimsNoRECOMMENDED. The individual factual claims from your message, each as a short self-contained sentence (e.g. ["I set MAX_RETRIES to 5", "I added the /v1/refund route", "I removed the parse_legacy function"]). You (the calling model) extract these from your own message — it's free and far more reliable than truth re-parsing your prose. Only list checkable state claims; skip vague/subjective ones. truth still decides each verdict from real evidence, not from your wording.
messageYesWhat the agent is about to claim about its work (the raw prose). Always include this — truth scans it as a backstop so claims you forget to list still get checked.
local_logNoOptional path to a local log file for usage/error claims.

Tool Definition Quality

A4.7/5.0
Behavior4/5

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

The description explains the deterministic nature, the citation of evidence, and the conditions for 'tests pass' support. It also mentions 'refused' meaning unverifiable. However, it does not explicitly state any potential side effects or limitations, though none are apparent. Still, it is comprehensive given no 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 detailed and front-loaded with the core purpose. It uses clear sections ('HOW TO CALL'). It could be slightly more concise, but every sentence adds value for the agent.

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?

Despite no output schema, the description covers what the tool returns (verdicts with citations) and how to interpret 'refused'. It also explains the evidence sources (indexed repo, git diff, runs, logs). Given the tool's complexity, the description is thorough and leaves little ambiguity.

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?

All parameters have descriptions in the schema (100% coverage), and the description adds significant value: for `claims`, it explains why they are recommended and what to include; for `message`, it clarifies it is a backstop; for `repo`, it explains the recommended use. This goes well beyond the 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: 'Fact-check your own claims about code you changed, BEFORE telling the user a change is done'. It specifies what it catches (over-claims, wrong values, routes, functions, etc.) and distinguishes itself as a verification step in the workflow.

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?

It provides explicit guidance on when to use ('BEFORE telling the user a change is done') and how to call it, including the recommended `claims` parameter format and the importance of including `message`. It also explains what each parameter does and the outcome (verdicts).

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

Install Server

Other Tools

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/blasrodri/truth'

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