litcheck-mcp

check_quote

Verify whether a quoted passage appears in a paper's open-access PMC full text, reporting version, licence, and retraction status. Logs the check for an evidence trail.

Instructions

Check whether a quoted passage appears in the paper's pinned open-access PMC text.

Also reports the text's version, sha256 and licence, and the paper's retraction status, and appends an evidence line to the log. The text searched is PMC's whole plain-text file, header and reference list included, so check paragraph before attributing a FOUND passage to the paper. Exact substring match (word boundaries are not checked) after normalisation q1 (Unicode NFKC, straight quotes, one dash, collapsed whitespace; case kept). It does not judge whether the passage supports the claim.

Input Schema

TableJSON Schema

Name	Required	Description
`claim`	No	Optional: the claim you are citing this passage for, kept in the log
`quote`	Yes	The passage exactly as you would quote it (20 characters or more; shorter is TOO_SHORT when there is text to check)
`identifier`	Yes	One paper: a DOI ("10.1590/1516-3180.2016.1344090516" or a doi.org URL), a PMCID ("PMC10496602") or a PMID written with its cue ("PMID 27355798")

Output Schema

TableJSON Schema

Name	Required	Description
`claim`	Yes
`quote`	Yes
`reason`	Yes
`log_seq`	Yes
`verdict`	Yes	FOUND: the quote occurs, as a substring, in the pinned open-access text (which includes its metadata header and reference list; see paragraph). NOT_FOUND: it does not. TOO_SHORT: under 20 characters, not searched. NOT_CHECKABLE: no open-access text in PMC, PMC's copy missing, or the identifier was not found (see resolved.status and reason). UNVERIFIABLE: a source could not be read or verified, or litcheck failed (see reason); nothing was concluded.
`log_path`	Yes
`resolved`	Yes
`paragraph`	Yes	0-based index of the blank-line-separated block of the text
`identifier`	Yes
`retraction`	Yes
`pmc_outcome`	Yes
`pmc_version`	Yes
`text_md5_ok`	Yes
`text_sha256`	Yes
`license_code`	Yes
`normalisation`	Yes
`quote_offsets`	Yes	[start, end) of the match in the normalised text
`casefold_found`	Yes	The quote occurs when case is ignored

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 4, 2026

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses a side effect ('appends an evidence line to the log'), the exact matching semantics (substring, no word boundaries, after normalisation q1), the text scope searched, and the auxiliary facts returned (version, sha256, licence, retraction status). This is substantially more than a bare 'check' verb would convey.

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 with the core purpose, then layered with scope, semantics, and caveats in separate sentences. Slightly verbose with parenthetical detail about normalisation, but every sentence carries usable information.

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?

An output schema exists, so return values need not be spelled out, and the description still covers the write side effect, matching semantics, and the scope caveat needed to interpret a FOUND result correctly. Nothing an agent needs to call this safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters, giving a baseline of 3. The description adds only matching/normalisation context rather than new per-parameter meaning, so it does not rise above the baseline.

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 ('Check') and resource ('whether a quoted passage appears in the paper's pinned open-access PMC text'), which an agent can distinguish from siblings like retraction_status or record_support. The scope (PMC full plain-text file including header and references) is unusually precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear exclusion ('It does not judge whether the passage supports the claim') and warns to check `paragraph` before attributing a FOUND passage, which is implied usage guidance. However, it never states when to prefer this tool over siblings such as record_support or verify_log, so routing is left to inference.

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

Deploy Server