Skip to main content
Glama
Sign In

Piping Toolset Engineering Data

by com.pipingtoolset
OverviewDiscussionsAdmin

Find a code dataset

find_dataset
Read-onlyIdempotent

Search the engineering code-table datasets by keyword (standard, table, quantity, material). Returns up to 10 matches, each with its id, title, standard, edition and table, whether lookups return a value or a pointer (table, row and column only), and the tier at which values are returned.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "find_dataset"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesKeywords, e.g. 'B31.3 allowable stress A106' or 'support spacing'
standardNoOptional standard filter, e.g. 'ASME B31.1'

Output Schema

NameRequiredDescriptionDefault
resultsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the result-shape disclosure: a hard cap of 10 matches and the important distinction between datasets whose lookups return values versus pointers (table/row/column only). That value-vs-pointer warning is genuinely beyond annotations, though it stops short of explaining how tiers affect downstream use.

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?

Two sentences, zero filler, with the primary action and scope front-loaded and the return-shape details following. Every clause carries information an agent needs to invoke or interpret the call.

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?

Given only two parameters, full schema coverage and an output schema, the description is nearly complete: it covers search intent, result cap, and the pointer/value caveat. The only gap is guidance on narrowing a search when 10 matches are hit or on how the standard filter interacts with keyword matching.

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 the baseline is 3, but the description earns an extra point by explaining what the query string is matched against (standard, table, quantity, material), which is interpretation guidance the schema's example alone does not guarantee.

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 (search) and resource (engineering code-table datasets) and enumerates what the keyword can match: standard, table, quantity, material. This is clearly distinct from lookup_value or describe_dataset behavior without needing to open a schema.

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?

Usage is implied rather than stated: the description tells you it searches datasets by keyword, so an agent infers it is a discovery step, but it never says when to prefer it over siblings like describe_dataset or get_pointer, nor what to do if results are empty or truncated.

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

All Piping Toolset Engineering Data 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