Stream metadata

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

Annotations already mark readOnlyHint and openWorldHint, and the description reinforces this with 'SPA GET contracts; no DownloadVideo'. It adds behavioral context beyond annotations by disclosing auth requirements per source, e.g., 'downloads: Bearer only (exported file list)'. No contradiction exists between description and annotations.

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 scannable: one introductory line plus three source-specific bullets. Every sentence contributes either the resource definition, an exclusion ('no DownloadVideo'), or a parameter requirement. There is no filler or repetition of the input schema.

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 six optional parameters and source-dependent behavior, the description covers the main conditional logic well. It does not explain the 'compact' parameter, which is undocumented even in the schema, and some phrasing like 'SPA GET contracts' assumes API familiarity. However, the output schema exists, and the description provides enough per-source guidance to invoke the tool correctly in most cases.

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 high at 83%, so the schema already documents most parameters. The description adds cross-parameter meaning by linking sources to required fields: which_content uses DateTo, videos requires DateFrom/DateTo with a UserID header, and downloads is an export list. This goes beyond the flat schema descriptions by clarifying conditional usage.

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 'Desktop video metadata' and the operation as 'SPA GET contracts', which together imply a read-only listing operation. The name 'list_stream_meta' adds the explicit verb. It does not explicitly distinguish from siblings, but the sibling tools cover clearly different domains such as users, risks, and analytics.

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 per-source usage context: 'which_content: needs user_id', 'videos: needs user_id + DateFrom/DateTo', and 'downloads: Bearer only'. This tells the agent what inputs and authentication each variant requires. It does not explicitly name alternatives or state when not to use the tool, but the source-specific guidance is strong enough for practical invocation.

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