create_view

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds genuinely useful context beyond that: with replace=true the prior definition is preserved in query_log (so the operation is non-lossy), and the description field is stored inside the view and surfaced by get_schema. It does not cover failure behavior on name collisions without replace, so not a 5.

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?

Three tight sentences, front-loaded with the primary action, then the cross-session description rationale, then the replace behavior. Every clause carries information that is not duplicated in the schema or annotations.

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?

With annotations covering the safety profile and no output schema to explain, the description is complete enough for correct invocation, including the recoverability of replaced definitions and cross-tool visibility of the description field. Minor gap: no statement about what happens on name conflict when replace=false.

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 100%, so baseline is 3, but the description adds meaning the schema lacks: replace also retains the old definition in query_log, and the description parameter is not merely stored but exposed through get_schema. select_sql semantics remain purely schema-defined.

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 a specific verb and resource ('Save a SELECT as a named view') and even defines the concept as 'a reusable query skill', so an agent immediately knows this creates a persistent view object. It does not explicitly distinguish itself from siblings like write_query or checkpoint, which keeps it just short of 5.

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?

Usage is implied rather than stated: the note that a description helps 'future sessions know what it is for' hints at creating reusable queries, and the replace semantics imply the update path. However, it never names an alternative tool or an explicit when-not-to-use condition, so guidance is only inferred.

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