mcp-server-macos

Overview Schema Source Related Servers Discussions Admin

Get system information

get_system_info

Read-only

Retrieve macOS version, build, model, processor, memory, computer name, and uptime to inspect or report a Mac's system details.

Instructions

Get information about this Mac: the macOS version and build, the model, the processor, the installed memory, the computer's name and how long it has been running.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_system_info"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`model`	Yes	The Mac's marketing name, e.g. 'MacBook Pro'.
`processor`	Yes	The processor's name, e.g. 'Apple M2 Pro'.
`macos_build`	Yes	The macOS build number, e.g. '24G90'.
`memory_bytes`	Yes	The installed memory (RAM), in bytes.
`computer_name`	Yes	The computer's name, as shown in System Settings and on the network.
`macos_version`	Yes	The macOS version, e.g. '15.6.1'.
`uptime_seconds`	Yes	Seconds since the Mac last started, sleep time included.
`model_identifier`	Yes	The Mac's model identifier, e.g. 'Mac14,9'.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds real value by scoping the operation to 'this Mac' and listing the concrete data collected, which tells the agent the information is local and host-specific. It does not discuss cost, caching, or freshness, but for a trivial local read that is a small omission.

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 sentence, front-loaded with the verb and resource, then a compact field list. Every clause names a distinct returned value; there is no filler, hedging, or repetition.

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

Completeness5/5

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

An output schema exists, so return values need not be spelled out, yet the description still summarizes them, which is more than sufficient. Combined with annotations covering safety and a zero-parameter schema, nothing an agent needs in order to call this correctly is missing.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a no-arg tool applies. The enumerated field list is arguably parameter-equivalent context and is fully aligned with the empty schema.

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?

The description gives a specific verb (get) and resource (system information) and then enumerates the exact fields returned: macOS version and build, model, processor, memory, computer name, uptime. An agent knows precisely what this tool yields without opening the schema, and it is clearly distinct from a notification-sending sibling.

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 only implied: the enumeration of hardware/OS facts makes it obvious you call this when you need machine context, but there is no explicit when-to-use statement, no prerequisites, and no named alternative. For a zero-parameter read-only tool the gap is minor, but the guidance is inferred rather than stated.

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

Deploy Server