opencode_provider_models

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

With no annotations, the description carries the full behavioral burden, yet it gives nothing beyond the word 'List'. It does not state that this is a read-only operation, that providerId must reference a valid/configured provider, or whether results are paginated (the limit param hints at paging but this is not explained). For a tool with zero annotation coverage this is a notable gap.

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 efficient sentence with the resource front-loaded and no filler. It is perhaps slightly under-specified rather than concise, but there is no wasted content.

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 listing tool with no output schema, the description is minimally adequate but leaves open what a returned model entry contains and how limit interacts with paging. It is complete enough to call the tool, but thin on context an agent would find useful.

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 67%: limit and directory are documented in-schema, but the required providerId has no schema description. The description only implies providerId via 'for a specific provider' and adds nothing about limit or directory behavior. Baseline 3 applies since the schema does most of the work and the description adds marginal value.

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 (List) and resource (models) scoped to a provider, which is clear enough to distinguish from siblings like opencode_provider_list (providers) and opencode_provider_auth_methods. However, it never names those siblings or otherwise anchors the distinction, so the differentiation is inferred rather than stated.

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?

There is no when-to-use guidance, no prerequisites, and no mention of how it relates to opencode_provider_list or opencode_tui_open_models. The agent must infer when this tool is appropriate purely from the name and one-line description.

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