list_violations

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

Annotations already mark it read-only and idempotent, but the description adds substantial behavior beyond that: the exact envelope structure, field list, sort order, unbounded total ("so nothing is hidden"), and the empty-envelope behavior when no scan exists. It also specifies "no network calls," enriching the safety and execution model.

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 dense but every sentence adds value: parameter details, return format, sort order, pagination, prerequisite, read-only nature, and next step. It is longer than strictly minimal, but the length is justified by the lack of schema descriptions and output schema. The structure is logical, progressing from purpose to parameters to output to usage notes.

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?

Despite having no output schema and minimal parameter schema, the description fully covers what an agent needs: input semantics, output envelope, pagination, sorting, edge case (no scan), and relationship to other tools (scan_target, get_remediation). The sibling context and annotations help, but this description would stand alone well.

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 fully compensates. It explains severity with valid values ('critical', 'high', 'medium', 'low', 'info') and omit behavior, limit with default and purpose, and offset with paging semantics. It also clarifies the meaning of the returned fields and pagination logic, going far beyond the 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 opens with a specific verb and resource: "List compliance violations recorded by the most recent scan snapshot in the local twin DB." This clearly states what the tool does and scopes it to a particular snapshot, distinguishing it from sibling tools like list_baselines, list_drift_events, and get_remediation.

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 gives clear context: it is a read-only local DB query with no network calls, and it explains the pagination workflow. It also provides a prerequisite ("run scan_target first" if no scan exists) and a downstream step ("Pass a row's 'id' to get_remediation for a fix plan"). It does not explicitly contrast with every sibling tool, but the usage context is sufficient.

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