Skip to main content
Glama
paramount-engineering

Roku Dev Studio MCP Server

by paramount-engineering
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Device Performance Metrics (CPU / Memory / Objects)

device_performance_metrics
Read-onlyIdempotent

Fetch time-series CPU, memory, and BrightScript object usage from Roku device performance charts. Includes optional process snapshot and downsampling for large windows.

Instructions

Time-series Device Performance metrics — the same chanperf/r2d2-bitmaps/app-object-counts data the Remote tab's CPU/Memory/BrightScript Objects quad charts poll and plot, returned as compact per-timestamp entries with a decoding legend. Requires "Show Device Performance" (quad layout) to have been turned on for this device tab at some point this session, with the sideloaded Dev channel as the foreground app — if it never was, devicePerformanceEnabled is false and samples is empty (never an error). charts selects which of cpu/memory/objects to include (default: all three) — each requested type appears as its own key per sample (c=cpu, m=memory, o=objects; see legend for field meanings). windowSec (default 60) sets how far back from now to report; if the device's retained history is shorter, actualWindowSec/sampleCount reflect what was actually available. A window whose natural sample count exceeds maxSamples (default 120, max 500) is evenly downsampled across the window (not truncated from one end) and downsampled is set true. cpuProcessSnapshot (only present when cpu is requested) is a single latest-value object (process state, channel uptime, CPU time, cumulative fault counts) — Roku's <proc-stat> block has no historical series of its own, only the fault-rate numbers inside each cpu sample do. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chartsNoWhich chart types to include. Omit (or pass an empty array) for all three.
deviceNoOptional target device (IP or serial). Omit to use the focused tab.
windowSecNoHow far back from now to report, in seconds (e.g. 60 for the last minute, 3600 for the last hour). Default 60.
maxSamplesNoCap on returned samples; the window is evenly downsampled if it would exceed this. Default 120, hard cap 500.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.2

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses important behavioral traits: the quiet-failure mode when the feature was never enabled, uniform downsampling across the window rather than truncation, the `actualWindowSec`/`sampleCount` fallback when history is short, and the special single-value `cpuProcessSnapshot` that is not a historical series. This goes well beyond the annotations and helps the agent set expectations.

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 dense but every clause earns its place. It front-loads the core purpose and data source, then logically covers prerequisites, parameter effects, edge cases, and one special output. No filler or repeated schema information—only clarifying detail.

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?

There is no output schema, so the description must cover return shape and behavior. It does so thoroughly: compact per-timestamp entries, a decoding legend, `devicePerformanceEnabled`, `samples`, `actualWindowSec`, `sampleCount`, `downsampled`, and `cpuProcessSnapshot`. It also covers defaults, caps, and the only meaningful failure mode, making the tool fully invocable without additional lookups.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds substantial meaning: it explains the per-sample key convention (`c`/`m`/`o`) and the role of `legend`, how `windowSec` interacts with retained history, how `maxSamples` causes even downsampling plus a `downsampled` flag, and why `cpuProcessSnapshot` appears only with cpu. This is significant value beyond the schema's parameter descriptions.

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?

The description states a specific verb and resource: it returns time-series device performance metrics for CPU, memory, and objects, tied to a known data source (chanperf/r2d2-bitmaps/app-object-counts). This clearly differentiates it from all sibling tools, which target debugging, networking, or app control, not performance telemetry.

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 gives clear context and a concrete prerequisite: the 'Show Device Performance' quad layout must have been enabled earlier in the session, and the behavior when it was not is explicitly defined (empty samples, never an error). It does not name explicit alternatives or when-not-to-use versus a specific sibling, but the distinct purpose makes alternatives unnecessary.

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