Skip to main content
Glama
markuskreitzer

PicoScope MCP Server

by markuskreitzer
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

configure_downsampling

Set data acquisition downsampling parameters to reduce file size while maintaining signal integrity for PicoScope oscilloscope measurements.

Instructions

Configure downsampling for data acquisition.

Args: mode: Downsampling mode. ratio: Downsampling ratio (1 = no downsampling).

Returns: Dictionary containing downsampling configuration.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNonone
ratioNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • src/picoscope_mcp/tools/advanced.py:94-109 (handler)
    The configure_downsampling tool handler function. Includes decorator for registration, type-hinted parameters serving as input schema, docstring, and current implementation (stub with TODO).
    @mcp.tool()
def configure_downsampling(
    mode: Literal["none", "aggregate", "decimate", "average"] = "none",
    ratio: int = 1,
) -> dict[str, Any]:
    """Configure downsampling for data acquisition.

    Args:
        mode: Downsampling mode.
        ratio: Downsampling ratio (1 = no downsampling).

    Returns:
        Dictionary containing downsampling configuration.
    """
    # TODO: Implement downsampling configuration
    return {"status": "not_implemented", "mode": mode, "ratio": ratio}
  • src/picoscope_mcp/server.py:19-19 (registration)
    Invocation of register_advanced_tools(mcp) which registers the advanced tools, including configure_downsampling.
    register_advanced_tools(mcp)
  • src/picoscope_mcp/tools/advanced.py:6-6 (registration)
    The register_advanced_tools function definition, which defines and registers multiple advanced tools including configure_downsampling via inline @mcp.tool() decorators.
    def register_advanced_tools(mcp: Any) -> None:

Tool Definition Quality

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'configure' which implies a write/mutation operation, but doesn't disclose whether this requires specific device states (e.g., connected/streaming), whether changes are persistent, what permissions are needed, or any side effects. The description adds minimal behavioral context beyond the basic action.

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?

The description is appropriately sized with clear sections (purpose, args, returns). The purpose statement is front-loaded, and the parameter explanations are efficient. However, the 'Returns' section could be more informative given there's an output schema - it somewhat repeats what the structured data already provides.

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

Completeness3/5

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

Given a mutation tool with no annotations but with an output schema, the description is moderately complete. It explains the parameters adequately and mentions the return type. However, it lacks important context about prerequisites (e.g., device connection state), side effects, and how this configuration interacts with other tools like 'start_streaming' or 'get_streaming_data'.

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?

With 0% schema description coverage, the description compensates by explaining both parameters: 'mode' is described as 'Downsampling mode' and 'ratio' is explained with 'Downsampling ratio (1 = no downsampling)'. This adds meaningful semantics beyond the bare schema, though it doesn't detail what each enum value ('aggregate', 'decimate', etc.) actually means. For 2 parameters, this is reasonably helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Configure downsampling for data acquisition' which provides a basic purpose (configure downsampling) and context (data acquisition). However, it doesn't specify what exactly gets configured (which device/channel/system) or how it differs from sibling tools like 'configure_channel' or 'set_timebase'. The purpose is clear but lacks specificity about scope and differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'configure_channel', 'set_timebase', and 'get_streaming_data', there's no indication of whether this tool should be used before/after streaming, in conjunction with other configuration tools, or as a standalone operation. The agent must infer usage from the tool name alone.

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