get_media_input_status

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

With no annotations, the description carries the full burden. It accurately describes the output (playback state, duration, cursor) without misleading claims, but it does not disclose error behavior, return format, or explicit read-only nature. For a simple getter, this is acceptable but minimal.

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 with no redundant content, making it efficient and front-loaded. It could be improved with an action verb, but it succeeds in conveying the core purpose without waste.

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 (one required parameter, no output schema), the description covers the essential semantics but omits return format, explicit mention of the required parameter, and error handling. This is slightly below the minimum viable completeness for a tool without annotations or an output schema.

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 0% and the description does not explicitly explain the input_name parameter. The phrase 'of a media source' indirectly hints at the parameter, but it doesn't connect it to the input schema or provide validation details, leaving the agent dependent on the parameter name 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 identifies the resource (media source) and the data returned (playback state, duration, cursor position). It's specific and differentiated from sibling tools like set_media_input_cursor or offset_media_input_cursor by the nature of the query, though it lacks an explicit verb like 'Gets' or 'Retrieves'.

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 name implies it's the getter for media status, but the description does not state any preferred context or exclude other tools, leaving the agent to infer usage 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.