Skip to main content
Glama

vela.research.list_studies

vela.research.list_studies
Read-only

List FieldStation research ideas as a library-kit DiscoveryDTO. Each card is a study we can support, not a running participant surface. The honesty gate (limitations, readiness, doNotClaim) is enforced by research:catalog-check — this tool publishes that same file. FREE and read-only. Presence is gated; truth is not.

[capability: study-catalogue · mirrors: GET /api/research/studies]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
noteYes
countYes
studiesYes
problemsYes
sendableYes
discoveryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already provide read-only and non-destructive hints; the description adds that it is 'FREE and read-only,' discloses an honesty gate (limitations, readiness, doNotClaim), and states 'Presence is gated; truth is not.' These go beyond the structured hints, though some phrasing is cryptic.

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 short and front-loaded with the action. The additional sentences earn their place by clarifying content semantics and safety, but phrases like 'honesty gate' and 'Presence is gated; truth is not' are compact yet less clear than they could be.

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 zero-parameter, read-only list operation with an output schema, the description covers purpose, scope, safety, and catalogue semantics. It lacks only explicit sibling routing or a clearer explanation of gating, but nothing essential to invoking it 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?

There are zero parameters, and schema description coverage is 100%, so the baseline is 4. The description adds no parameter details, but none are needed; it instead notes the output is a library-kit DiscoveryDTO and mirrors GET /api/research/studies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'List FieldStation research ideas as a library-kit DiscoveryDTO.' It further clarifies that returned cards are supportable studies, not participant-facing surfaces. It does not explicitly contrast with sibling get_study, so it stops short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied: call this to retrieve the study catalogue, and it warns that this is 'not a running participant surface.' However, it never explicitly says when to prefer get_study or another sibling, or when not to use this tool.

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