Skip to main content
Glama

NoMac

by app.nomac
OverviewDiscussionsAdmin

Read a file on a Mac

read_mac_file
Read-only

Reads a file on the Mac, up to max_bytes (default 1 MiB, max 3 MiB): text as text, PNG, JPEG, GIF and WebP whole as an image, other files as base64; a larger binary file comes back as its size and details only. Relative paths are in the workspace. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesFile to read. Relative paths are in the session workspace; ~ is the home folder.
max_bytesNoRead at most this many bytes (default 1 MiB, max 3 MiB).
session_idNoMac session ID (ses_…). Optional: without it, the account's running Mac.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / session_id / description
      Previous 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."
    • changedInput schema / required
      Previous value: -[
-  "session_id",
-  "path"
-]New value: +[
+  "path"
+]
  2. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedOutput 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: +null
  3. Changed2 schema fields changed
    • changedInput schema / properties / max_bytes / description
      Previous value: -"Read at most this many bytes (default 1 MiB, max 4 MiB)."New value: +"Read at most this many bytes (default 1 MiB, max 3 MiB)."
    • changedInput schema / properties / max_bytes / maximum
      Previous value: -4194304New value: +3145728
  4. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's trailing 'Read-only' is confirmatory rather than additive. It does add real behavioral context beyond annotations: format-dependent return shapes (text vs image vs base64), the truncation-to-metadata fallback for oversized binaries, and the default/max byte caps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with the return modes front-loaded after the core action. Every clause carries information (size caps, format branches, path resolution, safety), and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since there is no output schema, the description must explain return values and it does thoroughly via the format branches. It omits error behavior (missing file, permission denial) and whether truncation is signalled, which are minor gaps for a read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and every parameter is documented in the schema, including the same default/max byte values and path-resolution note the description repeats. Baseline 3 is appropriate since the description adds essentially nothing new for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (reads a file on the Mac) and disambiguates from the sibling write_mac_file by scope and read-only nature. An agent can distinguish it from get_mac_file_link and screenshot_mac from the stated behavior alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the tool name and the described return modes, but there is no explicit when/when-not guidance or pointer to siblings (e.g., use get_mac_file_link for large binaries, or screenshot_mac for screen content). The agent must infer the alternative.

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

All NoMac toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources