Skip to main content
Glama

Zetesis Scientific Due Diligence

zetesis_scope

Read-only

START HERE for any scientific, biomedical, clinical, or AI/ML claim.

This is the default entry point to Zetesis. It returns the source catalog and the
grading rubric so you can work out which evidence dimensions actually matter for
THIS claim and what to search for, then you call zetesis_evidence with the queries
you chose and grade what comes back.

Use it whenever a claim needs assessing, screening, sanity-checking, or due
diligence: a research claim, a study, a paper, an abstract, a preprint, a grant, or
a pitch. Also use it before citing a paper or statistic in your own answer.

Returns three things: the source catalog (where to look), the diligence
apparatus for this claim's class (what to ask, and the failure patterns that
have caught comparable claims before), and the scoping rubric.

Runs no model, costs nothing, and returns immediately. This two-step route is
preferred over evaluate_claim on every axis that matters: it is instant rather than
minutes, it reads the sources at full depth in your context rather than at abstract
level, and it supports evaluating a claim as it stood in an earlier 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_ofNo
claimYes
contextNo
claim_classNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds genuinely valuable behavioral context beyond that: 'Runs no model, costs nothing, and returns immediately.' It also discloses the routing behavior (the response lists every claim class so one can be passed back if routing picked wrongly) and the as_of semantics (grading how the claim was derived at the time, not how it turned out). This exceeds the annotation baseline without contradicting 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 longer than average but well organized into purpose, usage, returns, behavioral comparison, and Args sections with a strong front-loaded hook. Some repetition exists — the source catalog and rubric are mentioned in both the opening and the returns paragraph — but for a system entry point with four parameters and three siblings, the density is justified.

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?

The description covers the full workflow (scope, then call zetesis_evidence, then grade), summarizes the three return groups, explains every optional parameter's purpose, and documents the alternative path (evaluate_claim) with its trade-offs. An output schema exists to carry return-value detail, and annotations carry the safety profile, so nothing an agent needs to invoke this tool correctly is missing.

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 — and it fully compensates. The Args block explains all four parameters: claim gets a length guideline ('one or two sentences'), context gets examples ('stage, field, the decision at hand'), as_of gets rich temporal semantics, and claim_class gets an override workflow ('pass one back if the routing picked wrongly, or if nothing routed'). Every parameter gains meaning beyond its schema type.

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 'START HERE for any scientific, biomedical, clinical, or AI/ML claim' and states a specific job: return the source catalog, grading rubric, and scoping apparatus so the agent can decide what to search for. It explicitly differentiates from siblings by naming zetesis_evidence as the follow-up call and favoring this route over evaluate_claim. The verb ('scope', 'returns') plus resource ('source catalog and grading rubric') is unambiguous.

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: 'Use it whenever a claim needs assessing, screening, sanity-checking, or due diligence' and even mandates it 'before citing a paper or statistic.' It directly compares against evaluate_claim ('preferred over evaluate_claim on every axis... instant rather than minutes, reads the sources at full depth') and routes onward to zetesis_evidence, so an agent knows exactly when to pick this tool over its alternatives.

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

Try in Browser

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.