GlobeNow.tv live world news

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

Annotations already declare readOnly, idempotent, and openWorld, so safety needs no restating. The description adds real value by enumerating the returned payload (per-country counts, outlet lists, languages, start dates, videos with original and translated titles, coordinates, links) — important since there is no output schema.

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 sentence, front-loaded with the purpose before the return-value list. It is dense but every enumerated item is meaningful output information; no filler or repetition of the tool name.

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 output schema, the description carries the return-value burden and does so well, and it names the input source for event_id. Minor gaps remain: ordering of countries is only stated in the schema, and behavior for an unknown or expired event_id is not described.

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 event_id, language, per_country, and max_countries including defaults and bounds. The description only adds a hint that 'original and translated titles' relate to the language parameter, which the schema already states. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb-and-resource pair ('compare coverage of a story by country') and immediately enumerates what the comparison yields: video counts, outlets, languages, coverage start date, and latest videos. It also distinguishes itself from search_news_events by naming that tool as the source of the event_id.

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 parenthetical '(event_id from search_news_events)' makes the prerequisite and the routing between siblings explicit — an agent knows to find an event first, then compare it. There is no explicit when-not or exclusion, but the scope ('for one story') is clear enough that misuse is unlikely.

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

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

Annotations already cover the read-only, idempotent, open-world, non-destructive profile, so the description builds on that by disclosing the data source (official broadcaster YouTube streams), the returned fields, and a notable behavioral trait: MCP Apps clients can play the stream inline or in picture-in-picture, which materially affects how a client should present results. It doesn't mention rate limits, freshness of 'current viewers', or failure modes for geo-blocked channels.

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 dense sentences with no filler, and the core identity of the resource is front-loaded. The second sentence mixes return-field disclosure with client-capability notes, which makes it slightly overloaded but each clause carries 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?

No output schema exists, so the description carries the burden of describing results — and it does, enumerating country, language, worldwide availability, current viewers and links. With all six params schema-documented, the main remaining gap is nothing structural; only pagination/limit behavior and result ordering go unmentioned.

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 every parameter is already documented with examples and the language enum. The description only echoes the category and country concepts ('news, business, kids, music, religious and more' matching the category param) without adding filtering semantics such as how query and category interact or how limit defaults behave. 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?

Names the resource precisely and with strong qualifying detail: free, official, 24/7 live TV channels streamed on YouTube. It never states the verb (find/search) explicitly in the description, relying on the name, but the subject matter is unambiguous enough that an agent knows exactly what corpus it returns and how it differs from news-event siblings.

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 only implied — an agent infers 'call this when you want live TV channels.' There is a useful implicit scope constraint (YouTube-hosted broadcasts only), but no when-to-use/when-not guidance and no reference to the sibling news tools that might otherwise cover similar content.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real value beyond that: it discloses the default look-back window and, importantly, the shape of the payload (outlets, coordinates, YouTube links, related stories, city page and 3D globe links), which matters because there is no output schema. It does not mention pagination, rate limits, or behavior when no videos exist.

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 dense sentence with the core operation front-loaded and the time default immediately after, followed by the return inventory. No filler or repetition of the title.

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 read-only lookup with fully documented parameters and no output schema, the description covers purpose, default window and return contents, which is enough to call it correctly. The missing piece is sibling differentiation, which is the only real gap given three adjacent news 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?

Schema description coverage is 100%, with city examples, hours range/default, limit range/default and a language enum all documented in the schema. The description only restates the 24-hour default, which the schema already states ('default 24, max 168'). Baseline 3 applies since the schema carries the parameter burden.

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 gives a specific verb+resource+scope: 'Latest news videos filmed or reported in a city', with a default time window. It also enumerates what comes back (outlets, coordinates, YouTube links, related stories). It does not name or differentiate against the siblings (search_news_events, find_live_tv, compare_event_coverage), so an agent must infer the boundary between city-scoped news videos and general event search.

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 only usage signal is the implicit '(default: last 24 hours)'. There is no statement of when to pick this over search_news_events or find_live_tv, no prerequisites, and no exclusions. With three closely related siblings, the description leaves the routing decision entirely to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real context beyond that: the recency window, the fact that stories are grouped from videos across many outlets, and exactly which fields are 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?

Two tight sentences with no filler. Recency and grouping scope come first, and the empty-query rule closes with a concrete action, so the most decision-relevant 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?

With no output schema, the description carries the return-value burden and does so: event_id, summary, countries, outlet/video counts, and links. Freshness window and empty-query default are also covered, leaving nothing an agent needs before calling 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 80%, so limit, query, country, category and language are already documented. The description still contributes the non-obvious semantic that an omitted query returns top stories, which the schema does not state for the optional query field.

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 and resource ('Find news stories'), plus the scope that makes it distinct: stories 'GlobeNow is tracking now or in the last few days, grouped from videos by many outlets.' An agent can distinguish this from compare_event_coverage or get_city_news by the aggregation scope, though no sibling is named explicitly.

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 empty-query behavior ('Leave query empty to list the top stories right now') is a concrete usage rule. However, there is no guidance on when to prefer this over get_city_news or compare_event_coverage, and no exclusions or prerequisites are stated.

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