Clarify debug_attach_sim argument combinations for PID attach

[dpearson2699]

Summary

When using the debug_attach_sim MCP tool from Claude Code, the tool schema made it look like bundleId, pid, and waitFor could be supplied together. In practice, those fields are mutually constrained, and invalid combinations fail only after the tool call is made.

What happened

I was debugging a live iOS Simulator app and wanted to attach LLDB to an already-running process while preserving simulator/app state.

The schema exposed these fields:

• bundleId: string
• pid: integer
• waitFor: boolean
• continueOnAttach: boolean
• makeCurrent: boolean

Because bundleId and pid both appeared required/available, I initially supplied both. That failed. I then tried PID attach with waitFor: true, which also failed with an invalid option combination. The working form was effectively PID-only attach with an empty bundle id and no wait:

{
  "bundleId": "",
  "pid": 12345,
  "waitFor": false,
  "continueOnAttach": true,
  "makeCurrent": true
}

Why this is confusing

For an MCP client/agent, the schema communicates what fields are required and valid. If a field appears required even though it is only required for one mode, the agent tends to provide it. That can push the model into invalid combinations such as:

• bundleId + pid
• pid + waitFor: true

The correct usage is discoverable only by failing calls, which is especially painful during debugging because failed attach attempts interrupt the LLDB workflow.

Suggested improvements

Could the debug_attach_sim schema and/or tool error messages make the attach modes explicit?

For example:

1. Model the inputs as one of two attach modes:
   • attach by bundle id: bundleId required, pid omitted, waitFor allowed
   • attach by PID: pid required, bundleId omitted, waitFor false/omitted
2. Make bundleId optional when pid is provided, rather than requiring callers to pass "".
3. Return an error message that says exactly which combinations are valid, e.g.:
   • Provide either bundleId or pid, not both.
   • waitFor is only valid when attaching by bundleId.
4. Add a short example for attaching to an already-running simulator app by PID.

Environment/context

• Tool: XcodeBuildMCP via Claude Code MCP tools
• Workflow: simulator debugging / LLDB attach
• Goal: attach to an existing running app process without rebooting, reinstalling, or losing app state

Thanks for maintaining this tool. Once attached, debug_lldb_command worked well for raw LLDB commands like process status, bt, frame variable, and po.