claimgate
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEEPSEEK_API_KEY | No | API key for model adjudication. Without it, `--no-model` still runs the deterministic checks — which is where the fabricated-figure guarantee lives. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_draftA | 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 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. |
| check_draft_jsonA | 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. |
| list_claimsA | 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. |
| check_policy_onlyB | 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". |
| aboutA | What this server is, what it does not do, and how it can be trusted. Read this before relying on any verdict it returns. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.