audit_performance

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

With no annotations provided, the description must fully disclose behavioral traits. It does enumerate what is audited, but omits critical details: whether the audit is read-only or modifies anything, potential performance impact on live hot paths, or what the output/report format looks like. This leaves significant ambiguity for an agent deciding whether to invoke the tool.

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, front-loaded sentence that directly states the action and scope. Every phrase carries meaning, listing specific audit areas without redundancy or filler. It is optimally concise for its complexity level.

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?

All parameters are documented and the purpose is clear, but the absence of an output schema and any mention of return values means agents don't know what to expect from the tool's response. For an audit tool that likely produces a report, this is a noticeable gap, though the simplicity of the input schema partially compensates.

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%, with each parameter (side, query, offset, max_scripts) having a clear description. The tool description itself adds no extra parameter meaning, so the baseline of 3 applies. It neither enhances nor undermines the schema's clarity.

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 the tool's function with a specific verb ('Audits') and a defined resource ('live hot paths'), and lists concrete audit targets like per-frame allocation, cloning, and raycast pressure. This distinguishes it from sibling audit tools (e.g., audit_lifecycle, audit_data_integrity) which focus on different concerns.

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 usage for performance hot-path analysis but offers no explicit guidance on when to choose this tool over alternatives like audit_lifecycle or detect_race_conditions. There are no stated exclusions or use-case comparisons, leaving the agent to infer applicability from the tool name and description.

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