ise_dc_view_posture_assessment_by_endpoint

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The description frames this as a read-only 'Report' view, which is useful, but it does not disclose response format, pagination behavior beyond the limit parameter, the meaning of the 'time column' used by days_back, or any caveats about data retention/availability. For a report tool with zero annotation coverage, more disclosure is warranted.

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 a single, efficient paragraph that packs the report identity, purpose, and filterable columns into a concise block. The filterable column list is dense but genuinely useful. No wasted words or 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?

The description covers the view's purpose, its view-details capability, and its filterable columns, which is strong for identifying the data content. However, given 7 parameters, no output schema, and no annotations, a bit more is needed: clarifying the output shape, the time-column basis for days_back, and how this report relates to the generic ise_dc_query would make it complete. It's adequate but not full.

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%, so all 7 parameters have descriptions in the schema itself. The description adds the filterable columns list (SYSTEM_DOMAIN, SYSTEM_USER, IP_ADDRESS, etc.) which gives concrete meaning to the filter_column parameter and clarifies the view's contents. With high schema coverage and a useful column listing, score 3 is the appropriate baseline.

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 '[Report]' prefix and 'Posture Assessment By Endpoint' clearly identify this as a report view showing which endpoints have been subject to posture assessment. The description clearly states the tool's purpose of viewing posture assessment details per endpoint, which distinguishes it from the many other ise_dc_view_report tools by naming the specific view.

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 mentions the view shows endpoints subjected to posture assessment and gives the administrator ability to view details, establishing an implied use context. However, there is no explicit guidance on when to use this tool versus the alternative report views like ise_dc_view_endpoints_data or when to prefer generic ise_dc_query/view tools. With 7 parameters and many sibling report views, explicit differentiation would help.

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