Skip to main content
Glama
markswendsen-code

mcp-apple

by markswendsen-code
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

mcp-apple

An MCP (Model Context Protocol) connector for Apple services. This server exposes tools for querying the iTunes Search API and checking Apple system service status.

Tools

check_app_store_info

Look up app information from the Apple App Store using the iTunes Search API.

Parameters:

  • app_name (string, required): Name of the app to search for.

  • country (string, optional, default: "us"): Two-letter country code (e.g., "us", "gb", "jp").

Example:

{
  "app_name": "Xcode",
  "country": "us"
}

search_music

Search for music tracks on Apple Music / iTunes using the iTunes Search API.

Parameters:

  • query (string, required): Search query (artist, track name, album, etc.).

  • limit (number, optional, default: 10): Number of results to return (max 200).

Example:

{
  "query": "Taylor Swift Shake It Off",
  "limit": 5
}

check_service_status

Check the operational status of Apple services (iCloud, App Store, Apple Music, etc.) using Apple's official System Status page.

Parameters:

  • service (string, optional): Filter by a specific service name (case-insensitive substring match). If omitted, returns the status of all Apple services.

Example:

{
  "service": "iCloud"
}

Related MCP server: App Store Connect MCP Server

Installation

From npm (when published)

npm install -g @striderlabs/mcp-apple

From source

git clone <repo-url>
cd mcp-apple
npm install
npm run build

Usage

Running the server directly

node dist/index.js

Or if installed globally:

mcp-apple

Configuring with Claude Desktop

Add the following to your Claude Desktop configuration file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "apple": {
      "command": "mcp-apple"
    }
  }
}

Or if running from the built source:

{
  "mcpServers": {
    "apple": {
      "command": "node",
      "args": ["/path/to/mcp-apple/dist/index.js"]
    }
  }
}

Configuring with other MCP clients

The server communicates over stdio using the MCP protocol. Point your MCP client to the dist/index.js file or the mcp-apple binary.

Development

# Install dependencies
npm install

# Build
npm run build

# Pack for distribution
npm pack

APIs Used

  • iTunes Search API: https://itunes.apple.com/search — Public Apple API, no authentication required.

  • Apple System Status: https://www.apple.com/support/systemstatus/data/system_status_en_US.js — Public Apple status endpoint, no authentication required.

License

MIT

Available Tools

3 tools
check_app_store_infoC

Look up app information from the Apple App Store

ParametersJSON Schema
NameRequiredDescriptionDefault
app_nameYesName of the app to search for
countryNoCountry code (default: us)us

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic lookup action. It doesn't mention critical traits like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what the output might contain (e.g., app details, ratings). This leaves significant gaps in understanding the tool's behavior.

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?

The description is a single, clear sentence with zero wasted words, making it highly efficient and front-loaded. It directly communicates the core purpose without unnecessary elaboration.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete for a tool with two parameters and no structured behavioral hints. It fails to address what information is returned, how errors are handled, or any operational constraints, leaving the agent under-informed about the tool's full context.

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?

The schema description coverage is 100%, with both parameters ('app_name' and 'country') well-documented in the schema itself. The description adds no additional meaning or context beyond what the schema provides, such as format examples or usage tips, so it meets the baseline for high 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 action ('Look up') and resource ('app information from the Apple App Store'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_music', which might also involve lookup operations, preventing 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 Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'check_service_status' or 'search_music'. It lacks context about specific use cases, prerequisites, or exclusions, leaving the agent with minimal direction.

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

check_service_statusC

Check the status of Apple services

ParametersJSON Schema
NameRequiredDescriptionDefault
serviceNoSpecific service name to check (optional, returns all if not specified)

TDQS

C2.9/5.0
Behavior2/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 states what the tool does but doesn't disclose behavioral traits such as whether it's read-only, requires authentication, has rate limits, or what the output format might be. This is a significant gap for a tool with no structured safety hints.

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?

The description is a single, clear sentence with no wasted words. It's appropriately sized and front-loaded, efficiently conveying the core purpose without unnecessary elaboration.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'status' entails (e.g., uptime, health metrics), potential return values, or any behavioral context, making it inadequate for a tool that might involve external service checks.

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?

The input schema has 100% description coverage, with the parameter 'service' documented as optional and returning all services if not specified. The description adds no additional meaning beyond this, so it meets the baseline for high schema coverage without compensating further.

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 verb ('Check') and resource ('status of Apple services'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'check_app_store_info' or 'search_music', which might also involve Apple services, so it lacks sibling distinction.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.

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

search_musicC

Search for music on Apple Music/iTunes

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query for music
limitNoNumber of results (default: 10)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a search operation, implying read-only behavior, but doesn't disclose any traits like authentication requirements, rate limits, response format, or error handling. For a tool with no annotation coverage, this is a significant gap in transparency.

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?

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration or redundancy.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete for a search tool. It doesn't explain what the search returns (e.g., tracks, albums, artists), how results are structured, or any behavioral aspects like pagination or error cases. With 2 parameters and no structured output information, more context is needed.

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?

The description doesn't add any parameter-specific information beyond what's already in the schema, which has 100% coverage with clear descriptions for 'query' and 'limit'. The baseline score of 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with additional context like query syntax examples or result ordering.

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 action ('Search for music') and target platform ('on Apple Music/iTunes'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'check_app_store_info' or 'check_service_status', which appear to be unrelated to music searching, so it doesn't fully distinguish from alternatives.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, constraints, or scenarios where this tool is preferred over other search methods or sibling tools, leaving usage context entirely implicit.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedcheck_app_store_info
    • First observedcheck_service_status
    • First observedsearch_music
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: checking app store info, checking service status, and searching music. There is no overlap in functionality, making it easy for an agent to select the correct tool without confusion.

Naming Consistency4/5

The tools follow a consistent verb_noun pattern (check_app_store_info, check_service_status, search_music), with minor deviation in 'search_music' using 'search' instead of 'check'. This maintains readability and predictability across the set.

Tool Count3/5

With only 3 tools, the server feels thin for a domain like Apple services, which could include more operations such as checking device status, managing subscriptions, or accessing other media. However, it covers basic functions without being overly complex.

Completeness3/5

The tools cover distinct areas (App Store, service status, music search), but there are notable gaps for a comprehensive Apple services interface, such as no update, delete, or creation operations, and missing coverage for other Apple domains like iCloud or device management.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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/markswendsen-code/mcp-apple'

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