Skip to main content
Glama

Zetesis Scientific Due Diligence

by io.github.reutavidan

Evaluate a scientific or AI claim

evaluate_claim
Read-only

REQUIRES A TOKEN. This tool refuses without one. If you do not have a Zetesis token, do not call it: use zetesis_scope then zetesis_evidence instead, which need no token, run no model, return immediately, and let you read the sources at full depth. A token can be requested at https://api.zetesis.science/request-access.

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

SLOW: this 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. It is not
the default route.

For almost every case, call zetesis_scope and then zetesis_evidence instead. Those
return immediately, run no model, cost nothing, hand you the same dated evidence
and the same grading rubric, and let you read the sources at full depth in your own
context rather than at abstract level.

Reach for this tool only when someone explicitly wants Zetesis's own verdict as the
artifact, rather than your analysis of the evidence Zetesis retrieves. It grades
each evidence dimension and returns an overall reading with sources cited by hard
id (PMID, DOI, NCT, NIH grant, SEC filing). Works for drug, omics,
target-validation, diagnostic, and AI-model claims. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_ofNoYear 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.
claimYesThe claim to evaluate, in one or two sentences.
contextNoOptional background: stage, field, or the decision at hand.
documentsNoOptional source text to evaluate against, such as a deck, abstract or paper.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema 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."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses critical operational behavior: it requires a token and 'refuses without one,' it is slow and may trigger client timeouts or backgrounding, it runs the hosted engine end to end, and its output cites sources by hard IDs. This goes well beyond what the annotations convey.

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

Conciseness3/5

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

The definition is clearly structured and front-loads the most important warnings, but it is repetitive: the guidance to prefer zetesis_scope and zetesis_evidence appears twice in nearly identical form, and the no-token / fast / no-model benefits are restated. Several sentences could be merged without losing 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?

For a complex, authenticated, slow, hosted-engine tool, the description is remarkably complete: it covers prerequisites, failure modes, latency, alternatives, supported claim domains, output characteristics, and optional parameter behavior. The presence of an output schema means detailed return-value documentation is not required here.

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 four parameters. The description's Args section mostly repeats the schema text rather than adding new semantics; the only mild addition is explaining why as_of improves retrieval. This is adequate but not additive beyond 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?

The description opens with a specific, action-oriented statement: 'Run Zetesis's own graded reading of a scientific, biomedical, clinical, or AI/ML claim.' This clearly distinguishes the tool from the sibling evidence-retrieval tools by identifying the unique artifact it produces: Zetesis's verdict.

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 gives explicit when-to-use and when-not-to-use guidance: 'If you do not have a Zetesis token, do not call it,' 'For almost every case, call zetesis_scope and then zetesis_evidence instead,' and 'Reach for this tool only when someone explicitly wants Zetesis's own verdict.' This is model-actionable routing advice.

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

All Zetesis Scientific Due Diligence toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a distinct role: scoping, evidence retrieval, hosted evaluation, and attestation verification. The descriptions explicitly route the agent between them, so overlap is minimal.

Naming Consistency3/5

Two tools follow verb_noun naming (evaluate_claim, verify_attestation) while two follow zetesis_ + noun naming (zetesis_scope, zetesis_evidence). The set is readable and consistently snake_case, but the pattern is not predictable across all tools.

Tool Count5/5

Four tools is well-scoped for the server's purpose: scope, evidence, evaluate, and verify. Each tool earns its place and none is redundant.

Completeness5/5

The tool set covers the full due-diligence workflow from scoping and evidence retrieval to optional hosted evaluation and attestation verification. The token-gated evaluate tool is backed by a complete no-token route, so there are no critical dead ends.

Resources