Skip to main content
Glama

verify_report

Read-onlyIdempotent

Checks a report before acceptance by verifying linked quotes verbatim against source bytes and validating ⚓ anchors in repos, GitHub, or session transcripts; returns a FAIL/GAPS/PASS/EMPTY receipt.

Instructions

Check a report before accepting or passing it on: every quote must be in the bytes of the source it links to (verbatim), every ⚓ anchor must hold in the repos, on GitHub (pr:, ci:) or in the session transcript (run:). Returns a receipt with outcome FAIL / GAPS / PASS / EMPTY, the blocking items and a one-line summary. Only quotations in quotation marks with a link to their page in the same sentence, and ⚓ anchors in backticks, are checked: write e.g. Article 2.10 says «Юридическое лицо, присоединившее другое юридическое лицо, подлежит ответственности» (КоАП РФ, ст. 2.10). EMPTY means nothing was checkable, not that the text is right.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "verify_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoa Markdown file to check instead of text
textNothe report itself (Markdown); or give path
fetchNosnapshot cited URLs not in the store yet
reposNorepo checkouts for anchors (default: the git repo at or under the server's cwd; in Codex none, so pass the workspace path)
storeNosnapshot store (default $VERBATIM_STORE or ./.verbatim)
accessNoverbatim --access for unreadable pages, e.g. 'default'
checksNocustom: these checks (quote, number, file_anchor, commit_anchor, fact_anchor, pr_anchor, ci_anchor, run_anchor, choice_anchor, work_claim, other_anchor, env_anchor)
detailNothe text of the result: concise (the summary line and only the items to fix) or full (the whole receipt as JSON). The structured result is the whole receipt either way.concise
githubNoask GitHub for pr:/ci: anchors and strict GitHub citation sources
modulesNocustom: these verification modules: sources (quotes, numbers), github (repo anchors, pr:, ci:), execution (run:, choice:, work claims), environment (env: anchors against this machine)
numbersNoa number of a cited sentence not in its source: gap, fail or offgap
profileNowhat to check (default: everything): developer (repo, PR, CI, run: and work claims), research (quotes and numbers), complete, or custom with modules and/or checks. What a profile leaves out is not checked, and the result says so
receiptNoreceipt contract of the result: v0 (default) or v1, which also says what was checked, what was not and why (scope, coverage)v0
transcriptNoClaude Code session jsonl for run: anchors

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.0.8
    • changedInput schema / properties / checks / description
      Previous value: -"custom: these checks (quote, number, file_anchor, commit_anchor, fact_anchor, pr_anchor, ci_anchor, run_anchor, choice_anchor, work_claim, other_anchor)"New value: +"custom: these checks (quote, number, file_anchor, commit_anchor, fact_anchor, pr_anchor, ci_anchor, run_anchor, choice_anchor, work_claim, other_anchor, env_anchor)"
    • addedInput schema / properties / detail
      Added value: +{
      +  "default": "concise",
      +  "description": "the text of the result: concise (the summary line and only the items to fix) or full (the whole receipt as JSON). The structured result is the whole receipt either way.",
      +  "enum": [
      +    "concise",
      +    "full"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / modules / description
      Previous value: -"custom: these verification modules: sources (quotes, numbers), github (repo anchors, pr:, ci:), execution (run:, choice:, work claims)"New value: +"custom: these verification modules: sources (quotes, numbers), github (repo anchors, pr:, ci:), execution (run:, choice:, work claims), environment (env: anchors against this machine)"
    • changedInput schema / properties / modules / items / enum
      Previous value: -[
      -  "sources",
      -  "github",
      -  "execution"
      -]New value: +[
      +  "sources",
      +  "github",
      +  "execution",
      +  "environment"
      +]
  2. Changed1 schema field changedv2.0.4
    • changedInput schema / properties / github / description
      Previous value: -"ask GitHub for pr:/ci: anchors"New value: +"ask GitHub for pr:/ci: anchors and strict GitHub citation sources"
  3. Changed4 schema fields changedv1.1.1
    • addedInput schema / properties / checks
      Added value: +{
      +  "description": "custom: these checks (quote, number, file_anchor, commit_anchor, fact_anchor, pr_anchor, ci_anchor, run_anchor, choice_anchor, work_claim, other_anchor)",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / modules
      Added value: +{
      +  "description": "custom: these verification modules: sources (quotes, numbers), github (repo anchors, pr:, ci:), execution (run:, choice:, work claims)",
      +  "items": {
      +    "enum": [
      +      "sources",
      +      "github",
      +      "execution"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / profile
      Added value: +{
      +  "description": "what to check (default: everything): developer (repo, PR, CI, run: and work claims), research (quotes and numbers), complete, or custom with modules and/or checks. What a profile leaves out is not checked, and the result says so",
      +  "enum": [
      +    "developer",
      +    "research",
      +    "complete",
      +    "custom"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / receipt
      Added value: +{
      +  "default": "v0",
      +  "description": "receipt contract of the result: v0 (default) or v1, which also says what was checked, what was not and why (scope, coverage)",
      +  "enum": [
      +    "v0",
      +    "v1"
      +  ],
      +  "type": "string"
      +}
  4. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds value beyond them: the receipt shape, the four outcome codes, the EMPTY edge case, that a profile silently excludes checks while the result says so, and that cited URLs may be snapshotted (network side effect via fetch/openWorld). It does not discuss cost, rate limits, or failure modes of the network fetches.

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: what is checked, then what is returned, then the input contract with a worked example. Dense but every sentence carries information; the inline Russian citation example is long but is the only place the required markup is demonstrated, so it earns its space.

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 14-parameter, zero-required tool with no output schema, the description covers the outcome vocabulary and the checkable-input rule, which are the two things an agent must know to call it correctly. Gaps remain around how path and text interact when both are given, and default scoping, but those are documented in the schema.

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 coverage is 100%, so the baseline is 3, but the description contributes the markup contract the schema never states: which quotes and which anchors are actually checked and the exact inline syntax required. It also clarifies the practical consequence of profile ('what a profile leaves out is not checked') and of receipt v1 versus v0.

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 ('Check a report before accepting or passing it on') and enumerates exactly what is verified: verbatim quotes against linked sources, ⚓ anchors in repos, GitHub pr:/ci:, and run: transcript anchors. The named outcome codes (FAIL/GAPS/PASS/EMPTY) further pin down what the tool produces, and no sibling (snap, source_text, environment_snapshot) does anything comparable.

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?

Gives a clear situational trigger ('before accepting or passing it on') and defines what input is checkable: quotes in quotation marks with a same-sentence link, and ⚓ anchors in backticks. It also warns that EMPTY means nothing was checkable, not that the text is right. It stops short of naming alternatives or stating when not to run it, but the sibling set makes that low-stakes.

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