omniseek_view

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. It does so comprehensively: return block shapes per kind, contact sheet fallback behavior, max_images caps, 30-minute video cap, text-format note, bilibili session sharing, and an honest 'nothing to show' error note. No contradictions 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?

The description is long but every section earns its place given three modes and ten parameters. It is front-loaded with a one-line summary, then routing, then per-kind parameter details, then return format. Headers and bullet-like lines make it easy to scan despite length.

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 complex multi-mode tool with no output schema and no annotations, the description is remarkably complete. It covers all three input kinds, per-kind parameter behavior, return formats, fallbacks, limits, error handling, and relationships to sibling tools like omniseek_read and omniseek_transcribe. The only minor omission is contact_sheet's explicit role as a boolean flag.

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%, so the description compensates by explaining target, kind, sections, names, max_images, render_pages, start/duration, and n in context. However, the contact_sheet boolean parameter is never explicitly defined as a parameter; it is only implied through phrases like 'you get a CONTACT SHEET.' This is a minor but clear gap.

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 one-line statement of what the tool does: 'SEE with your own vision, IN-BAND — document figures, loose image URLs, or video frames.' It then breaks out three distinct modes (document, images, video) and explicitly contrasts with related tools like omniseek_read and omniseek_transcribe, so an agent can distinguish it from 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?

Extremely explicit routing rules are given for kind='auto' with file extensions and host names. It describes when to use the two-step process (omniseek_read first), when to use render_pages instead of sections/names, and when to pair with omniseek_transcribe for video. This is far beyond 'use when you need to view visual content.'

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