wb_call_method

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

Annotations already indicate destructiveHint=true, but the description adds crucial specifics: it requires confirm_write for write endpoints and both confirm_write and i_understand_this_modifies_data for destructive endpoints. This directly discloses the safety behavior. It also notes that nothing is sent otherwise, which is a clear behavioral contract. The description complements the annotations without contradicting them.

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 efficiently structured: a one-sentence summary, a clear safety warning front-loaded, and a bulleted list of parameters. Each line has a purpose, and the most critical information (safety requirements) is at the top. No fluff.

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 tool with 6 parameters and an output schema, the description covers the core invocation logic and safety requirements. It mentions the return shape ({ok, status, data}) and error envelope, matching the output schema, so no need for further explanation. However, it doesn't cover edge cases like how to obtain operation_ids (though that is delegated to search_methods) or how path_values should be formatted, but given the schema does not provide details either, the agent must infer. This is a minor gap.

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 0%, so the description must fully explain each parameter. It does: operation_id is traced to the catalog, path_values corresponds to {placeholders}, query is for query-string parameters, body is the JSON request body, and the two booleans are given explicit names. This compensates perfectly for the lack of schema descriptions.

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 the tool's primary function ('Execute one catalog endpoint by operation_id') and distinguishes it as part of a family of tools. However, it doesn't explicitly differentiate from siblings like wb_call_raw, which might be a conflict; the agent must infer that wb_call_method is the higher-level version that understands the catalog, while wb_call_raw is lower-level. This inference is possible but not spelled out.

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 clearly states when to use it: for executing a specific catalog endpoint by operation_id. It also implies alternative tools like wb_search_methods for finding operation_ids, and wb_call_raw for raw calls, but does not explicitly say 'use X instead when...'. The differentiator from wb_call_raw is implicit in the description's reference to the catalog.

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