Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@claimgate check draft.md against evidence/ and flag any unsubstantiated claims"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A publish gate for AI-assisted marketing content.
Point it at the copy you are about to publish and the evidence your organisation actually holds. It tells you which claims you cannot substantiate, which of your own policy rules you are breaking, and whether the asset is missing a disclosure the law now requires.
Exit code 1 means blocked. That makes it usable in CI, a pre-commit hook, or
a publishing pipeline — which is where a gate stops mistakes instead of
documenting them afterwards.
$ claimgate check campaign.md --evidence substantiation/ --policy policy.json
Claims requiring substantiation (14)
✗ [attribution] According to research at a leading university, 94% of finance teams waste more
unsupported: the figure(s) 94% in this claim do not appear in any supplied evidence
✗ [statistic] thousands of businesses, and we are fully ISO 27001 certified.
contradicted: evidence states "Acme Invoicing is not certified under ISO 27001"
~ [statistic] Meridian Freight cut their reconciliation time from 22 hours to 9 hours a week
partially_supported: the case study confirms 22 hours and 9 hours, but not "always"
try: Meridian Freight's finance team reduced reconciliation from 22 hours a week to 9
Policy findings (3)
✗ [prohibited] guaranteed
absolute guarantees are unenforceable and are treated as misleading advertising
✗ [disclosure] AI disclosure missing
required under EU AI Act Article 50 (in force 2 Aug 2026) and platform labelling rules
BLOCKED — 14 unsupported claim(s), 3 blocking policy finding(s).Generative AI is now how a large share of marketing copy gets written, and the controls did not scale with it. The recurring finding across 2025–2026 is not that models are bad at writing. It is that a reviewer cannot tell a hallucinated statistic from a real one — there is no grammatical signal that separates them — so hallucinated content passes a casual read. Organisations that scaled AI content without a review gate did not reduce their content risk, they accelerated it.
The existing tools do not close this. Detectors tell you a text was AI-written, which is not the question. Generators produce more copy. Governance platforms tell you at the end of the quarter that you had incidents.
ClaimGate answers the question that actually decides whether an asset can ship: can this specific claim be traced to something we can point at?
Related MCP server: @palveron/mcp-server
1. Substantiation. Every checkable claim in the draft is extracted, then adjudicated against your evidence. The important part is how:
A number in a claim must appear in the evidence. That is a string search, not a judgement call, and no model gets to overrule it. A fabricated statistic cannot be talked into a pass.
Semantic support is decided by a model given only the claim and the
evidence, required to name the evidence it relied on, and allowed to answer
unsupported or unverified.
If the model is unavailable, the key is missing, or the reply is malformed,
the verdict is unverified — which blocks. It never fails towards
"supported".
2. Policy. Your prohibited and restricted claims, written down once and enforced on every draft: guarantees, medical and financial claims, unsourced superlatives, named competitors, personal data.
3. Disclosure. From 2 August 2026 the EU AI Act (Article 50) requires disclosure of AI-generated content in specified circumstances, and Meta, TikTok and Google each require an AI label on realistic synthetic media in ads. A customer-facing AI-assisted asset with no disclosure is non-compliant however good the copy is — so it is checked as a property of the draft, not left to whoever uploads it.
No dependencies. Python 3.9+.
pip install "claimgate @ git+https://github.com/caseone115/claimgate"Not a bare pip install claimgate. That name on PyPI belongs to a
different, unrelated project (an AI-agent test harness), so the bare name
installs that tool, in which claimgate check does not exist. This
product installs from its own source repository, which is also where its
licence and its tests live. From a checkout, pip install -e . is
equivalent.
claimgate init my-project && cd my-project
claimgate check DRAFT-template.md --evidence evidence/ --policy policy.json --no-modelThat writes a policy file you can edit, an evidence folder, a blank draft
template, a six-question pre-publish checklist (including the AI-disclosure
section) and a GitHub Actions job that gates every pull request. --no-model
needs no API key and no network: it runs the deterministic checks, and it does
catch inventing — a figure that appears in the draft and not in your evidence
blocks, whatever wrote it.
The kit is free and stays free: https://github.com/caseone115/claimgate.
The full engine — model adjudication of every claim, JSON output for pipelines, the whole test suite — is a one-off download at https://teeterbot.gumroad.com/l/claimgate/LAUNCH39: US$39 while the launch is running, US$149 after it. It is the same code as this repository, MIT licensed; nothing is held back from the source.
claimgate init my-project # the free starter kit
claimgate init-policy policy.json # a starter policy to edit
claimgate claims draft.md # just list the claims
claimgate check draft.md --evidence ./evidence/
claimgate check draft.md --evidence evidence.json --policy policy.json --json
claimgate check draft.md --no-model # facts and policy only, no API callsEvidence is any directory of .txt/.md/.html files, or a JSON array:
[{"id": "spec", "title": "Product spec", "text": "..."},
{"id": "case-1", "title": "Meridian case study", "url": "..."}]Set DEEPSEEK_API_KEY for adjudication. Without it, --no-model still runs
the deterministic checks — which is where the fabricated-figure guarantee
lives.
Not a fact-checker. It does not search the web or decide what is true. It decides whether you can substantiate what you wrote, against evidence you supply. That is the question a compliance review actually asks, and it is the only one answerable without pretending to authority the tool does not have.
Not a detector. It does not guess whether a text was AI-written.
Not a lawyer. It enforces the policy you write. It flags where AI disclosure obligations appear to apply; it does not give legal advice.
The same checks run as an MCP server, so an agent can gate a draft before it
publishes instead of a human remembering to. mcp/server.py needs no install —
uv fetches its one dependency. Add this to your client's config:
{
"mcpServers": {
"claimgate": {
"command": "uv",
"args": ["run", "--directory", "<repo>/mcp", "<repo>/mcp/server.py"]
}
}
}It exposes check_draft, check_draft_json, list_claims,
check_policy_only and about. See mcp/README.md, including
what it deliberately refuses to do.
The free starter kit is a second registry entry,
io.github.caseone115/claimgate-kit. init_kit writes the policy file, the
evidence folder, the checklist and the GitHub Actions job into a directory you
name; check_kit then runs that gate offline with no API key. See
mcp-kit/.
python tests/test_claimgate.py # 55 checks — the engine
python tests/test_outreach.py # 21 checks — the outreach guardrails
python tests/test_kit.py # 44 checks — the starter kit
python scripts/test_mcp_server.py # 19 checks — the MCP server, over real stdioThe suite is written against the product's promises, not its implementation:
that no claim is invented, that a number absent from the evidence is never
reported as supported, that anything uncheckable blocks, and that the same
input always gives the same answer. tests/test_kit.py also runs the shipped
README through the shipped policy, because a claim-checking product whose own
front page carries a prohibited claim is the worst demonstration there is.
MIT.
What this server is, what it does not do, and how it can be trusted.
Read this before relying on any verdict it returns.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose key behavioral traits: it frames itself as a trust and limitations resource, including 'what it does not do.' It does not explicitly state that it is read-only or has no side effects, but the informational nature 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no waste. The core purpose is front-loaded, and the usage instruction follows immediately, making it easy for an agent to parse.
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?
An output schema exists, so the description need not explain return values. It sufficiently covers what the tool is for and when to read it, which is complete for a zero-parameter about tool.
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?
The tool has zero parameters, so there are no parameter semantics to clarify. The baseline for zero-parameter tools is 4, and the description appropriately does not attempt to describe inputs.
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 subject: it explains what the server is, what it does not do, and how it can be trusted. This distinguishes it from sibling verdict tools like check_draft and check_policy_only, though it does not use a conventional verb+resource phrasing.
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?
It gives explicit usage context: 'Read this before relying on any verdict it returns.' This tells the agent when to call it relative to the verdict-producing siblings, but does not name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check one piece of marketing copy against the evidence you hold.
Returns a plain-English report of which claims cannot be substantiated, which of your own policy rules the draft breaks, and whether an AI disclosure is missing. Read the summary first: it is written to be read by a person, and the machine-readable detail is available from check_draft_json.
ARGUMENTS
draft the copy to check, inline. Give this or draft_path.
draft_path path to a .md/.txt/.html file to check instead.
evidence_dir a folder of files to treat as evidence (.txt/.md/.html).
Everything in it is offered to the checker; nothing is
uploaded anywhere.
evidence_json evidence as a JSON array, e.g.
[{"id":"pricing","text":"The plan is $39/month"}]
policy_json your own policy file, from claimgate init-policy. Omit
to use the built-in defaults.
use_model false runs only the deterministic checks - no network, no
API key. A claim that cannot be decided that way comes
back unverified, never supported.
WHAT IT WILL NOT DO It does not decide that a claim is true because it sounds reasonable. If it cannot tell, it says so. A green tick here means an evidence file you supplied actually states the claim's substance.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | No | ||
| use_model | No | ||
| draft_path | No | ||
| policy_json | No | ||
| evidence_dir | No | ||
| evidence_json | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden and does so well: it discloses the privacy posture ('nothing is uploaded anywhere'), the deterministic-vs-model execution modes, the API-key/network requirement, and the precise meaning of a pass ('a green tick means an evidence file you supplied actually states the claim's substance'). The dedicated WHAT IT WILL NOT DO section pre-empts the most likely misuse, treating unsubstantiated claims as `unverified` rather than guessing.
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?
Front-loaded with the one-line purpose, then organized into a parameter block and a caveats block. Despite its length, every sentence carries distinct information (privacy, mode semantics, output routing) and none restates the tool name or schema boilerplate.
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 six-parameter tool with zero schema coverage, no annotations, and an existing output schema, the description covers exactly the right ground: full parameter semantics, execution-mode behavior, privacy guarantees, and where to get structured output. Return-value explanation is correctly omitted since an output schema exists.
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 description coverage is 0%, so the description must compensate and it does: every one of the six parameters is documented inline, including the draft/draft_path mutual exclusivity, what evidence_dir offers to the checker, a concrete evidence_json example, the origin of policy_json via `claimgate init-policy`, and the semantic difference use_model=false makes to returned statuses.
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?
States a specific verb and resource ('Check one piece of marketing copy against the evidence you hold') and immediately scopes the output as a plain-English report, which cleanly separates it from the sibling check_draft_json. An agent can tell what this tool does and what class of result it returns without opening the schema.
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 routes the agent to check_draft_json for machine-readable detail and explains the use_model=false branch (no network, no API key, undecidable claims come back `unverified`). It also notes policy_json is omitted to use built-in defaults. However the sibling check_policy_only is never mentioned, and there is no explicit 'do not use this when...' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The same check as check_draft, returned as structured JSON.
Use this when a pipeline, a CI job or another agent needs to gate on the
result rather than read it. Keys: claims, verdicts, policy_findings,
summary. summary.blocked is the boolean to gate on, and it is true when
any claim is unsupported, contradicted or unverified, or any policy
finding is blocking. Unverified counts as blocked on purpose: unknown is
not the same as fine, and a gate that treats it as fine is decoration.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | No | ||
| use_model | No | ||
| draft_path | No | ||
| policy_json | No | ||
| evidence_dir | No | ||
| evidence_json | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and delivers strong output semantics: the keys returned and the precise truth conditions for summary.blocked, including the deliberate decision that unverified counts as blocked. It is silent on input-side behavior (e.g. what use_model triggers), so it is not fully complete.
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?
Front-loaded with the key differentiator and the gate boolean. The closing line ('a gate that treats it as fine is decoration') is rhetorical but reinforces a genuinely important semantic, so it earns most of its space.
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?
The output schema already exists, so the return-value explanation is partly redundant, though the blocked semantics add value. The real gap is input completeness: a 6-parameter tool with zero parameter documentation anywhere is under-specified for correct invocation.
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?
Six parameters at 0% schema description coverage, and the description explains none of them. Fields like draft vs draft_path, evidence_dir vs evidence_json, and use_model are entirely undocumented, leaving the agent to guess their meaning and mutual exclusivity.
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 names a specific verb+resource (the same check as check_draft) and its distinguishing property (returned as structured JSON). An agent can immediately separate it from check_draft without opening either schema.
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?
It states exactly when to prefer this tool: 'when a pipeline, a CI job or another agent needs to gate on the result rather than read it.' The alternative (check_draft) is named, so the selection condition is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a draft against a policy alone - prohibited claims and AI disclosure.
This is the half that needs no evidence and no model: the constitutional layer. It answers "would our own rules let this out of the door", which is a different question from "is it true".
| Name | Required | Description | Default |
|---|---|---|---|
| draft | No | ||
| draft_path | No | ||
| policy_json | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that this path requires no evidence and no model (i.e., it is a cheap, self-contained policy check) and enumerates what is checked, but says nothing about failure modes, what happens with a malformed or missing policy, or how strict the verdict is.
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?
Front-loaded with the core purpose, then a short elaboration and a framing contrast. The 'constitutional layer' flourish is a bit decorative but brief, and no sentence is redundant.
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?
An output schema exists, so return values need not be explained, and the scope of the check is clear. However, with no annotations and zero parameter documentation, an agent still lacks guidance on how to supply the draft and policy, leaving the definition incomplete for a 3-parameter tool.
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?
Three parameters at 0% schema coverage, and the description explains none of them. The ambiguity between 'draft' (inline text?) and 'draft_path' (file path?) is exactly the kind of thing the description should resolve, and 'policy_json' is likewise undocumented. This is a real gap the description fails to compensate for.
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?
States a specific verb and resource ('Check a draft against a policy alone') and names the check contents (prohibited claims, AI disclosure). It distinguishes itself from the evidence/model-based siblings by describing itself as 'the half that needs no evidence and no model', though it never names check_draft directly.
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?
Gives a clear selection condition: use this when only the policy layer matters and no evidence or model is needed, contrasted against the 'is it true' question other tools presumably answer. It stops short of explicitly naming the alternative tool to use instead when truth/evidence matters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the claims in a draft and what each one needs, without judging them.
Useful as a first pass: it shows what the checker will demand substantiation for, so you can judge whether your evidence folder is even the right shape. Categories include statistic, percentage, superlative, comparative, guarantee, efficacy, temporal, attribution, absolute and causal.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | No | ||
| draft_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the key trait that the tool does not judge or reject anything (a non-evaluating read). It also names the categories it will classify into, which helps interpret results. However, it says nothing about permissions, input size limits, or error behavior, leaving real gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, and the follow-on sentences add genuine routing value. The trailing category enumeration is longer than strictly necessary but is informative rather than padding.
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?
An output schema exists, so return values need not be described, and the non-mutating nature is clear. The remaining hole is the unresolved draft vs draft_path choice, which an agent must get right to call the tool at all, and which nothing in the description or schema addresses.
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 description coverage is 0% and there are two parameters (draft, draft_path) offering two distinct input modes, yet the description never explains the difference or when to use one over the other. It only implies that 'a draft' is the input, so it does not compensate for the documentation gap.
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?
States a specific verb and resource ('List the claims in a draft and what each one needs') and immediately scopes it against the checking siblings with 'without judging them.' An agent can tell this is the inventory step rather than the evaluation step 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions the tool as 'a first pass' whose purpose is to reveal 'what the checker will demand substantiation for,' which gives clear situational context relative to check_draft and its variants. It stops short of naming the alternative tools explicitly or stating when not to use it, so it is strong but not complete routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0aboutcheck_draftcheck_draft_jsoncheck_policy_onlylist_claimsScored across 5 tools
check_draft, list_claims, check_policy_only and about each target a clearly different need, and the descriptions explicitly delimit what each does and does not decide. The one soft spot is check_draft vs check_draft_json, which perform the identical check and differ only in output format, plus check_policy_only which is a partial subset of check_draft; both overlaps are well-explained, so confusion is unlikely but not impossible.
Four of five names follow a verb_noun snake_case pattern (check_draft, check_draft_json, list_claims, check_policy_only) with a readable _json suffix convention. The lone outlier is 'about', a bare noun, which is a minor deviation rather than a convention clash.
Five tools is well-scoped for a claim-verification server: a human-readable check, a machine-gated variant, a pre-pass claim lister, an evidence-free policy check, and a trust/scope note. Nothing feels padded, and no essential verb is crowded out by the count.
The core lifecycle (list claims, check against evidence, check against policy, gate on structured output, read scope) is fully covered for a read-only verification domain. Minor gaps remain: no rewrite/suggestion tool to fix flagged claims, no tool to build or validate an evidence set or policy (init-policy is CLI-only), and no batch/multi-draft entry point, but agents can work around these.
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
Authenticated MCP server for ClearPolicy policy and compliance workflows.
Judged, citation-checked policy corpus over MCP. Keyless public reads; API key for AI tools.
AI governance MCP server for EU AI Act compliance and jurisdiction verification
