Skip to main content
Glama
NemoN

Tvheadend MCP

by NemoN

tvh_assign_epg_sources

Destructive

Assign advertised EPG source IDs to a Tvheadend channel, with add, replace, or remove modes to preserve or clear existing mappings; supports dry-run previews.

Instructions

Assign advertised EPG source IDs to a channel; add preserves existing sources.

Source IDs are enum keys from get_field_options(channel_uuid, 'epggrab'), often module/channel strings rather than UUIDs. Empty replace explicitly clears.

Input Schema

NameRequiredDescriptionDefault
modeNoadd
dry_runNo
source_idsYes
channel_uuidYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare destructive=true, openWorld=true, and non-idempotent, so the baseline is covered. The description adds meaningful behavioral context: add preserves existing sources, while empty replace explicitly clears them, and source IDs are non-UUID enum keys.

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 compact and front-loaded: purpose and mode behavior come first, followed by the critical source-ID format and empty-replace behavior. Every sentence adds useful information.

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?

With annotations covering safety traits and an output schema covering return values, the description supplies the key missing details: source ID format/origin and mode semantics. The main gap is that dry_run is never mentioned despite being relevant to a destructive operation.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry parameter meaning. It explains source_ids as enum keys from get_field_options and clarifies mode behavior, but it does not explain dry_run or channel_uuid, leaving a meaningful gap for a mutation tool.

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: assign advertised EPG source IDs to a channel. It also distinguishes the add mode's preservation behavior, which helps separate it from other EPG configuration siblings.

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?

It gives useful mode guidance for add and empty replace, and points to get_field_options for source IDs, but does not explicitly say when to use this tool instead of alternatives such as list_epg_sources or get_epg_config. The remove mode is not explained either.

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