Skip to main content
Glama
Sign In
uni-t-uts-mcp

uni-t-uts-mcp

by Reid-n0rc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_limit_line

Read-only

Read one limit line's display state, upper/lower type, tested trace, margin, on/off state, and frequency/level points to inspect analyzer limit-line setup; pass/fail is not returned.

Instructions

Read one limit line: whether it is displayed, its type (upper or lower), the trace it is tested against, the margin and its on/off state, and the point list (frequency in Hz, level in dBm, connected). The analyzer documents no pass/fail read-back, so whether a trace violates the line cannot be read; check the screenshot or compare get_trace_data with the points.

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": "get_limit_line"
  }
}

Input Schema

NameRequiredDescriptionDefault
lineNoLimit line number, 1 to 6 (the 1000-series models have 1 to 4)
instrumentNoWhich instrument to use (a name from list_instruments). Default: the `default` instrument, or the only one configured

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description goes well beyond that by disclosing a real capability gap — the analyzer documents no pass/fail read-back, so violation status is unobtainable here. It also pre-empts a wrong inference by naming the workarounds, which is exactly the kind of behavioral caveat an agent cannot get from structured fields.

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, front-loaded with the returned-field inventory, then the single caveat with its remedies. Every clause carries information — no restatement of the tool name, no filler framing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only tool with no output schema, the description supplies an implicit return-shape inventory plus the one behavioral limit that could cause misuse. Nothing an agent needs in order to call it and interpret the result is missing.

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 description coverage is 100%: `line` already documents the 1-6 range (1-4 on 1000-series models) and `instrument` documents the list_instruments lookup and default resolution. The description adds no parameter-level meaning beyond that, so the baseline 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 verb and resource ("Read one limit line") and then enumerates the exact fields the read returns: display state, type (upper/lower), tested trace, margin and on/off state, and the point list with units. An agent knows precisely what this tool yields without opening the schema, and the singular "one limit line" distinguishes it from any bulk/list read.

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

Usage Guidelines4/5

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

Gives clear contextual guidance: it explains that pass/fail cannot be read back and directs the agent to two concrete alternatives (screenshot, or comparing get_trace_data with the points) when violation status is needed. It does not state when to prefer this over a set/delete counterpart, but it does route the agent for the one ambiguous case that matters.

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