list_inventory_items

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

No annotations provided, so description carries full burden. It discloses return format (JSON string, camelCase keys, excluded null values), pagination behavior (limit/skip), and detailed error types (ValueError, InventoryAuthenticationError, etc.). Also mentions performance trade-offs for fetch_fields options.

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?

Description is well-structured with summary, usage guidance, parameter details, returns, and raises sections. It is front-loaded with the core purpose. While verbose, each sentence adds value and there is no redundancy.

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 4 parameters and no annotations, the description covers all relevant aspects: pagination, filtering, field selection, output format, and exceptions. The output schema exists (context signal), so return details are adequate. Minor gap: no mention of rate limits or authentication prerequisites beyond error types.

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%, but description fully explains all 4 parameters. limit, skip, and surface are clearly defined with ranges and enum options. fetch_fields is exceptionally detailed with preset names, field counts, and syntax examples. This adds significant meaning beyond the schema's type/defaults.

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 'List managed assets in SentinelOne with pagination and optional filtering,' specifying the exact verb and resource. It distinguishes from sibling tools like get_inventory_item (single item) and search_inventory_items (different query mode).

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 says 'Use this tool to browse SentinelOne managed assets' and provides parameter context like surface filter and fetch_fields options. However, it does not explicitly exclude cases where alternative tools (e.g., get_inventory_item for a single item, search_inventory_items for complex filters) would be more appropriate.

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