Zetesis Scientific Due Diligence

Name: Zetesis Scientific Due Diligence
Author: reutavidan

by io.github.reutavidan

Overview Discussions Admin

Server Details

Due diligence on life-science claims: omics, trials, gene therapy. Dimension by dimension.

Ownership verified

Status: Healthy
Uptime: 100.0% over 23 days
Last Tested: 2026-09-23 15:50
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: reutavidan/zetesis
GitHub Stars: 0
Server Listing: zetesis

TDQS

A4.3/5.0

Scored 2026-09-14 18:25 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct phase: scoping, evidence retrieval, full evaluation, and attestation verification. Even though zetesis_scope and zetesis_evidence both return rubrics, their primary outputs and roles are unmistakably different.

Naming Consistency3/5

Two tools use verb_noun naming (evaluate_claim, verify_attestation) while two use a brand-prefixed noun pattern (zetesis_evidence, zetesis_scope). The names are readable and lowercase, but the mixed action-vs-resource style is not fully consistent.

Tool Count5/5

Four tools is well-scoped for a specialized claim-evaluation server. Each tool maps to a necessary part of the workflow without redundancy or bloat.

Completeness4/5

The core pipeline is covered: scope a claim, gather evidence, evaluate, and verify attestations. The main gap is the lack of a way to manage or retrieve long-running evaluations, since evaluate_claim can time out in some clients.

Available Tools

4 tools

evaluate_claimEvaluate a scientific or AI claimA

Read-only

Inspect

Run Zetesis's graded reading of a scientific, biomedical, clinical, or AI/ML claim.

Grades each evidence dimension and returns an overall reading, with every source
cited by hard public id (PMID, DOI, NCT, NIH grant, SEC filing). Covers drug,
omics, target-validation, diagnostic, and AI-model claims.

Runs the hosted engine end to end and typically takes a couple of minutes, long
enough that some clients background or time out the call. The output is Zetesis's
own reading as a finished artifact. zetesis_scope and zetesis_evidence return the
same dated sources and the same grading rubric immediately and without running a
model, at full source depth rather than abstract level.

A signed, independently re-checkable dossier is available by request at the
Zetesis site.

Args:
    claim: the claim to evaluate, in one or two sentences.
    context: optional background (stage, field, the decision at hand).
    documents: optional source text (a deck, abstract, or paper).
    as_of: year the claim was made. Set it for any claim that is not brand new.
        It restricts evidence to what existed then, which both keeps later
        outcomes out of the reading and sharply improves what is retrieved: left
        open, a pivotal trial report competes with every paper published since
        and gets buried.

ParametersJSON Schema

Name	Required	Description
`as_of`	No	Year the claim was made. Set it for any claim that is not brand new: it restricts evidence to what existed then, which keeps later outcomes out of the reading and sharply improves what is retrieved.
`claim`	Yes	The claim to evaluate, in one or two sentences.
`context`	No	Optional background: stage, field, or the decision at hand.
`documents`	No	Optional source text to evaluate against, such as a deck, abstract or paper.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses that this runs an end-to-end hosted engine, can take minutes, and may be backgrounded or timed out by clients. It also clarifies that the output is Zetesis's own finished reading and adds the as_of temporal-restriction behavior, aligning with openWorldHint.

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?

The description is front-loaded with purpose, then alternates context, alternatives, and parameter guidance in a logical flow. It is longer than average, and the Args section partly repeats schema descriptions, but the extra latency warning and sibling differentiation justify the length.

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?

For a complex tool with an output schema and rich annotations, this description is remarkably complete: it covers what the tool returns, how long it takes, when to use sibling tools instead, and how to set as_of correctly. Nothing essential for selecting and invoking the tool is missing.

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 adds value beyond the schema. It explains claim length, gives concrete examples for context and documents, and enriches as_of with a vivid retrieval-burial example about pivotal trial reports being drowned out by later publications.

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?

The description opens with a specific action and resource: 'Run Zetesis's graded reading of a scientific, biomedical, clinical, or AI/ML claim.' It then clarifies what the tool produces—graded evidence dimensions, an overall reading, and hard public IDs for every source—so an agent can immediately distinguish it from the sibling evidence/scope tools.

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

Usage Guidelines5/5

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

