rhino_named_views

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

No annotations are present, so the description carries full behavioral disclosure burden. It reveals the four action types, notes that view_name is required for save/restore/delete, and describes the return shape. However, it omits the default action (list), does not warn that 'delete' is destructive, and does not clarify whether 'save' creates or overwrites. The mention of a controller parameter not present in the schema adds ambiguity.

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 compact, front-loads the purpose, and uses a standard Args/Returns structure. Every sentence earns its place; no padding or repetition. It is appropriately sized for a two-parameter dispatcher tool.

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 multi-action tool with no annotations and minimal schema, the description covers the essential actions and parameter semantics. Yet it leaves gaps: the default action when action is omitted, error or validation behavior, and the controller parameter's provenance. These omissions could cause an agent to misinvoke the tool, though the core interface is understandable.

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 must explain parameters, and it does so meaningfully: action's allowed values are listed, and view_name's conditional requirement is stated. It also introduces the controller parameter, though without full clarity on its role. This compensates well for the otherwise bare schema.

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 states 'Manage named views' and enumerates the four operations (list, save, restore, delete), making the tool's purpose concrete. It distinguishes itself from single-purpose siblings like rhino_named_view_save by covering all management actions in one dispatcher. The verb 'manage' is slightly generic, but the action list resolves ambiguity.

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 guidance on when to choose this tool over alternatives such as rhino_named_view_save or rhino_view_set. It does not mention prerequisites, context, or when not to use it. The usage must be inferred entirely from the action list, leaving the agent without explicit routing information.

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