profiler_manage

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

With no annotations, the description carries the transparency burden and discharges it by labeling every operation as 'Read' — clearly signaling no mutation or side effects. It also discloses the call-shape behavior (canonical op/params shape, flat-op compatibility alias, op/session_id top-level), which an agent needs before invoking.

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 compact and well organized: a one-line domain summary, four parallel operation bullets, and a single call-shape note. There is no filler or redundant schema repetition; every sentence earns its place and the most decision-relevant information is front-loaded.

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 multi-op read-only diagnostics tool with an output schema and no annotations, the description provides enough operational detail to select and invoke each op, including the canonical call shape. It is slightly incomplete in not explicitly stating that operations take no meaningful params and in not discussing when to use this tool instead of a sibling, but the output schema covers return details.

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%, so the description must compensate. It semantically documents the op enum by mapping each value to the data it returns, and it clarifies the top-level call structure, but it never explains the params object's contents or the session_id parameter. This is partial compensation: the primary selector (op) is well covered, while the other two parameters remain underspecified.

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 leads with a clear domain ('Engine Diagnostics, Performance Monitors, and Memory Analysis') and defines each exposed operation with a concrete verb and resource: get_monitors() reads Godot performance monitors, get_memory_info() reads memory breakdowns, get_render_info() reads render pipeline statistics, and get_physics_info() reads physics server stats. This makes the tool's scope distinct from the many sibling *_manage tools without needing to open their schemas.

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?

Usage is implied by the content: an agent can infer this tool is for reading profiling/monitoring data rather than configuring systems, but the description never states when to prefer profiler_manage over related siblings such as rendering_manage, physics_manage, or system_manage. It provides no explicit when-not-to-use guidance or exclusions.

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