diana_autostart

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

Annotations only declare openWorldHint=false and idempotentHint=true, so the description carries the real load — and does: it names the two files written and where, says they are inert outside DianaIE, documents that the bridge binds to 127.0.0.1 with a random token stored in local app data, and warns the change only applies to sessions started afterwards. That is exactly the side-effect, security, and timing context an agent needs before mutating a user's environment.

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?

Two short paragraphs: the first leads with the outcome, the second with mechanism, safety, and timing caveats. Nearly every clause earns its place, though the file names could arguably be trimmed as implementation detail.

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 values needn't be described, and the text covers mechanism, blast radius, network exposure, and activation timing. The remaining hole is behavioral coverage of the status action, which is the default and therefore the most likely invocation.

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 one enum parameter, so the description must define all three values. It explains enable and, by implication, disable, but never describes what status returns or that it is the default action — an agent must infer that from the enum. 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 and resource with scope: make every DianaIE session start the bridge automatically, so change tracking and live tools work. It explicitly distinguishes itself from diana_start ("without the command-console line or diana_start") and explains the mechanism (two .pth/.py files in the embedded Python's user site-packages).

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?

Gives a clear use condition — only enable or disable when the user asks — and names diana_start as the alternative path when autostart is not in play. It does not say when the third action, status, should be used versus enable/disable, nor whether checking status is always safe to do unprompted.

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