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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, openWorldHint=false. The description adds valuable context: it changes no source file, never falls back to another Engine, and requires explicit confirmation. This goes beyond the annotations by clarifying the non-destructive nature of the source files and the confirmation requirement, which is critical for a destructive operation. The description does not contradict annotations; it complements them.

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 two sentences, front-loaded with the core action and purpose, then adds the critical safety and confirmation requirements. Every sentence earns its place: the first defines what it does, the second clarifies the non-destructive nature and the confirmation requirement. No wasted words.

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?

Given the tool's complexity (5 required params, destructive annotation, no output schema), the description covers the essential context: what it does, the confirmation requirement, and the non-destructive nature of source files. It doesn't explain the return value or what happens after attachment, but with no output schema, that's less critical. The description is complete enough for an agent to call it correctly, though it could mention the expected_revision parameter's role more explicitly, but the schema covers that.

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 100%, so the schema already documents all five parameters. The description adds context about the overall operation (e.g., 'exact opaque workspace', 'exact online 2ools Engine') but doesn't add per-parameter semantics beyond what the schema provides. The description mentions 'show the selected computer/workspace and obtain explicit confirmation' which relates to the confirm parameter, but the schema already explains that. Baseline 3 is appropriate.

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 clearly states the action (attach), the resource (one saved project), the target (one exact opaque workspace on one exact online 2ools Engine), and the purpose (grants future project work access to real source on that computer). It distinguishes itself from siblings like start_project_on_engine and get_project_engine_workspace by emphasizing the exactness and the attachment semantics.

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 provides clear context: it is owner-authorized, requires showing the selected computer/workspace and obtaining explicit confirmation, and it never falls back to another Engine. It doesn't explicitly name alternative tools for when not to use it, but the context of 'exact' and 'never falls back' implies a specific use case. The sibling list includes get_project_engine_workspace and start_project_on_engine, but the description doesn't explicitly contrast with them, so a 4 is appropriate.

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