openclaw_config_patch

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

With no annotations, the description fully informs about destructive atomic replacement and optimistic locking via base hash. It also mentions the convenience flow's internal fetch-merge-submit steps. Additional details like error handling or permission requirements are absent, but the core behavioral traits are well communicated.

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 focused paragraph that front-loads the primary purpose and concisely explains the two modes of operation. Every sentence contributes useful information without excessive verbosity.

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 complexity of 5 parameters and no output schema, the description covers usage patterns and destructive nature but omits return values, error responses, and prerequisites beyond mentioning the baseHash source. This leaves the AI agent needing to infer some aspects.

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?

All 5 parameters are documented in the schema with descriptions, achieving 100% coverage. The description adds context about the two flows (raw/baseHash vs mergePath/mergeValue) and the role of baseHash from a previous get call, but this aligns with schema information. Thus baseline 3 is appropriate.

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 states that the tool performs an 'Optimistic-locked replace of the FULL gateway config' and explains both the direct raw+baseHash flow and the convenience mergePath+mergeValue flow. This distinguishes it from sibling config tools like openclaw_config_set (likely partial updates) or openclaw_config_apply (possibly different semantics).

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 provides clear guidance on when to use each flow: the raw+baseHash approach for pre-serialized configs and the mergePath+mergeValue for targeted deep-merges. However, it does not explicitly compare with or exclude other config tools, though the destructive note implies caution.

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