Skip to main content
Glama
markuskreitzer

PicoScope MCP Server

measure_amplitude

Measure signal amplitude on PicoScope oscilloscope channels. Use after capture to obtain voltage measurements like peak-to-peak, RMS, or mean values.

Instructions

Measure signal amplitude on a channel.

Note: This requires a recent capture. Call capture_block first.

Args: channel: Channel to measure. measurement_type: Type of amplitude measurement.

Returns: Dictionary containing amplitude in volts and measurement type.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
channelYes
measurement_typeNopeak_to_peak

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The @mcp.tool()-decorated measure_amplitude function that defines and implements the tool's execution logic, including input validation via type hints and stubbed measurement handling.
    @mcp.tool()
    def measure_amplitude(
        channel: Literal["A", "B", "C", "D"],
        measurement_type: Literal["peak_to_peak", "rms", "mean", "max", "min"] = "peak_to_peak",
    ) -> dict[str, Any]:
        """Measure signal amplitude on a channel.
    
        Note: This requires a recent capture. Call capture_block first.
    
        Args:
            channel: Channel to measure.
            measurement_type: Type of amplitude measurement.
    
        Returns:
            Dictionary containing amplitude in volts and measurement type.
        """
        try:
            if not device_manager.is_connected():
                return {
                    "status": "error",
                    "error": "No device connected",
                }
    
            # Check if channel is configured
            if channel not in device_manager.channel_configs:
                return {
                    "status": "error",
                    "error": f"Channel {channel} not configured. Configure and capture first.",
                }
    
            # For now, we need to guide the user to capture data first
            return {
                "status": "info",
                "message": "To measure amplitude: 1) Configure channel, 2) Set trigger, 3) Capture block, then extract measurements from captured data",
                "channel": channel,
                "measurement_type": measurement_type,
            }
    
        except Exception as e:
            return {
                "status": "error",
                "error": str(e),
                "channel": channel,
            }
  • Registration of all tool groups by calling register_analysis_tools(mcp) which in turn registers the measure_amplitude tool via its decorator.
    register_discovery_tools(mcp)
    register_configuration_tools(mcp)
    register_acquisition_tools(mcp)
    register_analysis_tools(mcp)
    register_advanced_tools(mcp)
  • Import of register_analysis_tools function required for tool registration.
    from .tools.analysis import register_analysis_tools
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the prerequisite of needing a recent capture, which is useful behavioral context. However, it lacks details on permissions, error handling, or rate limits, leaving gaps in transparency for a measurement tool.

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 front-loaded with the core purpose, followed by a note on prerequisites and structured sections for Args and Returns. Each sentence earns its place without redundancy, making it efficient and well-organized.

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 the tool's moderate complexity, no annotations, and an output schema that covers return values, the description is mostly complete. It includes purpose, prerequisites, and parameter semantics, but could benefit from more behavioral details like error cases or performance considerations.

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 schema description coverage is 0%, but the description compensates by explaining that 'channel' is the 'Channel to measure' and 'measurement_type' is the 'Type of amplitude measurement,' adding meaning beyond the enum values. However, it does not elaborate on the differences between measurement types like 'peak_to_peak' vs 'rms,' which could enhance usability.

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 clearly states the tool's purpose as 'Measure signal amplitude on a channel,' which is a specific verb+resource combination. However, it does not explicitly distinguish this tool from sibling measurement tools like measure_frequency or measure_thd, which reduces it from a perfect score.

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?

The description provides explicit guidance to 'Call capture_block first' and notes that it 'requires a recent capture,' which clearly indicates a prerequisite and context for usage. However, it does not specify when to use this tool versus alternatives like measure_frequency or get_statistics, which prevents a score of 5.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/markuskreitzer/picoscope_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server