ise_openapi_radius_condition_create

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. The description does identify the API endpoint (POST /api/v1/policy/network-access/condition), which confirms this is a mutation operation, and the '[Policy: Network Access]' namespace scoping is useful. However, it doesn't disclose what happens on success (return values), idempotency, required fields within 'data', or whether existing conditions with the same name are rejected or overwritten. The HTTP POST verb is transparent about the write nature, giving some behavioral context, but the description remains thin on outcomes.

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 sentence providing the essential purpose and endpoint. It is front-loaded with the functional verb and resource. The '[Policy: Network Access]' prefix adds useful domain scoping. No wasted words. However, it could be slightly more informative about what a library condition is without becoming verbose.

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 create (mutating) operation with no annotations, no output schema, and a nested 'data' object whose internal structure is undisclosed. The description does not explain what a RADIUS library condition is, what properties the 'data' JSON body must contain, or what the successful response looks like. Given the complexity (mutating operation, opaque nested data payload, multiple sibling create tools), the description is substantially under-specified. The deployment parameter is well-documented in the schema, which helps, but the central 'data' payload and behavioral outcomes are unaddressed.

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 the schema documents both parameters (data as 'JSON request body' and deployment with detailed value formats). The description adds the endpoint context which implies 'data' carries the condition definition, but it doesn't clarify the structure or required fields inside 'data'. Given 100% schema coverage, a baseline of 3 is appropriate; the description doesn't add meaningful parameter semantics beyond what the schema provides, and the 'data' object's internal structure (a nested object, per context signals) remains opaque.

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 '[Policy: Network Access] Network Access - Creates a library condition. (POST /api/v1/policy/network-access/condition)' which gives a specific verb+resource for creating a condition. However, it doesn't differentiate from sibling condition tools like ise_openapi_radius_condition_list, ise_openapi_radius_condition_get, ise_openapi_tacacs_condition_list, and importantly from other 'create' variants (authorization_create, authentication_create, policy_set_create). The purpose is identifiable but the scope of what a 'library condition' is (vs other condition types) is not clarified.

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 provides no guidance on when to use this tool versus alternatives. There are multiple create tools (ise_openapi_radius_condition_create vs ise_openapi_radius_authentication_create, ise_openapi_radius_authorization_create, ise_openapi_tacacs_* siblings) and no distinction is drawn between 'library condition' creation and other condition-related operations. No exclusions, prerequisites, or alternative tool references are given. For a create operation in a complex domain, this is a significant gap.

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