decision_get

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

Annotations already provide destructiveness and read/write hints, so the agent is warned that this is not a pure read operation. The description does not contradict the annotations, but it also does not explain why a 'get' operation is flagged destructive or what exactly may happen to the graph when the node is fetched.

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 compact sentence that puts the verb and resource first and contains no redundant filler. Every word contributes to the meaning of what the tool returns.

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?

The description does state the main output shape: the node and all nodes connected to it by edges in either direction. But there is no output schema, so the agent still lacks detail about how edges, directions, or node data are returned, and the destructive annotation is left unexplained.

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 only parameter is fully described by the schema: id is the Decision Graph node id. The description adds only the slight extra meaning that id is the starting node from which connected nodes are followed, so it has limited additional value.

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 concrete operation ('Get'), a specific resource ('a Decision Graph node'), and a clear output shape ('every node connected to it by an edge in either direction'). It is specific enough to distinguish the tool from the many decision_* siblings without needing to inspect 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?

The description implies when to use the tool: when the agent needs a decision graph node and its graph-connected neighbors. However, it does not explicitly state when to prefer it over closely related sibling tools such as decision_list or decision_history, nor does it give any excludes or alternatives.

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