Skip to main content
Glama
zhongmingyuan

mcp-my-mac

by zhongmingyuan
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

mcp_call_mac_system_profiler

Retrieve detailed Mac system information for debugging and analysis. Access hardware specs, network settings, software details, and device connections to understand system configuration.

Instructions

Call the system_profiler with the given datatype. Allow LLM to deepdive into the
system information.
This function is used to get the system information to help user to understand the
system and potentially debug.

Allowed datatypes:
    - SPAirPortDataType - Airport/WiFi information
    - SPApplicationsDataType - Application information
    - SPAudioDataType - Audio device information
    - SPBluetoothDataType - Bluetooth information
    - SPCameraDataType - Camera information
    - SPDiagnosticsDataType - Diagnostic information
    - SPDisplaysDataType - Display and graphics information
    - SPFirewallDataType - Firewall settings
    - SPHardwareDataType - Hardware specifications
    - SPLocationDataType - Location services information
    - SPMemoryDataType - Memory information
    - SPNetworkDataType - Network settings and interfaces
    - SPNVMeDataType - NVMe storage details
    - SPPCIDataType - PCI devices information
    - SPPowerDataType - Battery and power information
    - SPSoftwareDataType - Software and OS information
    - SPStorageDataType - Storage devices and volumes
    - SPThunderboltDataType - Thunderbolt ports and connections
    - SPUSBDataType - USB devices and connections

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
datatypeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • src/mcp_server_my_mac/server.py:48-77 (handler)
    The handler function for the 'mcp_call_mac_system_profiler' tool, including the registration decorator. It receives the datatype parameter and delegates to the load_system_profiler helper function.
    @mcp.tool(name="mcp_call_mac_system_profiler")
async def mcp_call_mac_system_profiler(datatype: str) -> str:
    """
    Call the system_profiler with the given datatype. Allow LLM to deepdive into the
    system information.
    This function is used to get the system information to help user to understand the
    system and potentially debug.

    Allowed datatypes:
        - SPAirPortDataType - Airport/WiFi information
        - SPApplicationsDataType - Application information
        - SPAudioDataType - Audio device information
        - SPBluetoothDataType - Bluetooth information
        - SPCameraDataType - Camera information
        - SPDiagnosticsDataType - Diagnostic information
        - SPDisplaysDataType - Display and graphics information
        - SPFirewallDataType - Firewall settings
        - SPHardwareDataType - Hardware specifications
        - SPLocationDataType - Location services information
        - SPMemoryDataType - Memory information
        - SPNetworkDataType - Network settings and interfaces
        - SPNVMeDataType - NVMe storage details
        - SPPCIDataType - PCI devices information
        - SPPowerDataType - Battery and power information
        - SPSoftwareDataType - Software and OS information
        - SPStorageDataType - Storage devices and volumes
        - SPThunderboltDataType - Thunderbolt ports and connections
        - SPUSBDataType - USB devices and connections
    """
    return load_system_profiler(datatype)
  • src/mcp_server_my_mac/readers/load_system_profiler.py:31-37 (helper)
    Core helper function that validates the input datatype and executes the macOS 'system_profiler' command using os.popen to retrieve system information.
    def load_system_profiler(datatype: str):
    if datatype not in ALLOWED_DATATYPES:
        raise ValueError(
            f"Invalid datatype: {datatype}. Allowed datatypes are: {ALLOWED_DATATYPES}"
        )
    return os.popen(f"system_profiler {datatype}").read()
  • src/mcp_server_my_mac/readers/load_system_profiler.py:6-28 (schema)
    Schema definition: Set of allowed datatypes for the system_profiler tool, used to validate input and restrict access to specific system information categories.
    ALLOWED_DATATYPES = set(
    [
        "SPAirPortDataType",
        "SPApplicationsDataType",
        "SPAudioDataType",
        "SPBluetoothDataType",
        "SPCameraDataType",
        "SPDiagnosticsDataType",
        "SPDisplaysDataType",  # Display information (resolution, graphics)
        "SPFirewallDataType",
        "SPHardwareDataType",
        "SPLocationDataType",
        "SPMemoryDataType",
        "SPNetworkDataType",
        "SPNVMeDataType",  # NVMe storage details
        "SPPCIDataType",  # PCI devices information
        "SPPowerDataType",  # Battery and power information
        "SPSoftwareDataType",
        "SPStorageDataType",
        "SPThunderboltDataType",  # Thunderbolt connections
        "SPUSBDataType",  # USB devices
    ]
)

Tool Definition Quality

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the tool's function and lists datatypes, but doesn't disclose behavioral traits like whether it's read-only, requires permissions, has rate limits, or what the output format is (though an output schema exists). The description adds some context but misses key operational details for a tool with no annotations.

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

Conciseness4/5

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

The description is appropriately sized and front-loaded with the core purpose in the first two sentences, followed by a useful list of datatypes. Every sentence adds value, though the list is lengthy but necessary for clarity. It could be slightly more structured but remains efficient overall.

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?

Given one parameter, no annotations, and an output schema (which reduces the need to describe return values), the description is fairly complete. It explains the purpose, usage context, and details all parameter options. However, it lacks behavioral transparency details (e.g., safety, permissions), which holds it back from a perfect score despite the output schema.

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

Parameters5/5

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

The input schema has 0% description coverage and only one parameter ('datatype') with no enum. The description compensates fully by listing all allowed datatypes with brief explanations (e.g., 'SPAirPortDataType - Airport/WiFi information'), adding significant meaning beyond the bare schema. This is excellent compensation for low schema coverage.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Call the system_profiler with the given datatype' and 'get the system information to help user to understand the system and potentially debug.' It specifies the verb ('call'), resource ('system_profiler'), and context ('system information'), though it doesn't explicitly differentiate from sibling tools like mcp_call_conda_info or mcp_call_gpu_available, which prevents a perfect score.

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?

The description implies usage context ('to help user to understand the system and potentially debug') and lists allowed datatypes, which suggests when to use it for specific information types. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., sibling tools) or any exclusions, making it moderately helpful but not comprehensive.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhongmingyuan/mcp-my-mac'

If you have feedback or need assistance with the MCP directory API, please join our Discord server