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
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
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: no license is declared. See how to fix → Fail
- Actively maintained (last published 28 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
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
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
claude mcp add com-blackswancausallabs-target-mcp -- uvx target-mcp
{
"mcpServers": {
"com-blackswancausallabs-target-mcp": {
"command": "uvx",
"args": [
"target-mcp"
]
}
}
} {
"servers": {
"com-blackswancausallabs-target-mcp": {
"command": "uvx",
"args": [
"target-mcp"
]
}
}
} codex mcp add com-blackswancausallabs-target-mcp -- uvx target-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-blackswancausallabs-target-mcp": {
"type": "local",
"command": [
"uvx",
"target-mcp"
],
"enabled": true
}
}
} openclaw mcp add com-blackswancausallabs-target-mcp --command uvx --arg target-mcp
mcp_servers:
com-blackswancausallabs-target-mcp:
command: "uvx"
args: ["target-mcp"] {
"McpServers": {
"com-blackswancausallabs-target-mcp": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"target-mcp"
]
}
}
} assistant mcp add com-blackswancausallabs-target-mcp -t stdio -c uvx -a target-mcp
{
"mcpServers": {
"com-blackswancausallabs-target-mcp": {
"command": "uvx",
"args": [
"target-mcp"
]
}
}
} 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
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 →
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 →
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.
| Name | Type | Req | Description |
|---|---|---|---|
| assessments | – | – | – |
| use_session | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| coverage | object | – | – |
| lowest_reported_leaves | array | – | – |
| n_papers | integer | – | – |
| note | string | – | – |
| per_leaf | array | – | – |
| spec_version | string | – | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| document | string | yes | – |
| manuscript_id | string | – | – |
| mode | string | – | – |
| model | string | – | – |
| spec_version | string | – | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| assessments | – | – | – |
| blind | boolean | – | – |
| use_session | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| version | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| available_versions | array | – | – |
| e_e_status | string | – | – |
| evidence_policy | string | – | – |
| guideline_scope | string | – | – |
| items | array | – | – |
| leaf_count | integer | – | – |
| spec_version | string | – | – |
| verdict_vocabulary | array | – | – |
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…
| Name | Type | Req | Description |
|---|---|---|---|
| citation | string | – | – |
| document | string | yes | – |
| manuscript_id | string | – | – |
| section_hints | – | – | – |
| supplement_status | string | – | – |
| supplements | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| citation | string | – | – |
| documents | array | – | – |
| extractor_version | string | – | – |
| flow_diagram_detected | boolean | – | – |
| full_text | string | – | – |
| manuscript_id | string | – | – |
| n_pages | – | – | – |
| protocol_table_detected | boolean | – | – |
| sections | array | – | – |
| source | string | – | – |
| supplement_status | string | – | – |
| text_sha256 | string | – | – |
| warnings | array | – | – |
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).
| Name | Type | Req | Description |
|---|---|---|---|
| citation | string | – | – |
| include_supplements | boolean | – | – |
| pmcid | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| citation | string | – | – |
| documents | array | – | – |
| extractor_version | string | – | – |
| flow_diagram_detected | boolean | – | – |
| full_text | string | – | – |
| manuscript_id | string | – | – |
| n_pages | – | – | – |
| protocol_table_detected | boolean | – | – |
| sections | array | – | – |
| source | string | – | – |
| supplement_status | string | – | – |
| text_sha256 | string | – | – |
| warnings | array | – | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| assessment | – | – | – |
| manuscript_id | string | – | – |
| view | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| attribution | object | – | – |
| citation | string | – | – |
| completeness | object | – | – |
| generated_from | object | – | – |
| html | string | – | – |
| manuscript_id | string | – | – |
| markdown | string | – | – |
| provenance | object | – | – |
| rows | array | – | – |
| spec_version | string | – | – |
| supplement_status | string | – | – |
| view | string | – | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| assessment | – | – | – |
| logo | boolean | – | – |
| manuscript_id | string | – | – |
| path | string | – | – |
| view | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| bytes | integer | – | – |
| content_base64 | string | – | – |
| content_type | string | – | – |
| filename | string | – | – |
| logo_applied | boolean | – | – |
| n_rows | integer | – | – |
| path | string | – | – |
| view | string | – | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| assessment | – | – | – |
| manuscript_id | string | – | – |
| view | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| content_base64 | string | – | – |
| content_type | string | – | – |
| filename | string | – | – |
| html | string | – | – |
| manuscript_id | string | – | – |
| provenance | object | – | – |
| view | string | – | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| document | string | – | – |
| items | array | yes | – |
| model | string | – | – |
| render | boolean | – | – |
| report_formats | – | – | – |
| spec_version | string | – | – |
| text_sha256 | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| assessed_at | string | – | – |
| citation | string | – | – |
| documents | array | – | – |
| excluded_leaves | array | – | – |
| extractor_version | string | – | – |
| full_text_available | boolean | – | – |
| items | array | – | – |
| manuscript_id | string | – | – |
| mode | string | – | – |
| model | string | – | – |
| prompt_hash | string | – | – |
| prompt_template_version | string | – | – |
| report | – | – | – |
| section_rollups | object | – | – |
| spec_version | string | – | – |
| supplement_status | string | – | – |
| temperature | – | – | – |
| text_sha256 | string | – | – |
| unresolved_evidence_leaves | array | – | – |
| 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.
| Name | Type | Req | Description |
|---|---|---|---|
| human_codings | array | yes | – |
| instrument | array | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| disagreements | array | – | – |
| leaves_with_data | integer | – | – |
| n_disagreements | integer | – | – |
| n_papers | integer | – | – |
| papers_compared | array | – | – |
| per_leaf | array | – | – |
| pooled_binary_reported | – | – | – |
| pooled_raw_agreement | – | – | – |
| spec_version | string | – | – |
No examples provided.
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.