Connect an MCP process to a specific Plasticity window and retrieve a compact initial scene summary, with paginated body bounds and counts for CAD inspection.
Connect this MCP process to one explicit Plasticity window and return its compact initial scene summary. Body bounds/counts are paginated; use plasticity_body_info for exact topology of a selected body.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes |
Changes observed during successful MCP inspections.
v0.2.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=false, so the safety profile is partly covered. The description adds that the initial scene summary is compact and that body bounds/counts are paginated, but never explains what 'connect' does to any existing connection/lifecycle state — which the destructive hint implies matters.
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, front-loaded with the primary action and its result, then the sibling routing. Nothing wasted.
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?
No output schema exists, and the description does supply a return summary and a pagination caveat. But for a connection-establishing tool with a required, undocumented parameter, it omits the target identifier format and any connection lifecycle/replacement behavior.
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 description coverage is 0% for the single required targetId. The phrase 'one explicit Plasticity window' implies targetId identifies a window, which is some added meaning, but the accepted format (id vs name) and the 'one window at a time' constraint are left unstated.
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?
Specific verb+resource: connecting the MCP process to one explicit Plasticity window, plus the return value (compact initial scene summary). This clearly distinguishes it from siblings like plasticity_list_windows, plasticity_status, or plasticity_call.
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 routes the agent to plasticity_body_info when exact body topology is needed, and warns that body bounds/counts are paginated. It does not, however, say when to prefer connect over plasticity_list_windows or plasticity_status, so the alternative routing is only partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.