The description explicitly names zetesis_scope and zetesis_evidence as alternatives that return the same grading rubric and dated sources immediately and without running a model. The latency warning ('typically takes a couple of minutes') further tells an agent when it might prefer those siblings or background the call.

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

verify_attestationVerify a Zetesis attestationA

Read-only

Inspect

Verify a Zetesis attestation, confirming an evaluation's claim, evidence, and conclusion have not been altered since it was signed. Use when someone has a Zetesis dossier or attestation and wants to independently re-check it.

Args:
    attestation_json: the full attestation object as JSON text.

ParametersJSON Schema

Name	Required	Description	Default
`attestation_json`	Yes	The full Zetesis attestation object, as JSON text.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already mark this as read-only and non-destructive, and the description adds meaningful behavioral context by explaining the integrity-check semantics: it confirms that the evaluation's claim, evidence, and conclusion have not been altered since signing. This goes beyond the annotations and clarifies what verification actually checks.

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

Conciseness5/5

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

The description is compact and front-loaded: the core purpose and verification semantics appear first, followed by a clear usage condition and a single parameter definition. Every sentence earns its place, with no filler or redundancy.

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 single-parameter tool with an output schema and read-only annotations, the description covers the essential context: what the tool does, when to use it, and what input is required. It could be slightly more complete by noting what a successful verification result looks like, but the output schema likely covers the return shape.

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%, and the description's Args section essentially restates the schema's parameter documentation ('the full attestation object as JSON text'). The description adds no new meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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?

The description uses a specific verb and resource: it verifies a Zetesis attestation and precisely states what is confirmed—that claim, evidence, and conclusion have not been altered since signing. This clearly differentiates it from sibling tools like evaluate_claim, zetesis_evidence, and zetesis_scope, which serve different purposes.

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 explicit context: use it when someone has a Zetesis dossier or attestation and wants to independently re-check it. It does not mention explicit exclusions or alternative sibling tools, but the stated use case is clear enough for an agent to select it appropriately.

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

zetesis_evidenceRetrieve dated public evidence for a claimA

Read-only

Inspect

Step 2 of a Zetesis evaluation. Runs the search queries against public evidence sources (Europe PMC, ClinicalTrials.gov, openFDA, and optionally NIH RePORTER and SEC EDGAR) and returns a deduplicated bundle where every source carries a hard public id, followed by the Zetesis grading rubric so you can grade the dimensions yourself.

With as_of set, retrieval is fenced to sources published, registered, or filed on or
before 31 December of that year, and two fields that leak later outcomes are
suppressed: a trial's present-day status, and FDA labels effective after the cutoff.
That makes it possible to judge a claim on what was actually knowable at the time.

Runs no model, costs nothing, and returns immediately. Takes the queries worked
out when the claim was scoped.

Args:
    queries: 3 to 6 short keyword phrases. Query 1 should be the bare name of the
        thing claimed about (a drug, compound code, model, or gene); query 2 that
        name plus at most two outcome words. Longer phrases retrieve commentary
        rather than the primary report.
        If the claim names no agent at all (a behaviour, diet, procedure, exposure
        or policy), anchor on the field's own technical term instead of the lay one
        ("time restricted eating", not "intermittent fasting"), pair it with the
        outcome as the field measures it, and allow one design word such as
        crossover or randomized in one later query. Without an entity name that
        design word is the only thing separating a trial report from a review of
        trial reports.
    as_of: optional cutoff year, as used in zetesis_scope.
    include_capital: also retrieve funding and public-filing signal.

ParametersJSON Schema

Name	Required	Description
`as_of`	No	Year the claim was made. Set it for any claim that is not brand new: it restricts evidence to what existed then, which keeps later outcomes out of the reading and sharply improves what is retrieved.
`queries`	Yes	Three to six short keyword phrases. Query 1 should be the bare name of the thing claimed about; query 2 that name plus at most two outcome words.
`include_capital`	No	Also retrieve funding and public filing signal from NIH RePORTER and SEC EDGAR.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description goes well beyond by revealing that it 'Runs no model, costs nothing, and returns immediately,' deduplicates results, and explains the as_of fencing that suppresses later-outcome fields. No contradiction with annotations.

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?

The description is front-loaded with the main purpose, then covers behavioral context suppressed fields and cost, and ends with an args section. It is long and dense, but every sentence carries substantive information, especially the query-building guidance.

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?

