Skip to main content
Glama

List findings

list_claims
Read-onlyIdempotent

Use this when the user asks what has been found about a relation: does an intervention extend lifespan, and in which organisms; what lowers a biomarker; what acts on a process. Lists findings extracted from papers as subject, relation and object (for example rapamycin extends_lifespan in Mus musculus), with organism, conditions, effect size and the paper, newest first. Narrow by subject, object, relation, organism or paper. Check a finding that matters against its paper with get_paper. Not for personal medical advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoResults per page, 1 to 25.
cursorNoOpaque cursor from `pagination.next_cursor` of the previous page. Keep the other parameters the same.
objectNoObject text, entity name or entity key (case-insensitive substring).
subjectNoSubject text, entity name or entity key (case-insensitive substring).
organismNoOrganism, e.g. Homo sapiens, Mus musculus (case-insensitive substring).
paper_idNoOnly claims from this paper.
relationNoExact relation, e.g. increases, decreases, associated_with, extends_lifespan.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed world), so the description's job is to add operational detail. It does: result ordering ('newest first') and the exact field set returned. It omits pagination/rate-limit behavior, but limit/cursor are schema-documented.

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?

Front-loaded with the triggering question, then result shape, then filtering, then the sibling hand-off and the exclusion. Dense but every clause carries a distinct instruction; the run-on opening sentence is the only mild structural weakness.

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 no output schema, the description carries the return-value burden and does so concretely, enumerating the fields of a claim and giving a worked example (rapamycin extends_lifespan in Mus musculus). For a 7-parameter, annotation-covered read tool, this is complete enough to call correctly.

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 defines every filter with examples and match semantics (case-insensitive substring vs exact relation). The description's 'Narrow by subject, object, relation, organism or paper' largely restates that, adding only the news-first ordering context. Baseline 3 applies.

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?

States a specific verb and resource: lists findings extracted from papers, rendered as subject/relation/object with organism, conditions, effect size and paper. It distinguishes itself from the sibling get_paper by framing this tool as the discovery surface and get_paper as the verification surface.

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?

Opens with concrete user-question patterns ('does an intervention extend lifespan, and in which organisms', 'what lowers a biomarker'), names the alternative (get_paper) with its selecting condition ('check a finding that matters'), and adds an explicit when-not ('Not for personal medical advice'). Nothing is left to inference.

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.

Resources