Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

TARGET Checklist MCP

PYPI · TARGET-MCP · SCANNED SEP 20

Score how completely a target-trial-emulation study reports what the TARGET guideline requires.

Available components

−12 this week 62 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security50
  • Malware scan not yet available for this package.Unverified
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs setuptools.build_meta at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
  • 2 of 49 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency32
Schema Quality & AI Usability66
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 3021 tokens (~274/item across 11 items; 11 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management93
  • Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage71
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 0% of tool parameters carry a description.Fail
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 11 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 12 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

How do I install the TARGET Checklist MCP server?

TARGET Checklist MCP runs locally as a PyPI package, launched with uvx target-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

pypi · target-mcp

# add to Claude Code
claude mcp add com-blackswancausallabs-target-mcp -- uvx target-mcp
// .cursor/mcp.json
{
  "mcpServers": {
    "com-blackswancausallabs-target-mcp": {
      "command": "uvx",
      "args": [
        "target-mcp"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "com-blackswancausallabs-target-mcp": {
      "command": "uvx",
      "args": [
        "target-mcp"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add com-blackswancausallabs-target-mcp -- uvx target-mcp
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-blackswancausallabs-target-mcp": {
      "type": "local",
      "command": [
        "uvx",
        "target-mcp"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add com-blackswancausallabs-target-mcp --command uvx --arg target-mcp
# ~/.hermes/config.yaml
mcp_servers:
  com-blackswancausallabs-target-mcp:
    command: "uvx"
    args: ["target-mcp"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "com-blackswancausallabs-target-mcp": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "target-mcp"
      ]
    }
  }
}
# add to Vellum
assistant mcp add com-blackswancausallabs-target-mcp -t stdio -c uvx -a target-mcp
// mcp.json
{
  "mcpServers": {
    "com-blackswancausallabs-target-mcp": {
      "command": "uvx",
      "args": [
        "target-mcp"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 19 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.

  • 17 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.

  • 15 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.

  • 14 Sept 26 −15
    • Malware scan: pass → unverified security
  • 13 Sept 26 +16
    • Malware scan: unverified → pass security
  • 11 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.

  • 9 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.

  • 7 Sept 26 −15
    • Malware scan: pass → unverified security
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 20 Sept 2026 · Analysed pypi/target-mcp@0.2.0

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem pypi

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend allowlisted setuptools.build_meta

Background: Why install scripts are a supply-chain risk →

Dependencies 49 packages
Packages resolved 49
Stale 1
No linked repository 1
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 11 exposed · ~2,673 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
aggregate_corpus ~101

Roll up many assessments into per-item completeness rates plus coverage denominators (supplement-retrieval status, full-text availability, evidence- resolution rate). Pass an array of assessment objects as `assessments`, or use_session=true to aggregate every assessment produced this session. The completeness rates are only as valid as the sample and are not yet gold-standard calibrated.

NameTypeReqDescription
assessments
use_sessionboolean
NameTypeReqDescription
coverageobject
lowest_reported_leavesarray
n_papersinteger
notestring
per_leafarray
spec_versionstring

No examples provided.

assess_manuscript ~261

Assess a manuscript against all applicable TARGET leaves in one batched pass. `document` is a path, raw text, or a text_sha256 returned by parse_manuscript. mode='scaffold' (default) is the path for reviewing a publication: you are the LLM in the loop, so the server returns the exact assessment prompt, the tool schema, and a prompt hash for YOU to execute — read the manuscript against the rubric, produce the verdicts, then call submit_scaffold_verdicts to validate them and get the stamped result (evidence resolved to spans, provenance, ready for render_checklist). mode='judge' is for the headless/batch case where no LLM is in the loop (e.g. a corpus run). The server makes its own pinned-model API call (requires ANTHROPIC_API_KEY) so scoring is reproducible and caller- independent, and returns the full verdict matrix directly. Overkill when an agent is already reviewing the paper interactively.

NameTypeReqDescription
documentstringyes
manuscript_idstring
modestring
modelstring
spec_versionstring

Structured output declared, but exposes no named fields.

No examples provided.

build_coding_sheet ~105

Emit blank per-paper coding sheets for human gold-standard coding: one row per applicable leaf with its intent and verdict boundaries and empty verdict/evidence/note fields. blind=true (default) withholds the instrument's verdict so coders are not anchored — use blind coding for the primary reference standard. Pass `assessments` or use_session=true.

NameTypeReqDescription
assessments
blindboolean
use_sessionboolean
NameTypeReqDescription
resultarrayyes

No examples provided.

get_checklist ~152

Return the encoded TARGET checklist spec: 39 scoreable leaf subitems (grouped into the 21 published items) with intent, assessor notes, signal terms, pairing links, and applicability rules. Pass a version id to pin; omit for the current default. OPTIONAL in the review flow — introspection only. assess_manuscript already embeds the full per-leaf rubric (intents + verdict boundaries) in the prompt it returns, so calling both get_checklist and assess_manuscript for the same review duplicates the rubric payload. Use this when you want to inspect the spec on its own, not as a required step before assessing.

NameTypeReqDescription
versionstring
NameTypeReqDescription
available_versionsarray
e_e_statusstring
evidence_policystring
guideline_scopestring
itemsarray
leaf_countinteger
spec_versionstring
verdict_vocabularyarray

No examples provided.

parse_manuscript ~586

PRIMARY entry point: parse a manuscript into a SectionMap with character-offset, source-tagged section spans. PASS `citation=`: the manuscript's full bibliographic reference in APA style (authors, year, title, journal, volume(issue), pages, DOI). It is carried into the assessment and displayed on every rendered checklist so the assessed publication is unambiguous — without it, renders can only show the short manuscript_id. You have the paper in hand; format the reference from its title page. `document` is EITHER the raw manuscript text OR a file path — but the path must be readable on the SERVER host. If you are an agent whose uploaded files live on your own filesystem (a mounted upload dir, a sandbox), the server cannot see them: paste the manuscript TEXT instead, or use parse_pmcid for an open-access PMCID. Reach for a file path only when the file is on the same host as this server (server-local/batch use). A path-looking string that the server can't find raises rather than being silently ingested as its own text. `supplements` is a list of server-readable file paths (PDF/docx/text) to merge as supplementary material — PASS IT WHEN YOU HAVE IT: TTE methods (estimand, identifying assumptions) frequently live in a supplementary protocol table, and without a supplement the verdicts on those leaves come back not_reported when the content was merely in an un-ingested appendix. When supplements are provided, supplement_status defaults to 'user_provided'. Pass supplement_status='none_exists' to assert the article has no supplement. `section_hints` is a LAST RESORT for a section the detector cannot find: {'introduction': 6543} splits whatever section contains that character offset. Some journals print no heading for a section (an introduction that simply follows the abstract) and interpose prose — a lay-summary box — that no structural rule can tell apart from the section itself; check the warnings for 'may have swallowed an unheaded introduction'. A hint never edits…

NameTypeReqDescription
citationstring
documentstringyes
manuscript_idstring
section_hints
supplement_statusstring
supplements
NameTypeReqDescription
citationstring
documentsarray
extractor_versionstring
flow_diagram_detectedboolean
full_textstring
manuscript_idstring
n_pages
protocol_table_detectedboolean
sectionsarray
sourcestring
supplement_statusstring
text_sha256string
warningsarray

No examples provided.

parse_pmcid ~248

CONVENIENCE / BATCH entry point: retrieve an open-access article from Europe PMC by PMCID and parse it. Reach for this in the corpus/batch case (no file in hand) or to auto-fetch an open-access paper's supplement; for a single manuscript you were given, use parse_manuscript instead. Fetches JATS main text plus (if available) PMC-hosted supplementary files, merged into one source-tagged SectionMap. supplement_status is 'retrieved' when a supplement was obtained, else 'not_retrieved' (a supplement may still exist on the publisher site; absence of retrieval is not proof of absence). Raises if no open-access full text is available. Returns the same summary as parse_manuscript, including the text hash for assess_manuscript. An APA-style `citation` is auto-built from the article's JATS metadata and displayed on every rendered checklist; pass citation= to override it (e.g. when the auto-built reference is incomplete).

NameTypeReqDescription
citationstring
include_supplementsboolean
pmcidstringyes
NameTypeReqDescription
citationstring
documentsarray
extractor_versionstring
flow_diagram_detectedboolean
full_textstring
manuscript_idstring
n_pages
protocol_table_detectedboolean
sectionsarray
sourcestring
supplement_statusstring
text_sha256string
warningsarray

No examples provided.

render_checklist ~176

Render a finalized assessment as the completed TARGET checklist form: the 21 published items (39 leaf rows, in checklist order) with the published item wording and a Location-reported column derived from the resolved evidence spans. The default enriched view adds, per leaf, the instrument's verdict and the verbatim evidence quote that justifies the location; view='official' strips to the published form's columns (Item / Checklist item / Location reported). Returns structured rows, a completeness tally, and a ready-to-display Markdown table. Pass either a full `assessment` object or the `manuscript_id` of one assessed earlier this session. This is a pure projection — no re-scoring.

NameTypeReqDescription
assessment
manuscript_idstring
viewstring
NameTypeReqDescription
attributionobject
citationstring
completenessobject
generated_fromobject
htmlstring
manuscript_idstring
markdownstring
provenanceobject
rowsarray
spec_versionstring
supplement_statusstring
viewstring

No examples provided.

render_checklist_docx ~328

Write the completed TARGET checklist to a Word (.docx) file and return it. Same content as render_checklist (published item wording + a Location-reported column from the resolved evidence spans; enriched view adds verdict and evidence), serialized as a submission-ready landscape table, one per manuscript section. Pass a full `assessment` object or the `manuscript_id` of one assessed this session. view='official' strips to the published form's three columns. RETRIEVING THE FILE: the return carries the document bytes as base64 in `content_base64` (with `content_type` and `filename`) — decode and save these to get the deliverable. The file is ALSO written to `path` on the server host, but that filesystem is not the caller's: if you are an agent whose files live elsewhere, use `content_base64`, not `path`. `path` defaults to a writable temp dir and is only directly useful for server-local/batch runs. logo=True heads the document with the published TARGET banner, but ONLY on view='official' (the author's self-report form); on the enriched view it is ignored and the returned `logo_applied` is False, because the official mark on a machine-generated assessment would imply an endorsement the instrument does not carry. Default off.

NameTypeReqDescription
assessment
logoboolean
manuscript_idstring
pathstring
viewstring
NameTypeReqDescription
bytesinteger
content_base64string
content_typestring
filenamestring
logo_appliedboolean
n_rowsinteger
pathstring
viewstring

No examples provided.

render_checklist_html ~165

Render the completed TARGET checklist as a self-contained HTML page — same content as render_checklist, styled to the Black Swan Causal Labs identity (canvas ground, one aligned table, verdict pills), viewable in any browser on any host. Returns the HTML string in `html` (show it inline or publish it as an artifact) and the same bytes as base64 in `content_base64` (decode and save as an .html file). Carries the provenance `stamp`. Pass a full `assessment` object or the `manuscript_id` of one assessed this session; view='official' strips to the published form's three columns.

NameTypeReqDescription
assessment
manuscript_idstring
viewstring
NameTypeReqDescription
content_base64string
content_typestring
filenamestring
htmlstring
manuscript_idstring
provenanceobject
viewstring

No examples provided.

submit_scaffold_verdicts ~429

Scaffold-mode completion: validate verdicts produced by the calling agent (leaf coverage, verdict vocabulary, mandatory verbatim evidence quotes resolved to spans) and return the stamped assessment TOGETHER WITH the finished, rendered deliverable. `items` is the verdict array from the forced tool call — one object per leaf with `id`, `verdict`, `confidence`, `rationale`, and (for reported/partial) `evidence_quotes`. THE ARTIFACT OF RECORD is in the returned `report` (by default the HTML form), carrying a provenance `stamp` bound to the ingested text and prompt. That stamped render is the ONLY canonical output — present it as the completed checklist. Need another format? Do NOT hand-assemble one: call render_checklist (markdown) or render_checklist_docx (.docx bytes) to re-render the same stamped artifact, or pass report_formats (any of 'html', 'markdown', 'docx') to include them here. The default is HTML only because every extra format flows through your context window. The `items` verdicts are an intermediate object; do NOT hand-assemble your own checklist document and present it as the assessment, because it will lack the stamp and cannot be verified. You MAY additionally write an analytic memo (prioritized gaps, an estimand-first reading), but label it as commentary and cite the stamp — never let it stand in for, or inherit the authority of, the stamped form. Set render=false to skip rendering (verdicts only). The parse cache does not survive a server restart; if `text_sha256` is no longer cached, pass `document` (the same path or text) to re-parse transparently.

NameTypeReqDescription
documentstring
itemsarrayyes
modelstring
renderboolean
report_formats
spec_versionstring
text_sha256stringyes
NameTypeReqDescription
assessed_atstring
citationstring
documentsarray
excluded_leavesarray
extractor_versionstring
full_text_availableboolean
itemsarray
manuscript_idstring
modestring
modelstring
prompt_hashstring
prompt_template_versionstring
report
section_rollupsobject
spec_versionstring
supplement_statusstring
temperature
text_sha256string
unresolved_evidence_leavesarray
usage

No examples provided.

validate_against_gold ~122

Compute per-leaf agreement between instrument assessments and human gold-standard codings: raw agreement, Cohen's kappa, Gwet's AC1, and binary (reported-vs-rest) sensitivity/specificity with the human coding as the reference standard, plus a span-keyed disagreement list for adjudication. Agreement is reported PER LEAF; the pooled figure is orientation only. Both arguments are arrays of assessment/coding objects sharing manuscript ids and spec version.

NameTypeReqDescription
human_codingsarrayyes
instrumentarrayyes
NameTypeReqDescription
disagreementsarray
leaves_with_datainteger
n_disagreementsinteger
n_papersinteger
papers_comparedarray
per_leafarray
pooled_binary_reported
pooled_raw_agreement
spec_versionstring

No examples provided.

Common questions

What is the TARGET Checklist MCP server?

TARGET Checklist MCP is listed in the public MCP registry as com.blackswancausallabs/target-mcp. Score how completely a target-trial-emulation study reports what the TARGET guideline requires. This page covers its PyPI package (target-mcp).

Is the TARGET Checklist MCP server safe to use?

TARGET Checklist MCP scores 62 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the TARGET Checklist MCP server expose?

TARGET Checklist MCP exposes 11 tools: get_checklist, parse_manuscript, parse_pmcid, assess_manuscript, submit_scaffold_verdicts, and 6 more. Their descriptions and schemas cost roughly 2,673 tokens of context every time the server is loaded.

Is the TARGET Checklist MCP server still maintained?

TARGET Checklist MCP is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.