With an output schema present, the description need not restate returns; it covers sources, dedup behavior, ID assignment, grading rubric inclusion, temporal fencing, cost/speed, and parameter details. An agent has enough context to invoke the tool 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?

The schema already covers all parameters with descriptions, so the baseline is 3. The description adds substantial query-construction meaning: bare name first, outcome words second, technical vs lay terms, and design-word guidance. as_of is given the helpful pointer 'as used in zetesis_scope'.

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 a specific verb+resource: 'Runs the search queries against public evidence sources ... and returns a deduplicated bundle where every source carries a hard public id.' It positions itself as 'Step 2 of a Zetesis evaluation', but does not explicitly contrast itself with sibling tools like evaluate_claim or verify_attestation.

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?

Provides strong contextual guidance: it is Step 2, takes 'queries worked out when the claim was scoped,' and includes detailed instructions for constructing queries and setting as_of. However, it never explicitly says when not to use it or names alternatives such as zetesis_scope or evaluate_claim.

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

zetesis_scopeScope a claim for evaluationA

Read-only

Inspect

Scope a scientific, biomedical, clinical, or AI/ML claim for evaluation.

Returns three things: the source catalog, meaning where the evidence for this
claim class lives; the diligence apparatus for that class, meaning the questions
a domain reviewer asks and the failure patterns that have caught comparable
claims before; and the scoping rubric used to work out which evidence dimensions
bear on this particular claim and what to search for.

Applies to a research claim, a study, a paper, an abstract, a preprint, a grant or
a pitch, and to checking a paper or statistic before relying on it.

Runs no model, costs nothing, and returns immediately. The queries worked out from
its output are what zetesis_evidence takes as input. With as_of set, the apparatus
and rubric are framed for judging the claim as it stood at the end of that year.

Args:
    claim: the claim to evaluate, in one or two sentences.
    context: optional background (stage, field, the decision at hand).
    as_of: optional year. Set it to evaluate the claim as it stood at the end of that
        year, grading how it was derived at the time rather than how it turned out.
    claim_class: optional override for the routed claim class. The response lists
        every class; pass one back if the routing picked wrongly, or if nothing
        routed.

ParametersJSON Schema

Name	Required	Description
`as_of`	No	Year the claim was made. Set it for any claim that is not brand new: it restricts evidence to what existed then, which keeps later outcomes out of the reading and sharply improves what is retrieved.
`claim`	Yes	The claim to evaluate, in one or two sentences.
`context`	No	Optional background: stage, field, or the decision at hand.
`claim_class`	No	Optional override for the routed claim class. The response lists every class; pass one back if the routing picked wrongly.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already establish readOnlyHint and non-destructive behavior, and the description adds meaningful behavioral context: 'Runs no model, costs nothing, and returns immediately.' It also explains how as_of changes the framing of the returned apparatus and rubric, which goes beyond the structured annotations.

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?

The description is front-loaded with purpose, outputs, applicability, and cost, then uses a labeled Args section for parameter details. It is somewhat redundant with the schema's parameter descriptions, but the structure is scannable and every major section earns its place.

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?

Given the presence of an output schema, 100% schema coverage, and four well-documented parameters, the description is complete enough for an agent to select and invoke the tool correctly. It covers what the tool returns, what inputs matter, the as_of behavior, and how the outputs feed into zetesis_evidence.

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?

Input schema covers all parameters at 100%, so the baseline is 3. The description adds useful nuance beyond the schema: as_of is described as grading 'how it was derived at the time rather than how it turned out,' and claim_class includes the fallback 'or if nothing routed.' This extra guidance justifies a 4.

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?

The description names a specific action ('Scope a scientific, biomedical, clinical, or AI/ML claim for evaluation') and explicitly lists three concrete return artifacts: source catalog, diligence apparatus, and scoping rubric. It clearly establishes the tool as the front-end stage before zetesis_evidence, distinguishing it from the sibling evaluation and verification tools.

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 a clear applicability list ('a research claim, a study, a paper, an abstract, a preprint, a grant or a pitch') and pipeline guidance ('The queries worked out from its output are what zetesis_evidence takes as input'). It does not explicitly name alternatives like evaluate_claim or verify_attestation, but the sequencing and cost note make the intended use clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesSep 5, 2026

Changedevaluate_claim4 fields changed

