get_simulation_info

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

No annotations are provided, so the description must carry the full behavioral disclosure burden. It only uses the word 'Get', which implies read-only behavior, but it does not say whether the tool triggers cooking, shows live state, has side effects, or what it returns.

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 front-loads the core purpose, followed by a simple parameter note. There is no filler, though the terse style contributes to under-specification in other dimensions.

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?

Given no annotations, no output schema, and only a one-parameter schema with no parameter descriptions, the description is too thin. An agent would not know what kind of information or object the tool produces, nor how to interpret the returned simulation state.

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?

The line 'node_path: DOP network node path' adds a small amount of meaning beyond the schema's generic 'Node Path' title. However, with 0% schema description coverage, it should more thoroughly explain what a valid DOP network node path looks like and what node types are accepted.

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 says 'Get DOP network simulation state', which identifies a verb and a resource area, but 'simulation state' is vague and left undefined. It does not differentiate this from closely-related sibling tools such as get_dop_field, get_dop_object, list_dop_objects, or get_sim_memory_usage.

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?

No guidance is given for when to use this tool versus the many DOP-related siblings. There is no mention of prerequisites, intended workflow, or situations where a different tool would be more appropriate.

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