ipc_eventlog

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

Annotations already declare destructiveHint=true and non-readOnly, but the description goes further: it discloses that it runs wevtutil through the System Service, reads back a temp file and deletes it, that it starts a process on the IPC (the reason for the destructive class), and that the confirmation token is required. That is meaningful behavioral context beyond the structured flags.

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?

Front-loads what the tool does and the key caveat, with every sentence carrying information. It is a little dense and the provider sentence is convoluted, but nothing is padding.

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?

For a destructive, process-spawning tool with an output schema present, the description covers the safety workflow, platform exclusions, and the surprising provider-listing side effect. Only the per-parameter meanings (count, confirm_token) remain thin.

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%, so the description must carry the parameter burden, and it only partially does: 'target=<log>' implies the log-name parameter and the TwinCAT/Beckhoff discussion implies the provider parameter, but 'count' and 'confirm_token' semantics are never explained. Partial compensation only.

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?

States a specific verb+resource: it reads the Windows event log of the target IPC (via wevtutil) and additionally enumerates TwinCAT/Beckhoff event providers. This distinguishes it clearly from the other ipc_* siblings (file/dir/process/reboot) which do different things.

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?

Explicitly states the when-not ('Not available on Windows CE / TC-BSD targets') and prescribes the required pre-step (confirm with tc_request_confirmation(action='ipc_eventlog', target=<log>)). It also explains why the provider-listing behavior exists, so the agent knows what to expect.

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