Manage events

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

The description adds genuinely useful safety context that booleans cannot express: only one action is destructive, it is gated by a two-step confirm_hash, and access_denied should be treated as a skip. But it directly conflicts with the tool annotation destructiveHint=false by asserting that delete is destructive, giving the agent two contradictory signals about safety; that conflict caps the score.

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-loaded with the resource, then the action set, then the safety and error semantics in a few dense clauses with no filler. The only cost of the compression is slight ambiguity in fragments like 'code=access_denied means skip', where the referent is not spelled out.

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?

An output schema exists, so return-value explanation is legitimately omitted, and the description does cover the critical safety flow. But for a 6-parameter mutation tool with 0% schema coverage, it leaves the fields required by each action (e.g. title for create, event_id for rename/delete) unaddressed, so an agent still has to guess per-action argument requirements.

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 0% across 6 parameters, so the description carries the full explanatory burden. It explains the action values (which the enum already conveys) and hints at confirm_hash via the 'two-step confirm_hash' flow, but says nothing about confirm, event_id, event_type, or title, leaving most of the parameter surface undocumented.

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 names a specific resource domain (conversion events and pixels) and enumerates the concrete action verbs (list|create|rename|delete|create_pixel), so an agent knows exactly what surface this tool covers. It does not explicitly differentiate itself from similarly named siblings like manage_audience or manage_funds, so it stops short of a 5.

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?

Action-level usage is implied well: list is read-only, delete needs a two-step confirm_hash, and access_denied should be skipped rather than retried. However, there is no explicit 'use this tool when X, use sibling Y otherwise' guidance, and no stated prerequisites for create/rename, so usage is only partially inferable.

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