Skip to main content
Glama
Sign In
REW MCP Server

REW MCP Server

by manuaero
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

rew_list_measurements

Read-only

Lists all loaded measurements with UUIDs, names, and metadata so you can inspect and select the right measurement before running further REW operations.

Instructions

List all loaded measurements, UUIDs, names and metadata.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "rew_list_measurements"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare this as a read-only, non-destructive, closed-world operation. The description adds useful scope by saying it lists 'loaded' measurements and includes UUIDs, names, and metadata, but it does not cover ordering, pagination, or empty-result behavior.

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?

The description is a single front-loaded sentence with no redundant wording. Every element—action, scope, and returned fields—earns its place.

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 simple zero-parameter list tool with annotations covering safety and no output schema, the description is nearly complete. It states what is returned, though minor details such as ordering or empty-list behavior are omitted.

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?

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description does not need to compensate for missing schema details.

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 states a specific verb and resource: list all loaded measurements, including UUIDs, names, and metadata. It is clear what the tool returns, though it does not explicitly distinguish itself from sibling tools such as rew_get_measurement.

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 phrase 'loaded measurements' implies the tool is for enumerating currently loaded items, but there is no explicit when-to-use guidance or comparison to alternatives like rew_get_measurement or rew_export_measurement. Usage is inferable but not directed.

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