Skip to main content
Glama

Zetesis Scientific Due Diligence

by io.github.reutavidan

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_ofNo
claimYes
contextNo
documentsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.9/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 consequential behaviors: it requires a token and refuses without one, it is slow and may cause clients to time out, and it returns a graded reading with sources cited by hard IDs. These details are not available from annotations or schema and materially affect whether an agent should invoke it.

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 long but well structured, with upfront warnings about tokens and latency before the function's purpose. It contains some repetition about the alternative tools and their benefits, but each paragraph earns its place by addressing authentication, speed, when to use, arguments, and output characteristics.

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 tool with one required parameter, an output schema, and high behavioral complexity, the description is complete. It covers the required token, latency profile, fallback sibling workflow, exact argument semantics, supported claim domains, and expected output format, so an agent has enough context to decide and invoke correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden for parameter semantics. It compensates completely: claim is defined as 'the claim to evaluate, in one or two sentences'; context, documents, and as_of all receive concrete meanings, including the key temporal behavior of as_of restricting evidence to what existed in that year.

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 clearly states the tool's function: 'Run Zetesis's own graded reading of a scientific, biomedical, clinical, or AI/ML claim.' It uses a specific verb and resource, and it distinguishes itself from siblings by positioning zetesis_scope and zetesis_evidence as the default alternatives while this tool provides Zetesis's own 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 guidance: call this tool only when someone explicitly wants Zetesis's verdict as an artifact, and otherwise use zetesis_scope then zetesis_evidence. It also states a hard precondition: if no Zetesis token is available, do not call it. This leaves little ambiguity about tool selection.

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