Public TV and radio catalogue with measured stream health, folders and M3U feeds for VLC.
Favorita um canal para o dono.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | Canal a favoritar, ex. `Globo.br`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states only that the tool favorites a channel, but does not mention that it is a mutation, any authentication requirements, side effects on repeated calls, or what happens to existing favorites. This is insufficient for a state-changing tool.
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?
The description is a single, terse sentence with no redundancy. However, it is overly minimal and does not provide structured detail that might help an agent, such as clarifying the ownership context or expected outcomes. It is concise but not necessarily well-structured for informative purposes.
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?
For a single-parameter mutation tool, the description is too thin. It leaves the 'dono' (owner) ambiguous, does not mention authentication or error conditions, and does not describe what happens after execution. Given the presence of auth-related siblings, this lack of context could lead to incorrect usage.
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?
The schema description coverage is 100%, with channel_id fully documented including an example. The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate. No extra context is provided about the parameter's format or behavior.
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?
The description clearly states the verb 'Favorita' (favorites) and the resource 'canal' (channel), making the tool's action obvious. It is distinguishable from siblings like remove_favorite by name, but the description itself does not explicitly differentiate it from other favorite-related tools. Slight ambiguity around 'para o dono' (for the owner) but the core purpose is clear.
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?
No guidance is given on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description is purely a statement of action without contextual direction, leaving the agent to infer usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adiciona canal à sub-aba.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | Sub-aba que recebe o canal, `grp_…`. | |
| channel_id | Yes | ID do canal no catálogo, ex. `Globo.br`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'adds channel to sub-tab' without disclosing side effects, reversibility, authentication requirements, or behavior on duplicate entries. This is a mutation tool with minimal behavioral disclosure.
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?
The description is extremely concise, consisting of a single short sentence. It is front-loaded and wastes no words, but its brevity borders on under-specification, though for a simple operation it is still appropriately sized.
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?
For a tool with no output schema and no annotations, the description is incomplete. It does not mention what the tool returns, error conditions, or any prerequisites. The agent lacks information about the outcome or failure modes.
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%, so both group_id and channel_id are fully documented in the schema. The description adds no additional parameter context, but the baseline of 3 is appropriate given the high coverage.
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?
The description states a specific verb (adds) and resource (channel to sub-tab), making the core purpose clear. However, it does not distinguish it from siblings like add_favorite or create_group beyond the obvious difference in resource, so it lacks explicit differentiation.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions. The description gives no indication of when to prefer this over create_group or add_favorite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Descobre a API Grade.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'Discover' without stating whether this is a read-only operation, what the response contains, whether authentication is required, or what side effects might occur. This is effectively no behavioral transparency.
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?
The description is extremely short and front-loaded, but it is under-specified rather than concise. One vague sentence does not earn its place because it provides almost no operational value to an agent.
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?
With no annotations, no output schema, and a vague one-line description, the tool is not adequately described. An agent cannot determine what the tool returns, when to call it, or how it differs from siblings, making the definition functionally incomplete.
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?
The tool has zero parameters and the schema is empty, so there is nothing to explain. With 0 params, the baseline is 4; the description does not need to add parameter semantics.
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?
The description says 'Descobre a API Grade' ('Discover the API Grade'), which combines a verb with a resource but leaves 'API Grade' undefined. The tool name 'api_index' suggests an index of endpoints, but the description does not clarify what the tool actually returns or how it relates to sibling tools.
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 guidance on when to use this tool versus any of the many sibling tools. The description provides no context or routing cues, such as 'use this to list all available endpoints' or 'use this instead of searching individual endpoints.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manda o código de login por e-mail.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | E-mail que vai receber o código. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that an email with a login code is sent, but omits side effects such as rate limiting, code expiration, whether an existing session is invalidated, or whether an email is only sent if the account exists. These are material behaviors for an auth-related mutation.
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?
The description is a single clear sentence with no filler or redundant wording. It is front-loaded with the core action and reads naturally in Portuguese.
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?
Although the tool is simple with one well-documented parameter, the lack of annotations and output schema means the description is the only behavioral source. It does not explain the auth flow, consequences of calling it, error conditions, or what the agent should do after sending the code. This leaves important operational context missing.
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%, so the schema already fully documents the single 'email' parameter. The description mentions 'por e-mail' but adds no semantic detail beyond what the schema states. Baseline 3 is appropriate because the structured field carries the meaning.
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?
The description clearly states a specific verb ('Manda' = sends), a resource ('código de login'), and the delivery channel ('por e-mail'). It distinguishes the tool from the sibling auth_verify, which presumably verifies the code rather than sending it. However, it does not explicitly frame this as the start of an authentication flow.
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?
The description gives no guidance on when to use this tool versus auth_verify or any other sibling. It does not mention prerequisites (e.g., unauthenticated user), expected context, or next steps. Usage must be inferred entirely from the name and the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confere o código, abre sessão e reivindica o convidado (devolve o convidado principal).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Os 6 dígitos que chegaram por e-mail. | |
| Yes | O mesmo e-mail do `/api/auth/start`. | ||
| guest_token | No | Convidado deste aparelho, para ser reivindicado pela conta. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It does state that it opens a session, claims the guest, and returns the guest, which are key actions. However, it does not disclose side effects like session invalidation, whether the operation is idempotent, or any permission requirements, leaving some behavioral ambiguity.
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?
The description is a single sentence that front-loads the primary action ('Confere o código') and then lists secondary actions. It is efficient with no filler, though it could benefit from a more structured format to separate actions clearly.
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?
The tool has a multi-step operation (confirm, open session, claim guest) and no output schema, so the description must explain the flow and return value. It mentions the return ('devolve o convidado principal') but does not explain when guest_token is needed, what the session entails, or what constitutes success. The lack of output schema and complexity makes this incomplete.
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?
The input schema has 100% coverage with clear descriptions for each parameter. The description does not add any additional meaning beyond what the schema already provides, such as the relationship between guest_token and the return value. Since schema coverage is complete, a baseline score of 3 is appropriate.
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?
The description clearly states three specific actions: confirming the code, opening a session, and claiming the guest, plus returns the main guest. It uses specific verbs and distinguishes from auth_start by the guest claim step. However, it is concise and could be more explicit about the tool's role in the auth flow.
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?
No guidance is provided on when to use this tool versus alternatives. The schema mentions email from /api/auth/start, implying a sequencing prerequisite, but the description itself does not state any conditions, exclusions, or recommended context. This leaves the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preços e tetos.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure, but 'Preços e tetos' reveals nothing about side effects, authentication requirements, response behavior, or whether this is a read-only operation. No behavioral trait is actually disclosed.
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?
The phrase is undeniably short, but it is under-specified rather than efficiently complete. It has no verb, no object action, and no useful structure to help an agent route to or invoke the tool.
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?
Even for a zero-parameter tool, the description does not explain what the caller will receive, such as a price list, cap values, or an availability status. Since there is no output schema and no annotations, the agent has almost no context to judge whether this tool satisfies a user request.
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?
The input schema has zero properties and full description coverage, so there are no parameters whose meaning the description must clarify. This matches the zero-parameter baseline; the description is consistent with the empty schema.
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?
The description, 'Preços e tetos' ('Prices and ceilings'), identifies a subject area but never states an action or resource operation. It does not say what the tool does with prices, such as returning, listing, or calculating them, and it does not distinguish billing from sibling tools.
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 guidance about when to call this tool versus alternatives. It gives no triggering condition, no exclusions, and no mention of sibling tools that might overlap with billing or pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Saúde comunitária do canal: taxa de sucesso, motivos de falha e ambientes afetados.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID do canal no iptv-org. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the output content (success rate, failure reasons, affected environments) but does not mention whether it is read-only, any side effects, rate limits, or response format. This is a moderate level of transparency.
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?
The description is a single, concise sentence that front-loads the key concept ('Saúde comunitária do canal') and lists specific output aspects. There is no redundancy or unnecessary detail, making it highly efficient.
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?
For a simple tool with one parameter and no output schema, the description provides adequate context about what it returns. It does not describe the return structure, but for a health-check tool, the listed metrics are sufficient for an agent to understand the tool's purpose. Missing details like response format are minor.
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?
The schema covers the single parameter 'id' with a clear description ('ID do canal no iptv-org'), so the schema description coverage is 100%. The tool description does not add any additional meaning beyond what the schema already provides, so it meets the baseline for well-documented parameters.
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?
The description states that the tool provides community health metrics for a channel, specifically success rate, failure reasons, and affected environments. This clearly distinguishes it from sibling tools like 'get_channel' (basic info) and 'health' (generic health), though it could be more explicit about the action (e.g., 'retrieves' or 'reports').
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 guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or comparisons with siblings like 'health' or 'play_reports', leaving the agent to infer its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Últimas mensagens da sala de um canal (sem WebSocket).
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | ID do canal no iptv-org. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully discloses that this endpoint is not a WebSocket and returns only the latest messages. It does not mention authentication requirements, pagination, rate limits, or the response envelope, though the read-only nature is strongly implied by 'history' and 'latest messages'.
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 compact sentence that front-loads the resource and scope and adds the WebSocket qualifier without filler. Every word earns its place.
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?
For a one-parameter read-only history tool, the description covers the core behavior and the non-WebSocket nature. However, with no output schema, it does not describe the shape of the returned messages or whether auth is required. This leaves moderate gaps for an agent invoking the tool.
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?
The input schema already documents channel_id as 'ID do canal no iptv-org' with 100% coverage. The description adds no parameter-level detail, but none is required given the schema's clarity. Baseline 3 is appropriate.
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?
The description states the tool returns the latest messages of a channel's chat room, which is a specific resource and scope. It avoids tautology and the parenthetical '(sem WebSocket)' helps distinguish it from a real-time messaging path. However, it lacks an explicit verb like 'returns' and does not name a sibling alternative.
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?
The phrase '(sem WebSocket)' implies this is the non-WebSocket/polling way to fetch recent chat messages, giving some context on when to call it. It does not explicitly state when to prefer chat_send, clear_history, or a WebSocket connection, nor any exclusions. Usage guidance is therefore only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Passe mensal do chat ($0.10 / 30 dias). Sem pagamento → 402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. It does add useful behavioral context: the pass costs $0.10 per 30 days and a missing payment results in HTTP 402. However, it does not describe what happens on successful payment, whether this creates a subscription, or what response/side effects the agent should expect.
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?
Two short, dense sentences convey price, duration, and a key failure behavior. There is no filler or repetition, and the core information is front-loaded.
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?
For a pass/payment-related tool with no annotations and no output schema, the description is too thin. It does not clarify whether the tool is a purchase action or a status check, what a successful call returns, what authentication is needed, or how it relates to the sibling billing and nsfw pass tools.
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?
The input schema has zero parameters, so there are no parameter semantics to document. The description correctly focuses on the tool's behavior and pricing rather than inventing parameter explanations, matching the baseline for zero-parameter tools.
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?
The description identifies the resource as a monthly chat pass and gives price/duration, but it lacks a concrete verb. It does not clearly say whether the tool buys, activates, checks, or renews the pass, and it does not distinguish itself from the sibling nsfw_pass_buy/nsfw_pass_status pair.
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 guidance on when to call this tool or when to prefer a sibling such as nsfw_pass_buy, nsfw_pass_status, or billing. The intended trigger—whether a user wants to purchase a pass or check access—is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manda mensagem na sala de um canal por HTTP.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | O texto da mensagem, dentro de `max_length`. | |
| author | No | Apelido a usar; sem ele o servidor gera um estável. | |
| channel_id | Yes | ID do canal no iptv-org. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only says the tool sends a message via HTTP; it does not mention authentication requirements, rate limits, idempotency, or side effects. For a mutating tool this is a notable gap.
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?
The description is a single short sentence with the action front-loaded. The phrase 'por HTTP' is slightly redundant, but overall there is no waste or clutter.
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?
For a mutating tool with no annotations and no output schema, the description is too sparse. It omits authentication context, expected usage conditions, and any relationship to sibling chat tools, making it incomplete for safe and correct invocation.
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%, so the schema already documents body, author, and channel_id. The description adds no additional parameter meaning, so the baseline of 3 is appropriate.
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?
The description states a clear verb ('Manda mensagem') and a specific resource ('na sala de um canal'), making the tool's core action obvious. It does not explicitly differentiate from siblings like chat_history or post_comment, but the channel-room wording provides enough distinction.
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 guidance about when to use this tool instead of related siblings such as chat_history or post_comment. The description only states what the tool does, leaving usage decisions entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Limpa o histórico inteiro do dono.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does convey that the tool clears the entire owner's history, which implies deletion. However, it does not state whether the action is irreversible, whether confirmation is needed, or what the result of the operation is.
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?
The description is a single, concise sentence with no redundant wording. It front-loads the core action and scope, which is ideal for such a simple tool.
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?
For a zero-parameter tool, the description is largely complete: it names the action, the resource, and the scope ('owner'). The main omissions are whether the operation is irreversible and whether it affects only the current owner's history, but the word 'dono' provides reasonable scoping.
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?
The tool has zero parameters and an empty input schema, so there are no parameter semantics to document. The description appropriately focuses entirely on the action, which is the only meaningful context an agent needs to invoke the tool correctly.
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?
The description states a specific action and resource: 'Limpa o histórico inteiro do dono' (clears the owner's entire history). This clearly differentiates the tool from read-oriented siblings like get_history or chat_history by indicating a destructive mutation.
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?
No guidance is given about when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. While the action is fairly self-explanatory, the description does not help an agent decide between clear_history and related history-related tools such as forget_watch or get_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Contato ou projeto de produtor ($0.10 x402/crédito por envio). form_ts é o início da composição em ms, entre 2 segundos e 12 horas atrás. Após o 1º envio: 429 + Retry-After.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Como chamar quem escreveu. | |
| Yes | Para onde responder. | ||
| form_ts | Yes | Início da composição, em milissegundos Unix: entre 2 segundos e 12 horas atrás, obrigatório também para agentes. | |
| message | Yes | O que você quer dizer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does add useful traits: the cost per send, the required form_ts time window, and the explicit rate-limit behavior “429 + Retry-After” after the first send. It does not describe the success response or auth requirements, but the send/rate-limit behavior is meaningfully transparent.
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?
The description is short and front-loaded with the purpose and cost, then the key timestamp constraint, then the rate limit. Each sentence carries useful information, though the cost expression “($0.10 x402/crédito por envio)” is slightly cryptic.
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?
For a simple four-parameter contact form with fully documented schema fields, the description includes the critical invocation constraints: cost, form_ts range, and rate-limit behavior. It does not explain the success return value, but the absence of an output schema makes that a smaller gap for this tool.
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%, so the baseline is 3. The description repeats the form_ts window already present in the schema and does not add new meaning for name, email, or message beyond what the schema documents.
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?
The description says “Contato ou projeto de produtor,” which identifies the resource/domain but does not state a clear action verb like “send” or “submit.” It gives pricing and constraints, but an agent still has to infer that this is a contact-submission endpoint.
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 guidance about when to use this tool versus alternatives; no sibling tool is mentioned. It provides technical constraints (form_ts range, 429 after the first send) but not when or why an agent should choose contact over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cria tab/categoria pessoal.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nome da pasta, até 40 caracteres. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Cria' implies mutation, but there is no mention of permissions required, whether the category is visible to others, reversibility, or any side effects—only the bare creation act is stated.
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 wasted words. The description is front-loaded and efficient, though it could be slightly more specific about the resource type.
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?
For a simple one-parameter creation tool with no output schema, the description is minimally adequate but leaves the tab/category/folder ambiguity unresolved. It lacks guidance on what a successful response looks like and whether the created item is private to the user, which 'pessoal' only hints at.
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%, with the 'name' parameter documented as 'Nome da pasta, até 40 caracteres' (folder name, up to 40 characters). The description adds no extra parameter detail, and there is a terminology mismatch—the description calls it 'tab/categoria' while the schema says 'pasta' (folder)—which could confuse an agent. Baseline 3 is appropriate since the schema does the work.
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?
The description states a clear verb ('Cria' = creates) and resource ('tab/categoria pessoal' = personal tab/category), but uses ambiguous terminology—'tab/categoria' conflates two concepts. It does not differentiate from sibling tools like create_group or create_guest, leaving the agent uncertain about the exact resource type.
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?
No guidance on when to use this tool versus alternatives such as create_group or create_guest. The description gives no context about use cases, prerequisites, or exclusions, so the agent has to infer applicability from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cria sub-aba numa categoria.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nome da sub-aba, até 40 caracteres. | |
| category_id | Yes | Pasta que vai receber a sub-aba, `cat_…`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states only the basic create action, but does not mention authentication requirements, side effects, whether creation can fail due to duplicates or invalid category_id, or what the tool returns. This is minimal behavioral transparency for a mutation tool.
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?
The description is a single short sentence with no wasted words, and the core purpose is front-loaded. It is appropriately concise, though its brevity leaves out useful operational context.
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?
For a simple two-parameter creation tool with no output schema, the description is minimally adequate: it states the action and target resource, and the schema explains the parameters. However, it lacks any context about expected behavior, prerequisites, or error conditions, making it only partially complete for an agent deciding whether and how to invoke it.
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 coverage is 100%, so the input schema already fully documents both parameters (name and category_id). The description adds no parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.
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?
The description 'Cria sub-aba numa categoria' clearly identifies the action (create) and the resource (sub-tab within a category), and it is distinct enough from the sibling create_category by specifying a sub-tab rather than a top-level category. It is concise and unambiguous, though it does not explicitly contrast itself with create_category.
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?
The description provides no guidance on when to use this tool versus alternatives such as create_category, nor does it mention prerequisites like requiring the category to already exist. Usage context must be inferred entirely from the resource name and parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cria guest ipt_…
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, and it fails: it only restates the operation implied by the name plus a cryptic 'ipt_' fragment. Nothing is disclosed about side effects, whether a token/ID is returned, session behavior, or persistence. The description adds essentially no behavioral context.
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?
While extremely short, the description appears truncated mid-token ('ipt_…'), which reads as broken rather than intentionally concise. A complete short sentence would be preferable.
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?
Although the tool is simple (no params, no output schema), an agent still needs to know what creating a guest produces (e.g., a guest token or ID) and how it fits the auth flow. The truncated description does not provide this, leaving a meaningful gap.
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?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. Per baseline for parameterless tools, the description reasonably does not need to document parameters.
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?
The description 'Cria guest ipt_…' states a verb ('Cria' = creates) and a resource (guest), which roughly distinguishes it from siblings like create_category and create_group. However, the text is truncated mid-phrase ('ipt_…'), leaving the exact purpose unclear, and it is nearly a restatement of the tool name.
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?
No guidance is given on when to use create_guest versus alternatives such as auth_start or auth_verify, which are clearly related to identity and sessions. There are no exclusions, prerequisites, or context signals about the intended flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apaga um comentário do próprio dono.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID do comentário, vindo de `Comentario.id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It implies deletion (a destructive action) but does not state permanence, authentication requirements, ownership verification, or any side effects. The phrase 'from its own owner' hints at a restriction but does not make it explicit.
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?
The description is a single, compact sentence with no extraneous words. It conveys the essential action and scope efficiently.
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?
For a simple delete operation with one parameter and no output schema, the description is minimally adequate. However, it lacks behavioral warnings (e.g., irreversibility) and does not explicitly state ownership restrictions, which an agent would need to invoke it correctly in all contexts.
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?
The schema fully describes the single parameter (id) with a clear origin reference, achieving 100% coverage. The description adds no additional meaning beyond what the schema already provides, so the baseline of 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?
The description 'Deletes a comment from its own owner' clearly states the action (deletes) and the resource (a comment), and the qualifier 'from its own owner' adds a meaningful scope. It distinguishes this from posting or listing comments, though it does not explicitly name alternatives.
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?
The description provides no guidance on when to use this tool versus sibling comment tools (e.g., post_comment, list_comments). It does not mention conditions, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tira um canal do histórico do dono.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | Canal a remover do histórico, ex. `Globo.br`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action (remove) but does not mention whether it is destructive, whether it requires authentication, or any side effects. It is a minimal statement without additional context.
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?
The description is a single, concise sentence that directly states the action. It is front-loaded and contains no filler or repetition. Perfectly efficient.
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?
For a simple one-parameter tool, the description is nearly complete, but it lacks any usage context or guidance on when to invoke it. It does not explain the difference from clear_history or mention that it only affects the current owner's history. This is a notable gap given the agent must select this tool among many siblings.
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?
The schema covers 100% of the parameter with a clear description and example, so the description adds no extra meaning. Since the schema is comprehensive, a baseline of 3 is appropriate; the description does not introduce any new information about the parameter.
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?
The description clearly states a specific verb ('remove') and resource ('channel from owner's history'), making the tool's purpose unambiguous. It is distinct from siblings like clear_history (removes all) and record_watch (adds), so an agent can easily differentiate it.
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?
No guidance is given on when to use this tool versus alternatives. For example, it does not mention that clear_history is for clearing the entire history, or that this tool is for removing a single channel. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
País sugerido pelo Cloudflare para a UI (fallback BR).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data source (Cloudflare), the purpose (UI), and the fallback value (BR), which are useful behavioral details beyond the empty input schema. It does not describe the return format in detail, but for a zero-parameter tool this is reasonably transparent.
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?
The description is a single concise phrase with no filler. The key information—Cloudflare-suggested country—is front-loaded, and the fallback detail is efficiently placed in parentheses.
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?
Given that this is a simple zero-parameter tool with no output schema, the description provides essential context: the source, the use case, and the fallback behavior. The only minor gap is that it does not explicitly state whether the return value is a country code, though 'fallback BR' strongly implies it.
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?
The input schema has zero parameters and schema description coverage is 100%, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, no additional parameter guidance is needed.
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?
The description clearly identifies the resource as a country suggested by Cloudflare for the UI, which conveys what the tool returns. However, it lacks an explicit verb like 'returns' or 'gets', and it does not directly distinguish itself from sibling list_countries, though the singular 'País' helps.
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?
The phrase 'para a UI' gives some context about when this is relevant, but it does not explicitly say when to use this tool versus alternatives such as list_countries. The usage is implied rather than clearly specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detalhe de um canal e seus streams.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID do canal no iptv-org, ex. `Globo.br`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It implies a read-only operation ('details') but does not explicitly state safety, authentication requirements, or any side effects. This is a minimal disclosure for a tool with no annotation support.
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?
The description is a single, concise sentence with no redundant content. It is appropriately front-loaded with the main purpose, though it could benefit from more detail without becoming verbose.
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?
For a simple tool with one parameter and no output schema, the description provides a minimal but sufficient overview. However, it does not mention what specific fields or streams are returned, which could leave the agent uncertain about the response format.
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?
The only parameter 'id' is well-documented in the schema with an example, achieving 100% schema coverage. The description adds no additional semantic value beyond the schema, so the baseline of 3 is appropriate.
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?
The description states it provides 'details of a channel and its streams,' which clearly identifies the resource and a specific aspect (streams). It is distinguishable from siblings like get_channel_guide and search_channels, though 'details' is somewhat vague about the exact content returned.
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?
No guidance is given on when to use this tool versus alternatives such as get_channel_guide or search_channels. There are no exclusions or contextual hints, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Programação de hoje do canal (grabada por nós): agora, a seguir e a lista.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID do canal no iptv-org. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions 'grabada por nós' (recorded by us), which hints at a data source but does not clarify whether the operation is read-only, whether it requires authentication, has rate limits, or any side effects. The lack of such disclosure is a notable gap.
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?
The description is a single concise sentence that immediately conveys the tool's purpose and output. It is front-loaded with the key information and contains no filler. While very efficient, it could arguably include a bit more context without becoming verbose.
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?
For a simple tool with one parameter and no output schema, the description is moderately complete. It specifies the content of the response (now, next, list), which gives some context. However, it lacks details about the response format, any pagination, or potential edge cases, and without annotations it does not cover operational aspects. It is adequate but not comprehensive.
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?
The schema fully describes the single parameter 'id' as 'ID do canal no iptv-org.' Since schema coverage is 100%, the description need not add parameter details. The description adds no extra meaning about the parameter, so the baseline of 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?
The description states that the tool provides today's channel programming ('Programação de hoje do canal') with specific components: now, next, and the list. This clearly identifies the resource and the type of data returned, and it distinguishes from sibling tools like get_channel (likely channel details) and list_* tools. However, it does not explicitly contrast with any specific sibling, so it falls short of a 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions for selection, exclusions, or related tools. An agent would have to infer usage from the name and context alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Histórico de canais assistidos pelo dono.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Itens por página. Acima de 50 é silenciosamente reduzido a 50. | |
| offset | No | Quantos itens pular. Use `next_offset` da resposta anterior. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only states the resource and does not mention pagination behavior, the silent 50-item cap, ordering, authentication, or response format. Some of this appears in parameter descriptions, but the tool description itself is not transparent.
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?
The description is a single short phrase with no filler, redundancy, or unnecessary detail. It is front-loaded and easy to parse, though it is so minimal that it sacrifices informative content.
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?
For a paginated list endpoint with no annotations and no output schema, the description does not explain what 'dono' refers to, how entries are ordered, or what the response looks like. The schema covers pagination, but broader context needed for correct invocation is missing.
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%, with limit and offset both documented, including the silent reduction to 50 and the use of next_offset. The tool description adds no parameter-level meaning, so the baseline of 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?
The description clearly identifies the resource: 'Histórico de canais assistidos pelo dono' (history of channels watched by the owner). It is distinct from sibling tools like get_library or list_favorites, but it lacks an explicit verb and does not name any sibling to differentiate from.
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 guidance on when to use this tool versus alternatives such as record_watch, clear_history, or forget_watch. No prerequisites, context, or exclusions are mentioned; the only usage signal is the tool name and the resource phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Árvore organizada do dono + URLs de feed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral disclosure burden. It only outlines the broad output contents (organized tree and feed URLs) and does not mention whether authentication is required, whether the operation is read-only, or what the response shape will be.
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?
The description is a single telegraphic phrase with no filler, and the main content is front-loaded. It is concise, though its terseness contributes to ambiguity in other dimensions.
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?
For a zero-parameter tool with no output schema, the description provides the minimum gist: an organized owner tree plus feed URLs. However, it leaves 'owner' ambiguous and does not define the URL/tree structure, so an agent is only partially equipped to interpret the response.
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?
The input schema has zero parameters, so there are no parameter semantics to document. The description does not need to compensate for schema gaps.
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?
The name 'get_library' plus the description 'Árvore organizada do dono + URLs de feed' clearly identifies a retrieval operation that returns the owner's organized library tree and feed URLs. The resource is specific and distinct enough from sibling tools like get_channel or list_favorites, though 'owner' is somewhat ambiguous.
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?
No statement explains when to use this tool versus alternatives, and there are no prerequisites or exclusions. The intended use is only weakly implied by the tool name and the terse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liveness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Liveness' implies a read-only health probe with no side effects, but it does not explicitly state that it is non-destructive, whether it requires authentication, or what kind of response the agent should expect.
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?
The description is extremely concise with no wasted words. For a zero-parameter liveness check, a single-word description can be acceptable, though a bit more elaboration would improve clarity.
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?
Given the simplicity of the tool, 'Liveness' is minimally adequate. However, with no output schema and no annotations, a short phrase like 'Returns service liveness status' would make the tool behavior more complete without adding much length.
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?
The tool has zero parameters and the schema description coverage is 100%, so there are no parameter semantics that need explanation. The baseline of 4 for a zero-parameter tool is appropriate.
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?
The description 'Liveness' is essentially a synonym of the tool name 'health', so it restates rather than explains. It communicates the general idea of a health check but does not specify a verb and resource or what exactly is being checked.
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 guidance on when to use this tool versus alternatives. The sibling list includes 'channel_health', which is likely related, but the description does not clarify whether this tool is the global API liveness check and whether channel_health is channel-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metadados públicos: site oficial do canal, URL da transmissão para copiar em outro player e player legado HTTP. Recusa adulto e bloqueados.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID público do stream, incluindo compatibilidade de IDs antigos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a key behavioral trait: it refuses adult and blocked content. However, it doesn't explain the failure mode (error vs empty response), permissions, or rate limits. The legacy HTTP player mention hints at legacy nature but not its implications.
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?
The description is a single, efficient sentence that front-loads the core metadata types and the refusal behavior. No waste, no redundancy.
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?
For a simple one-parameter metadata retrieval, the description covers what is returned and a notable restriction. However, without an output schema, it doesn't specify response shape or exact field names, and it omits usage guidance. It's adequate but not complete.
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 coverage is 100%: the parameter description explains the ID is public and supports legacy IDs. The tool description adds no extra parameter details, so baseline 3 is appropriate given the schema already handles semantics.
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?
The description clearly states the tool returns public metadata: official channel website, stream URL for other players, and legacy HTTP player. The verb is implicit (returns/provides) but the resource and content are explicit. It doesn't explicitly distinguish from siblings like get_channel, but the legacy focus and specific metadata list set it apart.
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?
No guidance on when to use this vs alternatives. The description doesn't mention exclusions, prerequisites, or when this is preferred over get_channel or search_channels. It only describes what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cidades com canal tocável.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Restringe a um país, ISO 3166-1 alpha-2. | |
| subdivision | No | Restringe a um estado/província. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says nothing about what the tool returns, whether it supports pagination, sorting, filtering beyond parameters, or any side effects. The phrase 'com canal tocável' hints at a filter but doesn't explain the behavior or result format.
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?
The description is extremely brief, one short phrase, which is technically concise but under-specifies the tool. It lacks any structural organization or front-loaded key information. The brevity is not effective because it omits essential details, making it more of an under-specification than genuine conciseness.
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?
For a list tool with two optional parameters and no output schema, the description should at least clarify the return type and how parameters affect results. It does neither. The description is incomplete to the point of being unusable for an agent to understand the tool's purpose and invocation.
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?
The input schema provides 100% description coverage for both parameters ('country' and 'subdivision'), so the schema already documents their meaning. The description adds no extra context about parameter usage, dependencies, or format. Per the baseline rule for high coverage, a score of 3 is appropriate.
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?
The description 'Cidades com canal tocável' translates to 'Cities with a playable channel', which is a noun phrase that doesn't explicitly state the action of listing or returning cities. It is vague and lacks a clear verb, making it ambiguous whether the tool lists cities or something else. It does hint at a resource (cities) but not the operation, so it only partially distinguishes from sibling list tools.
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 guidance on when to use this tool versus alternatives like list_countries or list_subdivisions. No context is provided about typical use cases, prerequisites, or when not to use it. The description gives zero information about selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comentários da comunidade sobre um canal.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID do canal no iptv-org. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether pagination applies, or what the response contains beyond 'comments.' Listing is implicitly read-only, but that is not stated. There is no mention of sorting, limits, or error behavior.
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?
The description is a single short phrase, but it is under-specified rather than concise. It omits essential operational details, so the brevity is a liability, not a strength. It does not front-load the key action or scope.
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?
For a list tool with no output schema and no annotations, the description should at least clarify the return format, pagination, or typical usage. It only states that comments exist for a channel, leaving the agent without enough context to invoke it correctly. The single parameter is documented, but the overall behavior is incomplete.
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?
The only parameter 'id' is fully described in the schema as 'ID do canal no iptv-org,' so schema coverage is 100%. The description adds no additional meaning about the parameter, such as format or constraints. Baseline of 3 is appropriate since the schema handles the parameter documentation.
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?
The description says 'Community comments about a channel,' which indicates the resource but does not explicitly state the action of listing. It is a noun phrase rather than a verb+resource, so it lacks specificity. It does distinguish from post_comment and delete_comment by focusing on retrieval, but not clearly.
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?
No guidance is provided on when to use this tool versus siblings like post_comment or delete_comment. There is no mention of prerequisites, context, or exclusions. The agent is left to infer that it lists comments based on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Países do catálogo com contagem playable e URL da bandeira (kind=radio conta estações).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | `tv` (padrão) conta canais de TV; `radio` conta estações do Radio Browser; `all` junta os dois. | tv |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds the nuance that kind=radio counts stations, but does not state that this is a read-only operation, mention return format details, pagination, or any constraints. This is a significant gap for a tool with no annotation coverage.
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?
One concise sentence with no filler, front-loading the core purpose and then the key parameter nuance. Efficient and clear.
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?
For a simple list tool with one optional parameter, the description covers the resource, output fields, and the parameter's effect. It lacks an explicit read-only statement and return structure, but these are minor given the simplicity and clear schema coverage.
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 coverage is 100% (the kind parameter is fully documented with its enum and default). The description adds only marginal extra meaning by restating the kind effect, which is already in the schema. Baseline 3 is appropriate.
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?
The description clearly states the tool lists countries with playable count and flag URL, using a specific verb ('Países do catálogo') and resource. It distinguishes from sibling list tools like list_cities and list_languages by the resource type.
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?
The description implies usage by its resource ('countries') and explains the effect of the kind parameter, but does not explicitly contrast with sibling tools. Context is clear, though no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Favoritos do dono.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. The phrase 'Favoritos do dono' conveys no action, side effects, auth requirements, or return handling. It does not even state that the tool returns a list or that 'owner' refers to the authenticated user.
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?
The description is extremely brief, but it is a sentence fragment in Portuguese rather than a complete, clear sentence. It under-specifies the tool's function, and the brevity comes at the cost of necessary meaning. It is not 'appropriately sized' because it omits the verb and core behavior.
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?
For a zero-parameter list tool, a complete description would be something like 'List the authenticated user's favorite items.' The actual description only says 'Owner's favorites' and fails to clarify that it returns a list, what the ownership scope is, or any auth context. Since there is no output schema, the description is the only source of behavioral context and it is insufficient.
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?
The input schema is empty, so there are zero parameters to document. The baseline for 0 params is 4. The description does not need to compensate for any schema gaps, and there is no parameter-related information missing.
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?
The description 'Favoritos do dono' ('Owner's favorites') identifies the resource as favorites and adds an ownership qualifier, but it lacks an explicit verb such as 'list' or 'retrieve'. It does not differentiate from sibling list_* tools by itself, leaving the tool name to carry the action. This is clearer than a tautology but still vague as a standalone purpose statement.
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?
No guidance is provided about when to use this tool versus alternatives like add_favorite, remove_favorite, get_library, or other list_* tools. The description gives no context about ownership scope or relation to sibling tools, so an agent has no help selecting this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Idiomas do catálogo tocável.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only names a resource; it does not state that the operation is read-only, what the response contains, whether there are side effects, or any caveats. The agent receives no behavioral detail beyond what the tool name implies.
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?
The text is short and without filler, but it is under-specified rather than appropriately concise. A single noun phrase without a verb or additional context does not function as a complete tool definition.
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?
With no annotations and no output schema, the description needed to at least explain that the tool returns a list and clarify what 'catálogo tocável' means. It does neither, leaving the agent to guess the return format and domain context. The tool may be simple, but the description still leaves important gaps.
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?
The tool accepts zero parameters and the input schema has no properties, so there is essentially no parameter-semantic burden. The description adds no parameter-specific meaning, but none is needed for a parameter-free tool.
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?
The description is a noun phrase ('Idiomas do catálogo tocável') rather than a verb-plus-resource statement. Combined with the tool name it implies listing languages, but the description alone does not explicitly state the action. It does reference a distinct resource domain and is not a pure tautology.
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?
No guidance is provided about when to use list_languages instead of sibling list tools like list_countries or list_tags. There are no exclusions, prerequisites, or alternative routing hints, so an agent gets no help selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Redes (network) do catálogo tocável.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only identifies a data domain and does not state whether this is read-only, what data is returned, whether results are paginated, or whether any authentication or scoping applies. The description does not contradict any annotations because there are none.
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?
The description is extremely compact, with no filler words, and the English parenthetical clarifies the Portuguese noun. Its brevity is appropriate for a zero-parameter list tool, though the undefined 'catálogo tocável' term keeps it from being perfect.
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?
Invocation is trivial because there are no parameters, but the description does not explain what the returned networks look like or what 'catálogo tocável' means, and there is no output schema or annotations to compensate. An agent can call it blindly but cannot anticipate the response shape or judge whether its result is what the user wants.
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?
The tool has zero parameters, so there is no parameter semantics for the description to clarify. The baseline for a no-parameter tool is 4, and the description correctly requires no input details.
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?
The description names the resource ('networks') and scopes it to 'the touchable catalog', so an agent can tell it is a list-type tool. However, it never states an explicit verb, and the term 'catálogo tocável' is unexplained jargon, so it does not fully differentiate it from the other list_* siblings beyond the noun.
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?
No guidance is given about when to use this tool versus alternatives such as list_cities, list_countries, or list_tags. There are no explicit exclusions, conditions, or cross-references, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Qualidades distintas dos streams.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates that the tool returns distinct stream qualities; it does not mention authentication, read-only behavior, rate limits, or what kind of stream context is relevant.
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?
The description is very short, front-loaded, and contains no filler. However, it is more of a fragment than a complete sentence and leaves out useful context, so it is concise but not fully well-rounded.
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?
Given the zero-parameter schema and simple list operation, the description provides the basic domain ('streams') and output type (distinct qualities), which may be minimally sufficient. But it lacks any auth expectation, use context, or relationship to the broader media/stream API, so an agent cannot fully judge when or how to invoke it.
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?
The tool has zero parameters, so there are no parameter details to document. The description still adds semantic context by clarifying that the returned values are stream qualities, which is helpful enough for a parameterless tool.
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?
The description 'Qualidades distintas dos streams' (distinct stream qualities) identifies a specific resource and the list_* verb in the tool name makes the operation clear, but it does not differentiate it from the many sibling list_* tools.
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?
No guidance is given about when to use this tool instead of siblings such as list_networks, list_languages, or list_tags. There are no exclusions or contextual cues to help an agent choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estados/subdivisões com canal tocável.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Restringe a um país, ISO 3166-1 alpha-2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only hints at a filtering condition (subdivisions with a tappable channel) but does not explain what that means, what the output structure is, or any ordering/pagination behavior. This is inadequate for a tool with zero annotation coverage.
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?
The description is extremely short (one phrase), which is concise, but it is under-specified rather than efficiently informative. There is no fluff, but it lacks essential content, so it earns a mid-range score for conciseness rather than a high one.
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?
For a simple tool with one optional parameter and no output schema, the description should at least clarify the meaning of 'canal tocável' and differentiate it from sibling list tools. It fails to do so, leaving the agent with insufficient context to call it correctly.
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?
The single parameter 'country' is fully documented in the schema (100% coverage), and the description adds no additional meaning about it. Per the rubric, baseline is 3 when schema coverage is high, and the description does not augment or contradict the schema.
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?
The description is a noun phrase ('Estados/subdivisões com canal tocável') rather than a clear verb+resource statement. It doesn't explicitly say 'list' or describe the action, and 'canal tocável' is ambiguous (tappable/clickable channel) without further context. It fails to distinguish from sibling tools like list_cities or list_countries.
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?
No guidance on when to use this tool versus the many sibling list tools (list_cities, list_countries, list_languages, etc.). The description provides no context for selecting this tool over alternatives, and no exclusions or preconditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tags das estações de rádio tocáveis (Radio Browser), com contagem; opcionalmente por país.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Quantas tags devolver (teto 100). | |
| country | No | Restringe às estações de um país, ISO 3166-1 alpha-2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It adds useful context: tags are scoped to playable Radio Browser stations, results include counts, and country filtering is possible. It does not disclose pagination, sorting, authorization, or rate-limit behavior, but for a simple read-only list tool this is acceptable.
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, front-loaded sentence with no filler; every clause adds information. The structure is appropriate for a simple list tool.
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?
For a 2-parameter tool with no required parameters and no output schema, the description covers the main return shape (tags with counts) and the main filter (country). It is missing minor behavioral details like default limit and ordering, but those are either present in the schema or low-stakes for invoking the tool.
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?
The schema already documents both parameters with 100% coverage, so the baseline is 3. The description's mention of 'opcionalmente por país' reinforces the country parameter but adds no new semantic detail beyond the schema's ISO 3166-1 alpha-2 note.
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?
The description identifies the resource (tags), the domain (playable Radio Browser stations), and a key feature (counts), plus an optional country filter. It clearly differs from sibling list_* tools because it targets tags rather than countries, cities, languages, or networks. However, it is a noun phrase rather than an explicit verb+resource statement, so it stops short of a 5.
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 guidance on when to choose list_tags over list_countries, list_languages, list_networks, or similar siblings. The optional country filter is mentioned, but no when-to-use/when-not-to-use context or alternative routing is provided. The intended usage is only implied by the name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Conta da sessão: e-mail, convidado principal e tamanho da biblioteca.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does specify the output fields, which provides some transparency, but it does not explicitly state that the operation is read-only, that authentication is required, or what happens if no session exists. For a zero-parameter info endpoint, this is adequate but not rich.
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?
The description is a single concise sentence that gets straight to the point. Every word contributes value by naming the session account and its three key attributes, with no filler.
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?
For a simple zero-parameter tool with no output schema, the description covers the main return values adequately. It could be slightly more complete by explicitly stating that the data is scoped to the current authenticated session, but the phrase 'session account' strongly implies this.
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?
The tool has zero parameters, and the schema coverage is effectively complete. Per the baseline for zero-parameter tools, a score of 4 is appropriate since there are no parameter semantics requiring compensation or explanation.
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?
The description clearly identifies the resource (the current session's account) and the exact fields returned: e-mail, main guest, and library size. However, it lacks an explicit verb like 'retrieve' and does not explicitly differentiate itself from sibling tools such as get_library or billing.
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?
The description implies the tool is used when session account information is needed, but it gives no guidance on when to prefer this over sibling tools or when not to use it. There are no exclusions, prerequisites, or alternative routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gera API key iptk_… (texto 1×).
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Rótulo para lembrar onde a chave foi usada. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It only says it generates a key, but does not state side effects, whether the key is one-time or persistent, permissions required, or reversibility. The phrase 'texto 1×' is ambiguous and does not clarify behavior. This is a significant gap for a mutation tool.
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?
The description is extremely short (one phrase) but is under-specified rather than concisely complete. It lacks essential context and structure, making it more inadequate than appropriately sized. It is front-loaded with the action but fails to convey necessary details.
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?
Given the tool's low complexity (single optional param, no output schema) and no annotations, the description is still incomplete. An agent cannot determine when to invoke it, what the key is for, or what to expect from the response. The ambiguity of 'texto 1×' further undermines completeness.
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%, so the label parameter is fully documented. The description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate. The 'texto 1×' phrase might relate to the key output, but it does not enhance parameter understanding.
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?
The description clearly states the action ('Gera API key') and the resource (API key with iptk_ prefix), making the tool's purpose evident. However, it lacks detail about what the key is used for and does not differentiate from potential related siblings like auth_start or auth_verify, though no direct conflict exists.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The description is purely declarative and leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Declara 18+ e aceita os termos de conteúdo adulto; libera nsfw=1 para este dono.
| Name | Required | Description | Default |
|---|---|---|---|
| birth_date | Yes | Data de nascimento, AAAA-MM-DD. | |
| accept_terms | Yes | Tem que ser `true` — aceite explícito. | |
| terms_version | No | Versão dos termos aceita; use a que veio no GET. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool sets nsfw=1 for the owner, which is a behavioral effect. However, it does not mention whether consent is permanent, reversible, or has legal implications, nor does it note any authentication requirements or failure conditions. The description is adequate but lacks deeper behavioral context.
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?
The description is a single, efficient sentence that front-loads the main purpose and effect. There is no wasted wording, and it is easily scannable by an agent.
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?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description is fairly complete. It explains the main outcome (nsfw=1) and the target (owner). It does not explain return values or edge cases, but those are not critical for a consent-acceptance tool. It could mention validation of birth_date (e.g., must be 18+), but the schema already implies format.
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%, so the schema already documents all three parameters. The description adds no additional meaning about the parameters, just reiterates the overall effect. This meets the baseline for full coverage, but does not go beyond it.
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?
The description clearly states the tool's purpose: declaring 18+ status, accepting adult content terms, and enabling nsfw=1 for the current owner. It is specific about the action and resource, and it distinguishes itself from siblings like nsfw_consent_revoke and nsfw_consent_status by naming the effect (libera nsfw=1).
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?
The description implies the use case (user consents to adult content), but it does not explicitly state when to use this tool versus alternatives like nsfw_consent_status or nsfw_consent_revoke. There is no mention of when not to use it or prerequisites beyond the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoga o consentimento adulto do dono.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It clearly indicates a state-changing consent revocation, but it does not disclose whether revocation is reversible, immediate, or has downstream effects on access to adult content. Some behavioral context is present, but consequences are left implicit.
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?
The description is a single concise sentence with no filler. It front-loads the action and object clearly, making it easy for an agent to parse quickly.
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?
Given the low complexity (no parameters, no output schema), the description is minimally adequate. However, it omits usage context, side-effect expectations, and explicit differentiation from consent-acceptance tools, which would help an agent invoke it with full confidence.
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?
The tool has zero parameters, so there are no parameter semantics to clarify. The baseline of 4 applies because the description does not need to compensate for undocumented parameters.
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?
The description states a specific action ('Revoga' = revokes) and a specific resource ('consentimento adulto do dono' = owner's adult consent). This clearly distinguishes it from sibling tools like nsfw_consent_accept and nsfw_consent_status, which perform different consent operations.
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 guidance about when to use this tool versus alternatives such as nsfw_consent_accept or nsfw_consent_status. The action is inferable from the verb, but the description does not state conditions, prerequisites, or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estado do portão de conteúdo adulto do dono.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure, but it only implies a read operation through the word 'status'. It does not state authentication needs, side effects, rate limits, or how the result is returned.
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?
The description is a single short sentence, appropriately compact for a parameterless status check. However, the metaphorical 'portão' wording is inefficient and ambiguous, where a plain phrase like 'NSFW consent status' would be clearer.
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?
With no annotations and no output schema, the description is the only source of context, and it fails to define the return value or clarify the subject ('dono'). An agent cannot know what format the response takes or whether this reflects the current authenticated user's consent setting.
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?
The tool has zero parameters and the empty schema trivially covers 100% of them, so there is nothing for the description to add. The baseline of 4 applies because no parameter documentation is needed.
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?
The description 'Estado do portão de conteúdo adulto do dono' (owner's adult content gate status) is essentially a restatement of the tool name in metaphorical Portuguese, with no action verb. It leaves ambiguous what 'portão' (gate) means, whose 'dono' (owner) is referenced, and whether the tool reads or modifies the status.
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?
No guidance is given on when to use this tool versus any of the many siblings. The description never mentions conditions, prerequisites, alternatives, or exclusions, so the agent must infer usage purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compra o passe de conteúdo adulto ($0.10 / 30 dias, x402). Exige consentimento de idade antes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the cost, duration, and consent requirement, but leaves unclear what happens if consent is missing, whether the pass auto-renews, and what the meaning of 'x402' is. No annotation contradiction exists.
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?
The description is a single concise sentence that front-loads the action and key details, then adds the consent prerequisite. There is no fluff or redundant information.
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?
For a simple 0-param tool with no output schema, the description covers the core action, price, duration, and prerequisite, but omits post-purchase behavior or return value. The cryptic 'x402' and lack of mention of how the pass is applied leave the agent with some uncertainty.
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?
The input schema is empty with zero parameters, so the baseline is 4. The description adds no parameter-specific meaning because there are no parameters to describe; this is appropriate.
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?
The description clearly states a specific verb and resource: 'Compra o passe de conteúdo adulto' (buy the adult content pass), along with concrete terms ($0.10 / 30 days). This distinguishes it from sibling tools like nsfw_consent_accept and nsfw_pass_status, which handle consent and status respectively.
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?
The description provides an explicit prerequisite: 'Exige consentimento de idade antes' (requires age consent before). This tells the agent when the tool may be used, though it does not name alternative tools such as nsfw_consent_accept or nsfw_pass_status for checking existing passes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diz se o passe adulto do dono está válido e até quando.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the core behavior: the tool reports validity and expiration date. The stative verb 'diz' implies a read-only query rather than a mutation, which is helpful. It does not mention auth, errors, or side effects, but those are secondary for a zero-parameter status check.
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?
The description is a single short, front-loaded sentence with no filler, repetition, or redundant schema information. Every word contributes to the meaning.
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?
For a simple status-check tool with zero parameters, no annotations, and no output schema, the description conveys the essential behavior and result. Minor gaps are that 'dono' (owner) is not explicitly defined as the currently authenticated user, and no guidance is given about related nsfw tools.
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?
The input schema has no properties, so there are no parameter semantics to clarify. The baseline of 4 applies because parameter explanation is unnecessary.
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?
The description uses a specific verb ('Diz' / 'tells') and clearly identifies the resource ('o passe adulto do dono' / the owner's adult pass) and the information returned (validity and expiration). It is clear, but it does not explicitly distinguish itself from sibling tools like nsfw_consent_status or nsfw_pass_buy.
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?
The intended usage is implied: call this tool to check whether the owner's adult pass is valid and when it expires. However, there is no explicit guidance about when to use this versus alternatives, and no reference to related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relatos crus de um canal, com endereço — só operador (METRICS_TOKEN). Use para investigar um canal específico.
| Name | Required | Description | Default |
|---|---|---|---|
| ok | No | `0` traz só as falhas — é o recorte que interessa numa investigação. | |
| limit | No | Itens por página. Acima de 50 é silenciosamente reduzido a 50. | |
| channel_id | No | Restringe a um canal. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure. It only reveals the operator token requirement (METRICS_TOKEN) and hints at 'raw' data, but does not state whether it is read-only, what side effects exist, or how failures are presented. This is insufficient for a tool with zero annotation coverage.
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?
The description is a single, compact sentence with no wasted words, and it front-loads the core purpose. However, the ambiguity of 'relatos crus' slightly detracts from overall clarity, keeping it from a perfect score.
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?
For a tool with 3 parameters, no output schema, and no annotations, the description provides some context (channel focus, operator access, raw reports with address) but lacks details on return format, error behavior, and pagination beyond the schema. It is adequate but leaves notable gaps.
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%, so the baseline is 3. The description adds no extra parameter meaning beyond reinforcing the channel investigation use case; it does not clarify the 'ok' enum semantics or limit behavior beyond what the schema already states.
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?
The description states a specific resource ('relatos crus de um canal') and an implied retrieval action, and distinguishes itself from siblings by emphasizing operator-only access and channel focus. However, 'relatos crus' is ambiguous—it could mean raw logs, reports, or something else—so it is not fully precise.
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?
It provides a clear usage context ('Use para investigar um canal específico') but does not mention alternatives or exclusions relative to sibling tools like channel_health or get_channel. The operator-only note implies access control but not when to choose this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comenta num canal (teto de 20/hora por dono).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID do canal no iptv-org. | |
| body | Yes | O texto do comentário; o teto vem em `max_length` da listagem. | |
| author | No | Apelido a usar; sem ele o servidor gera um estável. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses a rate limit (20/hour per owner), which is a useful behavioral trait. However, it does not mention authentication requirements, whether the operation is reversible, or what happens on failure – significant gaps for a write operation.
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?
The description is a single, concise sentence that front-loads the primary action and includes a key constraint. It contains no filler words or redundant information, earning a top score for structure.
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?
For a simple create-comment tool with no output schema, the description adequately covers the purpose and a key constraint. The schema handles parameter details, so nothing critical is missing. It could mention expected outcomes or error cases, but given the simplicity, it is sufficiently complete.
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%, so the schema already documents all three parameters (id, body, author). The description adds no parameter-level detail beyond the schema, which is the baseline expectation. It does not clarify semantics like the meaning of 'author' beyond the schema's description.
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?
The description clearly states the action ('Comenta num canal' – comments on a channel) with a specific verb and resource. It distinguishes itself from siblings like delete_comment and list_comments by explicitly indicating it posts a comment. The rate limit note adds clarity about the operation's scope.
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?
The description does not explicitly state when to use this tool versus alternatives like chat_send or list_comments. It implies usage for commenting on a channel, but lacks exclusions or alternative routing. The rate limit hints at a constraint but not when to prefer this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Oferta de transmissão autorizada sob consulta: informações e contatos para produtores. Não ativa streams.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Idioma da oferta: pt, en, es, fr ou de; ausente ou desconhecido volta a pt. | pt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and it does add a meaningful behavioral trait: this tool does not activate streams. It also implies a read-only, informational function by focusing on 'informações e contatos,' which is adequate for a low-risk lookup tool.
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?
The description is two short statements with no filler. The core purpose is front-loaded, and the clarifying exclusion follows immediately, making it easy for an agent to scan.
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?
For a single-optional-parameter tool with no output schema, the description adequately communicates what the tool provides and what it does not do. It does not describe the exact return format, but 'informações e contatos' gives enough general guidance for this low-complexity case.
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 coverage is 100%, so the lone 'lang' parameter is already fully documented with its enum and default behavior. The description adds no parameter-specific information, which is acceptable given the schema's completeness.
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?
The description clearly identifies a resource—authorized transmission offer information and contacts for producers—and includes the key exclusion 'Não ativa streams,' which distinguishes it from stream-activation tools. It lacks an explicit action verb like 'list' or 'get,' but its intended purpose is reasonably clear.
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?
The description gives clear context: use it for producer-facing authorized-broadcast information and contacts. It also provides an explicit when-not ('Não ativa streams'), though it does not name an alternative tool, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registra um canal assistido no histórico do dono.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | Canal assistido, ex. `Globo.br`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core action (registering a watched channel) but does not disclose side effects, authentication requirements, idempotency, error behavior, or whether it overwrites existing entries. For a write operation with no annotation safety hints, this is a significant gap.
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?
The description is a single, efficient sentence with no fluff. The core action is front-loaded, and there is zero wasted wording.
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?
For a simple 1-parameter tool, the description states the purpose clearly, but it does not mention return values, error handling, or idempotency. Since there is no output schema and no annotations, an agent is left guessing about outcomes beyond the basic effect.
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?
The schema covers the single parameter channel_id with an example ('Globo.br'). The description adds no additional semantic detail beyond what the schema already provides, so the baseline of 3 for full schema coverage 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?
The description states a specific verb ('Registra' = registers), a specific resource ('canal assistido' = watched channel), and a destination ('histórico do dono' = owner's history). This clearly distinguishes it from sibling tools like get_history, clear_history, and forget_watch, which read or clear history.
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?
The purpose implies usage (when you want to record a watched channel), but the description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. No guidance is given on how this differs from add_favorite or other recording tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tira um canal dos favoritos do dono.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | Canal a desfavoritar, ex. `Globo.br`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It states the basic action but does not disclose side effects, idempotency, error handling, or permission requirements. For a mutation operation, this is a significant gap.
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?
The description is a single, concise sentence that is front-loaded with the essential information. There is no redundancy or unnecessary detail.
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?
For a simple one-parameter tool with no output schema, the description is adequate but lacks guidance on usage conditions and behavioral details. It provides the core action but not enough context for an agent to decide when to invoke it or what to expect.
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?
The schema already documents the single parameter with 100% coverage, including an example. The description adds no additional semantic meaning beyond the action. Since the schema covers the parameter, the description's contribution is minimal.
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?
The description clearly states the action (remove) and the resource (a channel from the owner's favorites), using a specific verb and resource. It distinguishes from sibling tools like add_favorite and list_favorites by indicating the removal operation.
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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of conditions, prerequisites, or exclusions. The agent must infer usage from the name and sibling context, but no explicit direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relata se um canal tocou (ok=true) ou não (ok=false + code). Navegador, SO e país saem do pedido, não do corpo.
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | `true` se tocou, `false` se falhou. | |
| code | No | Por que falhou; só quando `ok` é `false`. | |
| channel_id | Yes | Canal que você tentou assistir. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a behavioral detail: that browser, OS, and country are derived from the request rather than the body. It does not mention side effects, but the report nature suggests it is read-only. No annotations are provided, so this transparency is valuable.
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?
The description is brief and to the point, consisting of two sentences that convey essential information without unnecessary words. It is well-structured and easy to parse.
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?
For a simple reporting tool, the description is complete. It explains the purpose, the meaning of the boolean and error code, and notes about request parameters. No output schema exists, so no return value description is needed.
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?
The schema provides detailed descriptions for all three parameters (ok, code, channel_id). The description further clarifies the relationship between ok and code (code is provided only when ok=false), enhancing the semantic understanding beyond the schema alone.
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?
The description clearly states the tool's purpose: reporting whether a channel played (ok=true) or failed (ok=false + code). It also clarifies that browser, OS, and country are taken from the request, not the body, which adds useful context.
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?
The description implies the tool is used after attempting to play a channel, but it does not explicitly mention when to use it versus alternatives like 'play_reports'. There is no direct comparison or condition provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca canais públicos (filtros: q, country, category, language, network, quality, playable, nsfw; kind=radio para estações de rádio, tag para tag de rádio; sort=score ordena pela saúde medida por terceiro, sort=votes pelos votos da rádio; online=1 só quem foi visto online nas últimas 48 h).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Texto livre no nome e nos apelidos do canal (busca full-text). | |
| tag | No | Tag da estação de rádio (vocabulário livre do Radio Browser, ex. `mpb`, `news`); veja `GET /api/tags`. | |
| city | No | Cidade, código do iptv-org. | |
| kind | No | `tv` (padrão) é o catálogo de TV; `radio` são as estações do Radio Browser; `all` junta os dois. Sem `kind`, rádio nunca aparece. | tv |
| nsfw | No | `1` inclui conteúdo adulto; exige consentimento 18+ gravado, senão 403. | 0 |
| sort | No | `score` ordena pela saúde medida por terceiro (IPTV Nexus), melhor primeiro; canal não medido vai para o fim. `votes` ordena pelos votos da comunidade do Radio Browser (rádio). `name` é a ordem alfabética. | name |
| guide | No | `1` traz só canal com grade de programação (EPG). | 0 |
| online | No | `1` traz só canal visto online pela fonte (IPTV Nexus para TV, Radio Browser para rádio) nas 48 h anteriores à última recarga do catálogo (`health_ext.online`); com o catálogo parado há mais de 48 h o filtro não devolve ninguém. | 0 |
| country | No | País do canal, ISO 3166-1 alpha-2. | |
| network | No | Nome exato da rede/emissora. | |
| quality | No | Qualidade exata do stream. | |
| category | No | ID de categoria do iptv-org. | |
| language | No | Idioma do canal, ISO 639-3. | |
| playable | No | `0` inclui canal sem stream utilizável conhecido. | 1 |
| subdivision | No | Estado/província, código do iptv-org. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses behavioral quirks like the 48-hour online window, that radio is hidden without kind=radio, and that sort=score orders by third-party health with unmeasured channels last. Missing response format or pagination details, but covers key behaviors.
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?
One long sentence but front-loaded with the main purpose and then enumerates filters in parentheses. Efficient though dense; it packs a lot of information without unnecessary words.
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?
With 15 parameters, 6 enums, and no output schema, the description covers the most important filters but omits several (city, guide, subdivision, playable) that are only in the schema. It does not mention the return type, pagination, or any response format, which an agent would need for a search operation.
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%, so baseline is 3. The description summarizes a few key parameters (kind, sort, online) but does not add meaning beyond the schema's own detailed descriptions. It only restates what the schema already explains.
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?
States a specific verb ('Busca') and resource ('canais públicos') and lists key filters. It clearly distinguishes from sibling list_* metadata tools and get_channel by being the search entry point.
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?
Usage is implied by the tool's purpose; it mentions specific use cases like kind=radio and sort=score, but does not explicitly say when to use this over alternatives like get_channel or list_* tools. No exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
add_favorite1 field changedInput schema / properties / channel_id / descriptionAdded value: +"Canal a favoritar, ex. `Globo.br`."add_item2 fields changedInput schema / properties / channel_id / descriptionAdded value: +"ID do canal no catálogo, ex. `Globo.br`."Input schema / properties / group_id / descriptionAdded value: +"Sub-aba que recebe o canal, `grp_…`."auth_start1 field changedInput schema / properties / email / descriptionAdded value: +"E-mail que vai receber o código."auth_verify3 fields changedInput schema / properties / code / descriptionAdded value: +"Os 6 dígitos que chegaram por e-mail."Input schema / properties / email / descriptionAdded value: +"O mesmo e-mail do `/api/auth/start`."Input schema / properties / guest_token / descriptionAdded value: +"Convidado deste aparelho, para ser reivindicado pela conta."channel_health1 field changedInput schema / properties / id / descriptionAdded value: +"ID do canal no iptv-org."chat_history1 field changedInput schema / properties / channel_id / descriptionAdded value: +"ID do canal no iptv-org."chat_send3 fields changedInput schema / properties / author / descriptionAdded value: +"Apelido a usar; sem ele o servidor gera um estável."Input schema / properties / body / descriptionAdded value: +"O texto da mensagem, dentro de `max_length`."Input schema / properties / channel_id / descriptionAdded value: +"ID do canal no iptv-org."contact4 fields changedInput schema / properties / email / descriptionAdded value: +"Para onde responder."Input schema / properties / form_ts / descriptionAdded value: +"Início da composição, em milissegundos Unix: entre 2 segundos e 12 horas atrás, obrigatório também para agentes."Input schema / properties / message / descriptionAdded value: +"O que você quer dizer."Input schema / properties / name / descriptionAdded value: +"Como chamar quem escreveu."create_category1 field changedInput schema / properties / name / descriptionAdded value: +"Nome da pasta, até 40 caracteres."create_group2 fields changedInput schema / properties / category_id / descriptionAdded value: +"Pasta que vai receber a sub-aba, `cat_…`."Input schema / properties / name / descriptionAdded value: +"Nome da sub-aba, até 40 caracteres."delete_comment1 field changedInput schema / properties / id / descriptionAdded value: +"ID do comentário, vindo de `Comentario.id`."forget_watch1 field changedInput schema / properties / channel_id / descriptionAdded value: +"Canal a remover do histórico, ex. `Globo.br`."get_channel1 field changedInput schema / properties / id / descriptionAdded value: +"ID do canal no iptv-org, ex. `Globo.br`."get_channel_guide1 field changedInput schema / properties / id / descriptionAdded value: +"ID do canal no iptv-org."get_history4 fields changedInput schema / properties / limit / defaultAdded value: +20Input schema / properties / limit / descriptionAdded value: +"Itens por página. Acima de 50 é silenciosamente reduzido a 50."Input schema / properties / offset / defaultAdded value: +0Input schema / properties / offset / descriptionAdded value: +"Quantos itens pular. Use `next_offset` da resposta anterior."legacy_stream1 field changedInput schema / properties / id / descriptionAdded value: +"ID público do stream, incluindo compatibilidade de IDs antigos."list_cities2 fields changedInput schema / properties / country / descriptionAdded value: +"Restringe a um país, ISO 3166-1 alpha-2."Input schema / properties / subdivision / descriptionAdded value: +"Restringe a um estado/província."list_comments1 field changedInput schema / properties / id / descriptionAdded value: +"ID do canal no iptv-org."list_countries2 fields changedInput schema / properties / kind / defaultAdded value: +"tv"Input schema / properties / kind / descriptionAdded value: +"`tv` (padrão) conta canais de TV; `radio` conta estações do Radio Browser; `all` junta os dois."list_subdivisions1 field changedInput schema / properties / country / descriptionAdded value: +"Restringe a um país, ISO 3166-1 alpha-2."list_tags3 fields changedInput schema / properties / country / descriptionAdded value: +"Restringe às estações de um país, ISO 3166-1 alpha-2."Input schema / properties / limit / defaultAdded value: +40Input schema / properties / limit / descriptionAdded value: +"Quantas tags devolver (teto 100)."mint_key1 field changedInput schema / properties / label / descriptionAdded value: +"Rótulo para lembrar onde a chave foi usada."nsfw_consent_accept3 fields changedInput schema / properties / accept_terms / descriptionAdded value: +"Tem que ser `true` — aceite explícito."Input schema / properties / birth_date / descriptionAdded value: +"Data de nascimento, AAAA-MM-DD."Input schema / properties / terms_version / descriptionAdded value: +"Versão dos termos aceita; use a que veio no GET."play_reports5 fields changedInput schema / properties / channel_id / descriptionAdded value: +"Restringe a um canal."Input schema / properties / limit / defaultAdded value: +20Input schema / properties / limit / descriptionAdded value: +"Itens por página. Acima de 50 é silenciosamente reduzido a 50."Input schema / properties / ok / descriptionAdded value: +"`0` traz só as falhas — é o recorte que interessa numa investigação."Input schema / properties / ok / enumAdded value: +[
+ "0"
+]post_comment3 fields changedInput schema / properties / author / descriptionAdded value: +"Apelido a usar; sem ele o servidor gera um estável."Input schema / properties / body / descriptionAdded value: +"O texto do comentário; o teto vem em `max_length` da listagem."Input schema / properties / id / descriptionAdded value: +"ID do canal no iptv-org."producer_services2 fields changedInput schema / properties / lang / defaultAdded value: +"pt"Input schema / properties / lang / descriptionAdded value: +"Idioma da oferta: pt, en, es, fr ou de; ausente ou desconhecido volta a pt."record_watch1 field changedInput schema / properties / channel_id / descriptionAdded value: +"Canal assistido, ex. `Globo.br`."remove_favorite1 field changedInput schema / properties / channel_id / descriptionAdded value: +"Canal a desfavoritar, ex. `Globo.br`."report_play4 fields changedInput schema / properties / channel_id / descriptionAdded value: +"Canal que você tentou assistir."Input schema / properties / code / descriptionAdded value: +"Por que falhou; só quando `ok` é `false`."Input schema / properties / code / enumAdded value: +[
+ "cors",
+ "geo",
+ "sumiu",
+ "codec",
+ "playlist",
+ "sem_resposta",
+ "protocolo",
+ "sem_stream",
+ "outro"
+]Input schema / properties / ok / descriptionAdded value: +"`true` se tocou, `false` se falhou."search_channels25 fields changedInput schema / properties / category / descriptionAdded value: +"ID de categoria do iptv-org."Input schema / properties / city / descriptionAdded value: +"Cidade, código do iptv-org."Input schema / properties / country / descriptionAdded value: +"País do canal, ISO 3166-1 alpha-2."Input schema / properties / guide / defaultAdded value: +"0"Input schema / properties / guide / descriptionAdded value: +"`1` traz só canal com grade de programação (EPG)."Input schema / properties / guide / enumAdded value: +[
+ "0",
+ "1"
+]Input schema / properties / kind / defaultAdded value: +"tv"Input schema / properties / kind / descriptionAdded value: +"`tv` (padrão) é o catálogo de TV; `radio` são as estações do Radio Browser; `all` junta os dois. Sem `kind`, rádio nunca aparece."Input schema / properties / language / descriptionAdded value: +"Idioma do canal, ISO 639-3."Input schema / properties / network / descriptionAdded value: +"Nome exato da rede/emissora."Input schema / properties / nsfw / defaultAdded value: +"0"Input schema / properties / nsfw / descriptionAdded value: +"`1` inclui conteúdo adulto; exige consentimento 18+ gravado, senão 403."Input schema / properties / nsfw / enumAdded value: +[
+ "0",
+ "1"
+]Input schema / properties / online / defaultAdded value: +"0"Input schema / properties / online / descriptionAdded value: +"`1` traz só canal visto online pela fonte (IPTV Nexus para TV, Radio Browser para rádio) nas 48 h anteriores à última recarga do catálogo (`health_ext.online`); com o catálogo parado há mais de 48 h o filtro não devolve ninguém."Input schema / properties / online / enumAdded value: +[
+ "0",
+ "1"
+]Input schema / properties / playable / defaultAdded value: +"1"Input schema / properties / playable / descriptionAdded value: +"`0` inclui canal sem stream utilizável conhecido."Input schema / properties / playable / enumAdded value: +[
+ "0",
+ "1"
+]Input schema / properties / q / descriptionAdded value: +"Texto livre no nome e nos apelidos do canal (busca full-text)."Input schema / properties / quality / descriptionAdded value: +"Qualidade exata do stream."Input schema / properties / sort / defaultAdded value: +"name"Input schema / properties / sort / descriptionAdded value: +"`score` ordena pela saúde medida por terceiro (IPTV Nexus), melhor primeiro; canal não medido vai para o fim. `votes` ordena pelos votos da comunidade do Radio Browser (rádio). `name` é a ordem alfabética."Input schema / properties / subdivision / descriptionAdded value: +"Estado/província, código do iptv-org."Input schema / properties / tag / descriptionAdded value: +"Tag da estação de rádio (vocabulário livre do Radio Browser, ex. `mpb`, `news`); veja `GET /api/tags`."legacy_streamadd_favoriteadd_itemapi_indexauth_startauth_verifybillingchannel_healthchat_historychat_passchat_sendclear_historycontactcreate_categorycreate_groupcreate_guestdelete_commentforget_watchgeoget_channelget_channel_guideget_historyget_libraryhealthlist_citieslist_commentslist_countrieslist_favoriteslist_languageslist_networkslist_qualitieslist_subdivisionslist_tagsmemint_keynsfw_consent_acceptnsfw_consent_revokensfw_consent_statusnsfw_pass_buynsfw_pass_statusplay_reportspost_commentproducer_servicesrecord_watchremove_favoritereport_playsearch_channelsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Create and run 24/7 linear TV channels. Import videos by URL; we transcode, schedule and stream.
Control your internet radio from any AI client: listeners, stream, playlists, AutoDJ, DJs, store.
Radio MCP — wraps Radio Browser API (free, no auth)
Search 1.2M+ Telegram channels, 245k+ chats, 160k+ bots — no account, no key, no install.
Add one secure layer between your agents and this server.
Each tool addresses a distinct resource/action: favorites vs. history vs. watch recording are clearly separate, and the NSFW consent/pass tools are unambiguous. Even closely related tools like 'get_channel', 'get_channel_guide', and 'legacy_stream' serve different purposes. No two tools appear to do the same thing.
Most tools follow a verb_noun pattern (get_, list_, create_, add_, remove_, etc.) with clear conventions. A few exceptions exist like 'billing', 'geo', 'health', and 'me', which are nouns and break the pattern slightly, but the overall style is predictable and readable.
With 47 tools, the server is far beyond the typical well-scoped range (3-15). While the API covers a broad domain (auth, catalog, chat, comments, billing, NSFW), this many tools would be better split into smaller, focused servers. The count feels bloated and could overwhelm an agent.
The tool surface is quite comprehensive for a streaming service: it includes auth, user preferences, favorites, history, catalog search, channel details, comments, chat, NSFW consent/passes, billing, and reporting. Minor gaps exist (e.g., no update/delete for categories/groups, no comment editing), but these are not critical dead ends.
