Skip to main content
Glama

Countersign by Signalry

Submit and verify a claim

submit_claim
Read-only

Record a claim and verify it now with public checks. Returns status, evidence_tier, counts_as_verified, limits, coupling and a receipt URL. Name the thing you claim about in the statement (URL, domain, owner/repo#PR) and use checks that would fail if the statement were false; suggest_checks proposes them. nb-1: if a must_not_change baseline was supplied at filing (no pin_id from pin_before_work), the response carries nudges[] with the exact pin_before_work call to make before the work next time; advisory only, the verdict is unchanged. Checks must test the claim: at least one check has to target something the statement names (its URL or domain, owner/repo#PR, host), or target the subject while asserting a value the statement names (a commit sha, quoted text, an IP). Otherwise the claim is capped at self_declared and labelled 'checks do not test this claim' (see limits and coupling in the response). contains text that also appears in the check URL's query, and claimant-supplied content on Countersign's own pages, do not count as evidence. Anonymous claims (no API key) are self_declared. Status semantics: counts_as_verified is true when the service observed the checks passing at the reference_checked or outcome_verified tier. Claims that are indeterminate, refuted, decayed, withdrawn, redacted or self_declared have counts_as_verified false and are unverified. Check params: {"http":"{url, status?=200, contains? (string, or array: ALL must appear), not_contains? (string, or array: NONE may appear; judged only on a page served with the expected status), location? (with a 3xx status: Location prefix; 3xx is then not followed), body_sha256? (64 hex: sha256 of the body as served must equal it, e.g. curl -s URL | sha256sum), role?: "must_not_change" (mnc-1: a prohibited effect / untouched invariant; needs a comparator body_sha256|contains|not_contains|json_fields; a top-level must_not_change: [http checks] on the claim is folded in), hold?: "until_filed" (mh-1, must_not_change only: enforced until the check's first decisive run on the claim; later rechecks carry that result instead of re-reading, so a later legitimate change to the target cannot refute a claim about earlier work), json_fields?:[{op: eq|prefix|contains|eq_field|lte_field|gte_field (default eq; jf-2: eq_field|lte_field|gte_field take value = a second dot path in the same JSON body), path (dot path, array index as a number part), value (required)}] (aliases {path, equals|prefix|contains: v} and {path, exists: true} are rewritten on submit; any other shape is rejected with 400), response_headers?: [{name, op?: eq|contains|not_contains|exists|not_exists, value?}] (hf-1: case-insensitive HTTP response header assertions), html_checks?: [{selector, op?: eq|contains|not_contains|prefix|exists|not_exists, value?, attr?}] (dom-1: structured HTML/DOM selector, , canonical link, and meta:<name|property> checks with HTML comments stripped), max_age_s? (hf-1: positive seconds; checks Last-Modified or freshness_header?: last-modified|date age <= max_age_s), max_ms?, timeout?, allow_redirect_hosts?: [host]}. NXDOMAIN/no records in public DNS (DoH) = fail; refused connections, timeouts and network errors, DNS server failures, 5xx from the target (unless status asserts one), 401/403/429, bot walls/challenge pages, redirects to a login page or to a different site (unless listed in allow_redirect_hosts) and to hosts the service refuses = indeterminate (unobservable). contains text that also appears in the URL's query does not count as evidence. A 404 from a GitHub file URL (raw.githubusercontent.com, or github.com///blob|tree|...) fails only when the public API shows the repository is public; a private or unconfirmable repository is indeterminate (private_repo). Unknown fields are refused on submit with 400 and a did-you-mean hint (uk-1).","dns":"{host, expect?} public DNS via DoH (dns.google, fallback cloudflare). NXDOMAIN or no A/AAAA/CNAME = fail. Unknown fields are refused on submit with 400 and a did-you-mean hint (uk-1).","tls_cert":"{host, port?=443, min_days?=7} trusted chain, hostname match, not expiring within min_days. Unknown fields are refused on submit with 400 and a did-you-mean hint (uk-1).","github_pr":"{repo: owner/name, number, state?: open|closed|merged, head_sha?, merge_gate?: true} public GitHub REST API. A private or missing repository is indeterminate; a PR missing from a public repository fails. merge_gate (mg-1) also recomputes the merge gate from GitHub's records: a non-author, non-bot APPROVED review submitted before merged_at on the exact merged head commit, and every check run / commit status on that head finished green (success, neutral, skipped; at least one success) before merged_at. Fails with merge_gate.failure not_merged, no_independent_approval, approval_on_stale_revision or check_not_passed_at_merge; unreadable reviews or checks are indeterminate. The required-check list (admin-only) is not read. Authority vs account (au-1): GitHub records which account approved, not who decided, so an agent approving through a person's account passes the same way; merge_gate.approver_basis is "github_account" and decision_authority "not_checked". Unknown fields are refused on submit with 400 and a did-you-mean hint (uk-1).","git_public":"{url: https git remote, ref?, commit?} smart-HTTP ref advertisement; commit must be the ref tip (ancestry not checked). Unknown fields are refused on submit with 400 and a did-you-mean hint (uk-1).","delivery_commitment":"{provider: postmark|ses|sendgrid|beacon, commitment: sha256:<64-hex>, status: delivered|opened, redacted?, target_commitment?, assertions?} (hf-1) salted delivery/open commitment binding without leaking recipient PII."}

Input Schema

NameRequiredDescriptionDefault
checksYesPublic checks; see description for params
privacyNofp-1 (fleet roles): claims on subjects not on GET /v1/privacy/public-hosts are private by default (unlisted, csc-1 committed); commit: also commit an allowlisted or visibility public claim
subjectYesWhat the claim is about (domain, repo, URL)
authz_refNoaz-1 optional hash commitment of the request or plan you were authorized to carry out: "sha256:<64 hex>" or { digest, scheme?, policy_id? }. Never send the plan itself. It is committed into the claim digest, so every receipt binds it; whoever authorized the plan can find this claim by searching claims with authz_ref set to sha256:<hex> and compare the outcome. Countersign does not check the authorization itself
statementYesThe claim in one sentence
depends_onNocd-1 child claims: up to 20 existing claim ids (csh-...) this parent claim depends on, e.g. the teammate claims a coordinator is rolling up. Set once at filing, not part of claim_digest. get_status then carries children {total, verified, failing, pending, all_verified, items}; advisory, the verdict is unchanged. Say the parent is done only when counts_as_verified and children.all_verified are both true
supersedesNoOptional id of your older claim to retire in favour of this one
visibilityNounlisted: kept out of search, listings and track-record pages; reachable by id
evidence_tierNoOptional; can only lower the derived tier
must_not_changeNomnc-1 prohibited effects: http targets that must NOT change as a side effect of the work, each with body_sha256 (sha256 of the body now) or contains / not_contains / json_fields. Folded into checks (role must_not_change); a change fails the claim
privacy_reviewedNoSet only if a flagged name is a business or public figure (claims are public: use neutral subjects, never private individuals)
supersede_reasonNoReason recorded on the superseded claim's withdraw receipt
supersedes_latestNoAutomatically find and supersede your latest active claim with the same subject
supersedes_latest_tagNoAutomatically find and supersede your latest active claim with the same subject and tag substring

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior1/5

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

The description explicitly says 'Record a claim', which is a write operation. The annotations declare readOnlyHint: true. This is a direct contradiction: the tool records data while annotated as read-only. Per the rules, this makes behavioral transparency 1 and triggers an annotation contradiction flag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a very long wall of text. It starts with a useful summary but then dumps extensive parameter and edge-case details with little structure. While complex, it is not front-loaded or scannable, and many sentences are hard to parse.

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?

The description covers many behavioral details, return fields, and parameter semantics, which is necessary for this complex tool. However, the serious annotation contradiction about read-only behavior creates confusion, and the overwhelming density reduces completeness for an agent trying to use it 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 description coverage is 100%, so the baseline is 3. The description adds substantial meaning beyond the schema by documenting check parameter shapes, semantics for each check type, and edge cases like indeterminate outcomes. It is dense but valuable, so it rises above baseline.

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 clearly states the specific verb and resource: 'Record a claim and verify it now with public checks.' It also lists the response fields. However, it does not explicitly differentiate this tool from siblings like verify_claim or file_deploy_claim, so it falls short of a 5.

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 clear context for when to use the tool: to record a claim with public checks that would fail if the statement were false. It references suggest_checks for proposing checks and pin_before_work for baselines. But it never explicitly says when not to use it or how it differs from verify_claim, so it lacks full alternative routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources