iva_system

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists actions like 'SMS approval, crash report, mail to support' but does not disclose that these are side-effect operations, whether authentication is required, or any consequences such as sending emails or confirming destructive actions. The behavioral detail exists only in the input schema, not in the description.

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 and front-loaded with the module name, followed by a comma-separated list of capabilities. It is efficient and scannable, though the phrase 'system info' is repeated and the structure is more of a tag list than a complete sentence.

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?

This is a high-complexity aggregate tool with 10 possible actions, multiple optional parameters, nested objects, and no output schema. The description is only a one-line capability list and does not explain return values, required inputs for nested objects like smsData and mailData, or operation-specific behavior. The schema helps, but the description alone is not sufficient for an agent to call all variants confidently.

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 100%, and the action enum provides meaningful descriptions for each operation, including the confirm destructive-action flag and the crash-report file parameter. The description itself adds little parameter-level meaning, but the schema already covers this dimension adequately.

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 the tool's domain as 'IVA system info' and enumerates concrete capabilities: system info, media info, ICE servers, layouts, broadcast notifications, SMS approval, crash report, mail to support, and client applications. It is clear that this is the system-level utility tool, though it lacks a single strong verb and is broader than a typical single-purpose tool.

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 no guidance on when to use this tool versus alternatives such as iva_conference_media, iva_file_resources, or iva_profile. The scope is implied by the list of system-level operations, but there are no explicit when-to-use or when-not-to-use instructions.

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