addedInput schema / properties / as_of / description

Added value: +"Year the claim was made. Set it for any claim that is not brand new: it restricts evidence to what existed then, which keeps later outcomes out of the reading and sharply improves what is retrieved."

addedInput schema / properties / claim / description

Added value: +"The claim to evaluate, in one or two sentences."

addedInput schema / properties / context / description

Added value: +"Optional background: stage, field, or the decision at hand."

addedInput schema / properties / documents / description

Added value: +"Optional source text to evaluate against, such as a deck, abstract or paper."

Changedverify_attestation1 field changed
- addedInput schema / properties / attestation_json / description
```
Added value: +"The full Zetesis attestation object, as JSON text."
```

Changedzetesis_evidence3 fields changed

addedInput schema / properties / as_of / description

Added value: +"Year the claim was made. Set it for any claim that is not brand new: it restricts evidence to what existed then, which keeps later outcomes out of the reading and sharply improves what is retrieved."

addedInput schema / properties / include_capital / description

Added value: +"Also retrieve funding and public filing signal from NIH RePORTER and SEC EDGAR."

addedInput schema / properties / queries / description

Added value: +"Three to six short keyword phrases. Query 1 should be the bare name of the thing claimed about; query 2 that name plus at most two outcome words."

Changedzetesis_scope4 fields changed

addedInput schema / properties / as_of / description

Added value: +"Year the claim was made. Set it for any claim that is not brand new: it restricts evidence to what existed then, which keeps later outcomes out of the reading and sharply improves what is retrieved."

addedInput schema / properties / claim / description

Added value: +"The claim to evaluate, in one or two sentences."

addedInput schema / properties / claim_class / description

Added value: +"Optional override for the routed claim class. The response lists every class; pass one back if the routing picked wrongly."

addedInput schema / properties / context / description

Added value: +"Optional background: stage, field, or the decision at hand."

4 tool updatesSep 1, 2026
- First observedevaluate_claim
- First observedverify_attestation
- First observedzetesis_evidence
- First observedzetesis_scope

Related MCP Connectors

BioCosm A
io.github.nhoverte
Biotech intelligence for AI agents: drugs, targets, diagnostics, PoS estimates, and writeups.
Bioinformatics Biology & Medicine
132
phasefolio A
com.phasefolio
Biotech rNPV/PoS engine for AI agents. Signed exports, evidence register, asset landscape.
Bioinformatics Finance AI & Machine Learning
132
Stipple — Document Verification & Extraction A
sh.stipple
Document forensics: tamper/AI checks, fields, tables, identity, screening, tenders, citations.
Security Image & Video Processing
162
AmassOAuth
tech.amass
Linked life-science search: 40M+ papers, 1.2M+ trials, drugs, genes, FDA/EMA approvals, patents.
Bioinformatics Biology & Medicine
11

Related MCP Servers

genpark-study-methodology-bias
Research & Data
Alpha-Park
F
license
Not graded
quality
B
maintenance
Enables auditing scientific papers for methodological biases such as selection bias and p-hacking, and assessing citation credibility and research consensus.
Updated 17 days ago (2026-09-06 12:32 UTC)
8
-
BioPharma Sentinel
Biology & Medicine Research & Data
renga92
F
license
Not graded
quality
D
maintenance
High-strategic intelligence platform for life sciences that enables real-time clinical trial audits, competitive landscape mapping, regulatory cross-referencing, and financial milestone correlation using the Model Context Protocol.
Updated 7 months ago (2026-03-08 10:02 UTC)
-
biopharma-catalyst-mcp
Biology & Medicine Finance Research & Data
yesc97
A
license
A
quality
D
maintenance
Enables biopharma catalyst research by aggregating signals from ClinicalTrials.gov, PubMed, SEC EDGAR, openFDA, and Yahoo Finance, with a single tool to audit a ticker/drug combination and return a forensic verdict.
Updated 4 months ago (2026-05-11 03:33 UTC)
10
37 npm
5
ISC
andon
Testing & QA Tools Developer Tools
gulmezeren2-byte
A
license
Not graded
quality
A
maintenance
Deterministic verification for AI-generated analysis. Reconciliation, consistency and Excel-integrity checks that stop the line when the numbers don't add up.
Updated 2 months ago (2026-08-04 06:55 UTC)
1
MIT