Skip to main content
Glama
Sign In
PGS Catalog MCP

PGS Catalog MCP

by derekslinz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Search traits (ontology terms)

search_traits
Read-only

Resolve a human-readable condition to its exact EFO/MONDO/HP ontology ID for score searches, or find traits by name, category, synonym, ontology ID, or external mapped term.

Instructions

Search PGS Catalog traits by name, trait category, synonym, ontology ID, or external mapped term (e.g. 'breast cancer', 'Neurological disorder', 'ICD10:I25', 'OMIM:605526'). Always use this first to resolve a human-readable condition into the exact EFO/MONDO/HP ID that search_scores expects — ontology IDs change between catalog releases, so do not assume an ID from documentation or memory. Child ontology terms are included by default.

Input Schema

NameRequiredDescriptionDefault
fullNoReturn the complete upstream record including every field. Verbose; use only when the compact projection is not enough.
termNoTrait name, category, synonym, ontology ID, or external mapped term. Required unless trait_ids is given.
exactNoMatch only the exact term instead of partial matches. Defaults to false.
limitNoResults per page. The PGS Catalog default is 50 and the maximum is 250.
fieldsNoOptional comma-separated list of fields to return (dotted paths allowed, e.g. 'id,trait_reported,publication.title'). Omit for the default compact projection.
offsetNoZero-based offset into the full result set, used to page through matches.
trait_idsNoIDs to fetch, as a comma-separated string or an array of IDs.
include_parentsNoInclude parent ontology terms. Only applies when trait_ids is used.
include_childrenNoInclude child ontology terms of the matched trait. Defaults to true.
include_child_associated_pgs_idsNoAlso list PGS IDs associated with child traits. Only applies when trait_ids is used.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful context that child ontology terms are included by default and that IDs shift between catalog releases, but says nothing about result shape or paging limits beyond what the schema implies.

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?

Three sentences, front-loaded with the action, followed by the workflow rule and then the default behavior. No filler and nothing buried.

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 10-parameter search tool with no output schema, the description covers the primary workflow, ID-resolution requirement, and child-term behavior. It could note what a result record contains (trait ID, label, category) or that paging is available, but nothing needed to call it correctly 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 baseline is 3, but the description earns an extra point by supplying concrete example values ('breast cancer', 'ICD10:I25', 'OMIM:605526') that illustrate the heterogeneous term formats in a way the schema's prose does not. It also restates the include_children default in behavioral terms.

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 ('Search PGS Catalog traits') and enumerates the five searchable dimensions with concrete example terms. It is clearly distinguished from search_scores and get_trait by naming the downstream consumer of its output.

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?

Explicitly says to 'always use this first' to resolve a human-readable condition before calling search_scores, and warns against assuming ontology IDs from documentation or memory. This gives both the when and the when-not in a single workflow statement.

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

Deploy Server

Other Tools