Skip to main content
Glama
calebn

Podcast MCP

by calebn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

open_gui_tool

Launch or reuse a read-only DAW web viewer to inspect podcast multitrack timelines, return its URL, and optionally open the project in your browser.

Instructions

Start the read-only DAW web viewer (background) and return its URL.

Idempotent: if a healthy viewer is already listening on host:port, reuses it and optionally opens the browser to this project. Requires the gui extra (uv sync --extra gui) and a built gui/web dist for the HTML UI.

Input Schema

NameRequiredDescriptionDefault
hostNo127.0.0.1
portNo
open_browserNo
project_pathNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.1
    • addedInput schema / properties / project_path / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / project_path / default
      Added value: +null
    • removedInput schema / properties / project_path / type
      Removed value: -"string"
    • removedInput schema / required
      Removed value: -[
-  "project_path"
-]
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses read-only operation, background execution, URL return, idempotency, reuse of an existing healthy viewer, optional browser opening, and required extras/dist artifacts. It does not describe behavior when an unhealthy process occupies the port or other failure modes, so it is strong but not exhaustive.

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 core action is front-loaded in the first sentence, followed by idempotency and prerequisite details in compact form. Every clause adds useful operational context without repetition.

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 local start-server tool with four parameters, no annotations, and an output schema, the description provides the key prerequisites and reuse semantics. It leaves out only edge-case behavior such as what happens when an unhealthy viewer is already bound to the port, which is a minor gap given the output schema covers the return URL.

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 0%, so the description must compensate, and it does by referencing all four parameters: host:port for health-check/listening, open_browser for optional browser opening, and project_path for the project to open. It stops short of parameter-specific constraints or defaults beyond what the schema already encodes.

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?

States a specific verb and resource: 'Start the read-only DAW web viewer (background) and return its URL.' The read-only, background, and URL-returning scope distinguishes it from all sibling DAW editing tools without opening any other schema.

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

Usage Guidelines3/5

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

The description implies the usage context by describing the viewer and its idempotent reuse behavior, and it states prerequisites (gui extra and built gui/web dist). However, it never explicitly says when to use this tool versus alternatives, nor does it name any related tool the agent should consider instead.

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