Skip to main content
Glama
paramount-engineering

Roku Dev Studio MCP Server

by paramount-engineering
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Network Inspector: List Events

network_inspector_list_events
Read-onlyIdempotent

List captured network events from Roku devices with optional filters for host, method, status, and more. Returns recent summaries to quickly inspect traffic without full headers.

Instructions

List captured network events as lightweight summaries (no full headers/body — drill down with network_inspector_get_event_detail using an event id). Summary-first by design to protect context. All filters optional and AND-combined across fields; give a field an array to OR within it (e.g. status: [404, 500]): device (IP or serial; omit for all Rokus on the hotspot), host (case-insensitive substring of hostname/SNI/URL), method (GET/POST/…), type (one of the network event types), status (exact HTTP response status code(s)), statusClass ('2xx'|'3xx'|'4xx'|'5xx'), contentType (case-insensitive substring against the response Content-Type, e.g. "json"), errorsOnly (HTTP status >= 400 — a shortcut for statusClass 4xx+5xx), mitmOnly (decrypted-HTTPS transactions only), limit (default 200, max 2000). Returns most-recent events. Requires Network Inspector enabled (see network_inspector_status).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNoOptional case-insensitive substring matched against hostname, TLS SNI, or request URL.
typeNoOptional event type filter.
limitNoMax events to return (default 200, max 2000).
deviceNoOptional Roku IP or serial. Omit to include every Roku on the hotspot.
methodNoOptional HTTP method filter (e.g. "GET", "POST").
statusNoOne or more values to match (OR).
mitmOnlyNoOnly decrypted-HTTPS transactions captured via the MITM proxy.
errorsOnlyNoOnly HTTP transactions with a response status >= 400.
contentTypeNoOne or more values to match (OR).
statusClassNoOne or more values to match (OR).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.2

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations' readOnly/idempotent hints, the description adds genuinely useful behavioral context: 'Summary-first by design to protect context' (explains the deliberately truncated output), 'Returns most-recent events' (ordering contract), AND/OR filter combinatorics, and the prerequisite state dependency. No contradiction with the annotations exists.

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 dense but well-ordered: purpose, drill-down pointer, design rationale, filter semantics, ordering, prerequisite. The long parameter glossary is justified by 10 parameters, though it partially restates schema content and could be tightened by trimming redundant per-field phrasing.

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?

For a 10-parameter, no-output-schema read tool, the description covers prerequisites, filtering semantics, defaults, ordering, and drill-down routing. The one gap is that it tells the agent what summaries lack ('no full headers/body') but never what fields they contain, leaving the return shape to inference.

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?

Although schema coverage is 100%, the description adds meaning the schema lacks: cross-field AND-combination with OR-within-arrays, the errorsOnly shortcut mapping to statusClass 4xx+5xx, the device omit-for-all-Rokus semantics, and the limit default/max. These semantics materially change how an agent composes a correct call and go well beyond the per-field schema text.

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 opens with a specific verb and resource ('List captured network events as lightweight summaries') and adds a scope qualifier ('no full headers/body'), then explicitly names the sibling it is not (network_inspector_get_event_detail). An agent can distinguish this tool from the other network_inspector_* siblings without opening the schema.

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 explicit routing to network_inspector_get_event_detail for drill-down and states the prerequisite ('Requires Network Inspector enabled (see network_inspector_status)'). It does not, however, address the overlapping siblings network_inspector_find and network_inspector_analyze, leaving some ambiguity about when those should be preferred, so it falls just short of full when/not-when coverage.

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