ise_openapi_cert_trusted_update

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 transparency. The description only identifies it as an HTTP PUT operation, which implies a full replacement update, but doesn't disclose field-level replace-vs-patch semantics, whether partial updates merge or overwrite, permission requirements, or response behavior. For a mutation tool with zero annotation coverage, more behavioral context is needed.

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, compact sentence that front-loads the purpose and includes the endpoint for reference. It's efficient with no wasted words. The endpoint inclusion is marginally useful but slightly redundant with the tool's functionality.

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 mutation tool (PUT) with no annotations, no output schema, and a nested 'data' object parameter that isn't explained. The description doesn't address what the response contains, whether errors occur when the id doesn't exist, or the prerequisite of fetching the certificate first via trusted_get. For a complex update operation with a nested body, the description leaves significant gaps.

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 already documents all three parameters. The description adds minimal parameter context beyond the schema—'id' is a path parameter for which certificate, and 'data' is the JSON body, but the description doesn't clarify what fields are needed in the data body for a trusted certificate update. With full schema coverage, baseline 3 is appropriate, though the description could add value by noting the body format.

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 it updates an existing trust certificate in the Cisco ISE trust store, naming the specific endpoint (PUT /api/v1/certs/trusted-certificate/{id}). The [Certificates] prefix groups it with cert tools, and the verb 'Update' with resource 'trust certificate' makes the action clear. It distinguishes reasonably from sibling tools like ise_openapi_cert_trusted_delete and ise_openapi_cert_trusted_import.

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 implies this is used when a trusted certificate already exists and needs updating ('already present in the trust store'), which subtly differentiates it from import/create flows. However, it doesn't explicitly state when to choose this over import, delete, or get variants, nor does it specify prerequisites (e.g., whether the certificate must be listed via trusted_list first). The guidance is implied rather than explicit.

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