uni-t-uts-mcp

marker_search

Run a peak, minimum, or next-peak search on a spectrum analyzer marker and return its new frequency and level in one call, so you can locate signals without separate readouts.

Instructions

Move a marker with a search and return its new frequency and level together. Actions: peak (highest), next_peak (next highest), next_left / next_right (next peak left or right of the marker), minimum, peak_to_peak (the marker becomes a delta marker showing the peak-to-peak difference). A search turns a marker that is off on. Peaks must satisfy the peak threshold and excursion (get_peak_criteria).

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": {
      "marker": "<marker>",
      "action": "<action>"
    },
    "name": "marker_search"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	Which search to run
`marker`	Yes	Marker number, 1 to 10
`instrument`	No	Which 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.

First observedv1.1.0Nov 13, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false, so the description carries the burden and does disclose meaningful state changes: the marker moves, a previously off marker is switched on, and peak_to_peak converts the marker into a delta marker. It also reveals the response payload. It doesn't say whether the delta-marker mode persists across later calls or what happens when no peak meets the criteria.

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?

Three sentences, front-loaded with the primary effect and the return value, then the action glossary, then the precondition. Every clause carries information. The opening phrase 'Move a marker with a search' is slightly awkward but costs little.

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?

With no output schema, the description correctly states what comes back (frequency and level together), and it covers the off-to-on side effect and the peak criteria precondition. For a mutating search tool that is nearly complete; only failure behavior (e.g., no qualifying peak) is left implicit.

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%, giving a baseline of 3, but the description earns more by defining the semantics of each enum value (peak=highest, next_peak=next highest, next_left/next_right relative to the marker, minimum, peak_to_peak=delta marker) rather than leaving them as bare labels. The marker and instrument parameters gain no extra meaning beyond the schema.

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 first sentence names a specific verb (move via search) plus the resource (a marker) and states the return payload (new frequency and level together). The enumerated action list makes the scope concrete. It stops short of contrasting itself with similarly named siblings such as ad_marker_search and emi_marker_search, so the agent must infer which variant applies to its instrument.

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?

It gives clear operating context: a search turns a marker that is off on, and peak-type searches require threshold/excursion to be satisfied, routing the agent to get_peak_criteria first. That prerequisite pointer is genuinely useful. There are no explicit exclusions or named alternatives for the non-peak searches, which keeps it below a 5.

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

Deploy Server