cad_connect

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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds important behavioral context beyond them: it establishes a persistent scoping effect on subsequent MCP calls. This is exactly the kind of stateful behavior an agent needs to know before invoking the tool.

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 tight sentences with no filler; the core action is front-loaded and the rationale follows immediately. Every word earns its place.

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 one-parameter tool it conveys the core mechanism, but it omits how to discover the processId and how the binding might be changed or released. Since there is no output schema and no param descriptions, those details would make the definition fully self-sufficient.

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 compensate for the undocumented processId parameter. It only says 'one specific AutoCAD process' and never explains that processId is the target process identifier or where to obtain it, leaving a meaningful gap for correct invocation.

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 states a specific action and resource: 'Bind subsequent MCP calls to one specific AutoCAD process,' which is a clear and unique purpose. The second sentence adds a concrete rationale (avoiding the wrong drawing) that distinguishes it from generic command tools and process-listing siblings like cad_instances.

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 clearly identifies when to use the tool: 'when multiple instances are running' and routing to the wrong drawing is a risk. It does not name alternatives or explicitly say when not to use it, so it stops short of full routing guidance.

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