What is airing right now, or at a given time. Returns programmes with descriptions and, for each, when the claim was observed and when it expires. Accepts free text.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | ISO 8601 instant. Defaults to now. | |
| limit | No | ||
| query | No | Free text: a title, genre, or channel name. Optional. | |
| outlet | No | Restrict to one channel by name. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It usefully reveals the output shape: programmes with descriptions and claim observation/expiry timestamps. However, it does not mention permissions, data freshness semantics, rate limits, or any side effects, so coverage 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?
Two tightly worded sentences with the core purpose front-loaded. Every clause adds information: time scope, response contents, observation/expiry timestamps, and free-text acceptance. There is no repetition or 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?
The description covers the essential purpose and return shape, which is helpful given there is no output schema and no annotations. Still, an agent is left without details on how 'claim observed/expires' should be interpreted, what 'limit' means, and how this tool differs from semantically adjacent siblings. 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 description coverage is 75%, and the description reinforces that query is free text and that time-based lookup is supported. Yet it adds no meaning for 'limit', which is undocumented in both the schema and the description, and it provides no additional nuance for 'outlet' beyond 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 opens with a clear, specific question ('What is airing right now, or at a given time') and explicitly states that it returns programmes with descriptions, observation time, and expiry time. This clearly identifies the resource and action. However, it does not explicitly contrast with sibling tools like media_verify or media_still_true, 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?
The description implies use for current or time-specific programme lookup and notes that it accepts free text, which gives some situational context. But it never states when not to use it or names alternatives among the eight siblings, leaving selection guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.