Skip to main content
Glama
Sign In

Turbulence Modeling Resource

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Tmr Reference Data

tmr_reference_data
Read-onlyIdempotent

Reference data (an experimental measurement or an established correlation, e.g. skin-friction coefficient Cf or lift/drag vs. angle of attack) for one NASA Langley Turbulence Modeling Resource case, as published by the case's own data file. Only available for a subset of cases — call tmr_cases first and check "reference_data: true" — because most TMR case directories hold dozens of individual turbulence-model CFD result files alongside the reference data, and this tool only serves files the case page itself unambiguously labels as the reference/experimental data.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "case": "2DZP"
    },
    "name": "tmr_reference_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
caseYesCase id from tmr_cases, e.g. "2DZP".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: availability is limited to an unambiguous subset, and the reason (case directories hold dozens of model-result files). It stops short of describing the return format or payload structure, so not a full 5.

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 core resource definition, then the availability constraint. It is slightly verbose in the explanatory em-dash clause about directory contents, but every sentence carries information an agent needs. Minor trimming possible.

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 single-parameter read tool with no output schema, the description covers what is returned (experimental measurement or established correlation such as Cf or lift/drag vs. AoA), the gating condition, and the prerequisite call. Return formatting is not specified, but the content is adequately characterized.

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 coverage is 100% and the single 'case' parameter carries an enum of 35 ids plus its own description ('Case id from tmr_cases'). The description reinforces that the id originates from tmr_cases but adds no syntax or format detail beyond the schema, so the 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 resource (reference/experimental data for one NASA Langley TMR case) and scopes it precisely to files the case page itself labels as reference data. It distinguishes itself from the sibling tmr_cases by routing the agent there for case discovery. An agent can tell what this returns without opening the schema.

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?

Explicit when/when-not guidance: 'Only available for a subset of cases — call tmr_cases first and check "reference_data: true"'. It names the prerequisite tool, the gating condition, and explains why most cases lack data. 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.

All Turbulence Modeling Resource toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources