Get channel
get_channelFicha completa de um canal, com os streams já apontando para o nosso hop.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID do canal no catálogo, ex. `GloboNews.br`. |
get_channelFicha completa de um canal, com os streams já apontando para o nosso hop.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID do canal no catálogo, ex. `GloboNews.br`. |
Changes observed during successful MCP inspections.
Input schema / properties / id / descriptionPrevious value: -"ID do canal no iptv-org, ex. `GloboNews.br`."New value: +"ID do canal no catálogo, ex. `GloboNews.br`."Input schema / properties / id / descriptionPrevious value: -"ID do canal no iptv-org, ex. `Globo.br`."New value: +"ID do canal no iptv-org, ex. `GloboNews.br`."Input schema / properties / id / descriptionAdded value: +"ID do canal no iptv-org, ex. `Globo.br`."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description does add one genuinely useful non-obvious trait: the returned streams are already rewritten to point at "o nosso hop" (our proxy/CDN hop), which an agent would not learn from the schema or annotations. It stops there, saying nothing about what else the record includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler and the resource front-loaded. It is efficient, though "ficha completa" is vague enough that the brevity shades into under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 carries the burden of explaining what is returned — yet "ficha completa" never enumerates or characterizes the fields. For a single-record fetch with no output schema and no return-value documentation, an agent cannot anticipate the payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single `id` parameter is documented in-schema with an example (`GloboNews.br`). The description adds no additional meaning about the identifier, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Ficha completa de um canal" names the resource (a channel) and implies a full-record retrieval, so the basic intent is inferable. However, it never states a clear verb or what the record contains, and it does nothing to distinguish itself from siblings like get_channel_guide, channel_health, legacy_stream, or search_channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. An agent must guess whether this or get_channel_guide/channel_health is the right call for channel metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.