supabase_disable_rls

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

With no annotations provided, the description carries the full burden. It successfully discloses the critical security impact ('removes all RLS protection') but fails to mention other important behavioral traits: whether the operation is reversible (via enable_rls), whether existing policies are deleted or merely disabled, or what permissions are required to execute this dangerous operation.

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 appropriately brief with two front-loaded sentences. The '[UNIFIED]' prefix appears to be metadata noise from code generation but does not significantly impair readability. The warning is appropriately positioned and weighted for a high-risk operation.

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 this is a destructive, security-critical operation with 0% schema coverage and no output schema, the description is minimally viable. It covers the primary risk (security removal) but leaves significant gaps regarding parameter semantics, reversibility, and operational prerequisites that would be necessary for safe autonomous use.

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%, requiring the description to compensate. While 'on a table' implicitly references the 'table' parameter, the description completely omits explanation of the 'site' parameter (which Supabase instance?) and 'schema' parameter (defaults to 'public'), leaving all three parameters effectively undocumented in natural language.

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 action ('Disable Row Level Security') and target resource ('on a table'), providing specific verbs and objects. However, it does not explicitly differentiate from the sibling tool 'supabase_enable_rls' in the text itself, relying on the verb to imply the distinction.

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 warning 'This removes all RLS protection' implies when not to use the tool (when security is required), serving as a guardrail. However, it lacks explicit positive guidance on when to use it (e.g., 'Use this when you need to temporarily disable access controls for maintenance') or mention of the inverse operation to restore protection.

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