open_mac_desktopReturns a link to the Mac's full desktop in the human's browser, with mouse and keyboard, for seeing or clicking something on it (Xcode, the Simulator, a sign-in window). They sign in to nomac.app to open it; it disconnects after 15 minutes without input. Works on a ready Mac. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Mac session ID (ses_…). Optional: without it, the account's running Mac. |
Changes observed during successful MCP inspections.
Input schema / properties / session_id / descriptionPrevious value: -"Mac session ID (ses_…) returned by start_mac or list_mac_sessions."New value: +"Mac session ID (ses_…). Optional: without it, the account's running Mac."Input schema / requiredRemoved value: -[
- "session_id"
-]Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": {},
- "description": "The JSON response of the NoMac API for this operation",
- "properties": {
- "error": {
- "additionalProperties": {},
- "description": "Present only when the call failed",
- "properties": {
- "code": {
- "description": "Stable machine-readable error code, for example insufficient_credit",
- "type": "string"
- },
- "message": {
- "description": "What went wrong and what to do next",
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- }
- },
- "type": "object"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that a human signs in at nomac.app, that the link is browser-based with mouse and keyboard, and that the session disconnects after 15 minutes without input. This adds useful behavioral context on auth flow and timeout. It does not cover all possible operational details, but with annotations already declaring read-only safety, the additional disclosure is substantive.
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 compact and front-loaded: it leads with what is returned and why, then adds sign-in, timeout, readiness, and safety details in a tight sequence. There is no wasted text.
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 single-parameter tool with full schema coverage and no output schema, the description covers what the tool returns, who interacts with it, the timeout behavior, and the readiness prerequisite. An agent has enough to call it appropriately without needing more.
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?
There is only one optional parameter, and the schema already documents session_id with 100% coverage. The description does not add format or semantic detail beyond what the schema provides, so the 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 gives a specific verb and resource: it returns a browser link to the Mac desktop with mouse and keyboard. It clearly frames the tool as human-interactive rather than agent-executed, which helps distinguish it from siblings like exec_mac and screenshot_mac, though it does not explicitly name an alternative.
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?
It states the intended use case clearly: seeing or clicking things like Xcode, the Simulator, or a sign-in window. It also notes the prerequisite that the Mac must be ready. It stops short of naming when-not-to-use cases or explicit alternatives, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.