get_status

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds one genuinely new behavioral fact — that it does not start SOLIDWORKS — plus a hint that it returns both connection state and the 'current target'. However, 'exact current target' is left undefined (document? component? selection?), so the disclosure is partial.

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?

A single front-loaded sentence with no filler, stating the action, the subject, and the key constraint in one pass. Nothing could be removed without losing information.

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 zero-parameter, read-only status tool, the definition covers what is inspected and the no-launch constraint. Since no output schema exists, a sentence describing the shape of the returned status (connected/disconnected, active document name) would have closed the remaining gap.

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 tool takes zero parameters, so there is no parameter semantics to add; the baseline of 4 applies. The description correctly implies a parameter-free snapshot call, consistent with the empty schema and additionalProperties: false.

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 ('inspect') and a specific resource ('the running CAD connection and exact current target'), which clearly separates it from the long list of geometry-creation siblings. It does not, however, differentiate itself from near-neighbors like pro_connection_doctor, pro_capabilities, or pro_visualize_status, which an agent could plausibly confuse it with.

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 phrase 'without launching SOLIDWORKS' implies a useful usage condition: this is a lightweight probe for when the app may or may not be running. But there is no explicit when-not guidance and no named alternative (e.g., use pro_connection_doctor for deeper diagnostics, list_documents for the document list), so the agent must infer routing.

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