session_get

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

readOnlyHint=true already declares this as a safe read, so the "[READ]" tag is largely redundant. The description does add that this is a polling tool for tracking progress over time, which is useful behavioral context, but it does not disclose return format or pagination behavior.

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?

Front-loads the read tag and purpose, then usage guidance, then an Args block. The structure is clean and the content is tight, with mild redundancy between the [READ] tag and the readOnlyHint annotation.

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 simple two-parameter polling tool with no output schema, the description covers purpose, usage, and both parameters. The main omission is what the poll returns and whether the session can fail, but that is a minor gap given the tool's narrow scope.

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 coverage is 0%, so the description must carry the burden, and it does document both parameters: session_id as a Veeam session id (pointing to session_list) and target as a Veeam target name from config. This meaningfully compensates for the empty schema descriptions.

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 (poll/get) and resource (one session by id) plus the intent (check job/restore progress). The singular "one session by id" cleanly distinguishes it from session_list, which the description also cross-references for id lookup.

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?

Explicitly says to use it after job_start or start_vm_restore to follow the operation rather than re-issuing it, naming the relevant sibling operations. It gives clear triggering context but no explicit exclusion of alternatives such as session_list.

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