opencode_get_config

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the return shape and warns implicitly that the payload includes bulk content (instructions), but says nothing about size, sensitivity of config values, or failure modes.

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?

Front-loaded one-line purpose followed by return format, with no filler prose. The '## Examples' block showing `opencode_get_config()` adds nothing for a zero-arg tool and could be dropped.

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?

No output schema exists, but the description compensates with an explicit return format ({success, message, data.config}). For a parameterless read, that is nearly everything an agent needs, short of noting that config may contain secrets or be large.

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?

Zero-parameter tool, so the baseline is 4; the empty schema with additionalProperties false leaves nothing for the description to explain.

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+resource ('Read the full opencode configuration') and enumerates what it contains (model, provider, MCP server settings, instructions), which clearly separates it from session/run siblings. It does not explicitly name which sibling to use instead for narrower reads like providers or project.

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 statement of when to use this versus opencode_list_providers, opencode_get_project, or opencode_system, nor any preconditions. Usage is only inferable from the tool name and the word 'full'.

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