Skip to main content
Glama
Medard-prog

ios-emoji-mcp

by Medard-prog
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript

📱 iOS Emoji MCP Server

npm version npm downloads

A Model Context Protocol (MCP) server that provides access to iOS emoji images with URLs for both 160x160px and 320x320px versions.

📦 npm: https://www.npmjs.com/package/ios-emoji-mcp

🚀 Quick Start with npx

You can run this MCP server without installation using npx:

{
  "mcpServers": {
    "ios-emoji-mcp": {
      "command": "npx",
      "args": ["-y", "ios-emoji-mcp@latest"]
    }
  }
}

Or on Windows:

{
  "mcpServers": {
    "ios-emoji-mcp": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "ios-emoji-mcp@latest"]
    }
  }
}

Related MCP server: mcp-server-icon

📦 Installation Options

Global Installation

npm install -g ios-emoji-mcp

Local Development

git clone https://github.com/Medard-prog/ios-emoji-mcp.git
cd ios-emoji-mcp
npm install
npm start

⚙️ Configuration

Add to your Claude Desktop config (claude_desktop_config.json):

Using npx (Recommended)

{
  "mcpServers": {
    "ios-emoji-mcp": {
      "command": "npx",
      "args": ["-y", "ios-emoji-mcp@latest"]
    }
  }
}

Using global installation

{
  "mcpServers": {
    "ios-emoji-mcp": {
      "command": "ios-emoji-mcp"
    }
  }
}

Using local development

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

🛠️ Available Tools

1. get_emojis

Lists all available iOS emoji names.

⚠️ Note: Full list contains 1,559 emojis (~5,550 tokens)

Parameters: None

Example:

Available iOS emojis (1559 total):
100, 1234, 8ball, a, ab, abc, abcd, accept...

2. search_emojis

Search for emojis using fuzzy matching.

Parameters:

  • query (required): Search term to find matching emojis

  • limit (optional): Maximum results to return (default: 10)

Examples:

  • Search for "ball": Returns 8ball

  • Search for "a": Returns a, ab, 8ball (fuzzy matched)

3. get_url

Get the direct URL for a specific emoji with size options.

Parameters:

  • emoji (required): Emoji name (e.g., "100", "a", "8ball")

  • size (optional): "160" or "320" for pixel dimensions (default: "160")

Example Response:

Emoji: 8ball
Size: 160x160px
URL: https://cgi78hjdnd.ufs.sh/f/DJLnTzoE7sxZfDL7m68uRskvbxZ7Pm6WuCnrOjaoStGEylcI

🎯 Use Cases

  • Web Development: Get direct URLs for iOS emojis in your applications

  • Content Creation: Access high-quality emoji images for designs

  • Documentation: Include iOS-style emojis in documentation

  • Chat Applications: Implement iOS emoji support

📊 Features

  • ✅ Fuzzy Search: Find emojis even with partial or approximate names

  • ✅ Multiple Sizes: 160x160px and 320x320px versions available

  • ✅ Direct URLs: Get direct links to emoji images

  • ✅ Fast Access: No API keys or authentication required

  • ✅ Comprehensive: Includes all major iOS emoji variants

🔧 Technical Details

  • Built with the Model Context Protocol (MCP) SDK

  • Uses JSON data file for emoji mappings

  • Implements fuzzy search algorithm for flexible emoji discovery

  • Supports both CommonJS and ESM environments

  • Zero external dependencies beyond MCP SDK

📝 Example Workflow

  1. Discover emojis: Use get_emojis to see all available options

  2. Search: Use search_emojis with a query like "ball" or "letter"

  3. Get URL: Use get_url with the exact emoji name and preferred size

  4. Use: Copy the URL and use it in your application or content

🤝 Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if applicable

  5. Submit a pull request

⚖️ Legal & Copyright

Important: This MCP server provides access to iOS emoji images that are the intellectual property of Apple Inc.

  • Emoji Copyright: All emoji images are © Apple Inc. and are subject to Apple's terms of use

  • Apple Trademarks: iOS and iPhone are trademarks of Apple Inc., registered in the U.S. and other countries

  • Usage Rights: This tool provides access to emoji URLs for educational, research, and development purposes

  • Commercial Use: For commercial applications, please ensure compliance with Apple's licensing terms

  • No Affiliation: This project is not affiliated with, endorsed by, or sponsored by Apple Inc.

Disclaimer: The authors of this MCP server do not claim ownership of the emoji images or related intellectual property. Users are responsible for ensuring their use complies with applicable copyright laws and Apple's terms of service.

📄 License

MIT License - applies to the MCP server code only, not the emoji content.

Note: The MIT license covers this MCP server's code and functionality. The emoji images themselves remain under Apple's copyright and are subject to their respective terms of use.

🐛 Issues

Found a bug or have a feature request? Please open an issue on GitHub.

Made with ❤️ for the MCP community

Apple Legal Notice: Apple, iOS, iPhone, and related emoji designs are trademarks and/or copyrights of Apple Inc. This project is an independent tool and is not affiliated with Apple Inc.

Available Tools

3 tools
get_emojisA

Get a list of all available iOS emoji names

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/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 discloses that the tool retrieves a list of emoji names, but does not mention any behavioral traits like return format, pagination, or performance characteristics. For a simple read operation, this is adequate but minimal.

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 front-loading the purpose. There is no extraneous information; every word is necessary.

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

Completeness3/5

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

Given the tool's simplicity (no parameters, no output schema), the description is somewhat complete but lacks detail about the output format (e.g., whether it returns just names or includes identifiers). A more complete description would specify the structure of the returned list.

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 has no parameters, and the schema coverage is 100%. The description adds meaning by clarifying that the result is a list of available iOS emoji names, which adds value beyond 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 explicitly states the action ('Get'), the resource ('list of all available iOS emoji names'), and clearly distinguishes from siblings like search_emojis which suggests search functionality. It is a specific verb+resource with no ambiguity.

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 does not provide explicit guidance on when to use this tool versus alternatives such as search_emojis or get_url. The context implies that get_emojis returns all emoji names while search_emojis might filter, but this is not stated directly.

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

get_urlB

Get the URL for a specific emoji with optional size

ParametersJSON Schema
NameRequiredDescriptionDefault
sizeNoSize version: '160' for 160x160px or '320' for 320x320px (default: '160')160
emojiYesThe emoji name (e.g., '100', 'a', '8ball')

TDQS

B3.1/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 does not disclose any behavioral traits such as read-only nature, error handling for missing emojis, or any side effects. The brief description is insufficient for an agent to understand 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.

Conciseness4/5

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

The description is a single concise sentence with no unnecessary words. It is front-loaded with the tool's purpose. However, it could be slightly expanded to include usage notes without losing conciseness.

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 simplicity (2 params, no output schema, no annotations), the description should cover return format, error behavior, or prerequisites. It does not, leaving significant gaps for the agent.

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 description coverage is 100% (both parameters have descriptions in the schema). The description adds 'with optional size' but does not provide additional meaning beyond what the schema already conveys. Baseline 3 is appropriate.

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 clearly states the verb 'Get' and resource 'URL for a specific emoji', distinguishing it from sibling tools 'get_emojis' (list all emojis) and 'search_emojis' (search for emojis). It specifies the optional size parameter.

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. Sibling tools are listed in context but not mentioned in the description, leaving the agent without decision criteria.

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

search_emojisA

Search for emojis by name with fuzzy matching

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return (default: 10)
queryYesSearch query to find matching emoji names

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It mentions 'fuzzy matching' which is useful, but does not explain return format, pagination, or what happens with no results. Adequate but not comprehensive.

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?

A single sentence that front-loads the purpose. However, it could be slightly expanded to include usage notes without losing conciseness. Currently efficient but missing some valuable context.

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

Completeness3/5

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

Given the tool's simplicity (2 params, no output schema), the description is mostly adequate but lacks usage guidelines and behavioral details like result limits or matching behavior. It meets minimum viability but has gaps.

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?

Schema coverage is 100% (both parameters described), baseline 3. The description adds 'fuzzy matching' which enhances the query parameter's meaning, and limit is clear from schema. This extra context justifies a 4.

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 clearly states the tool searches for emojis by name using fuzzy matching, which is a specific verb and resource. It differentiates from siblings: get_emojis likely lists all emojis, and get_url retrieves a URL.

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?

No guidance on when to use this tool versus alternatives (get_emojis, get_url). The agent is left to infer context; ideally, the description would explicitly state when search is preferred over listing all emojis.

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.

  1. 3 tool updatesv1.0.1
    • First observedget_emojis
    • First observedget_url
    • First observedsearch_emojis
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: listing all emojis, searching by name, and getting a URL. No overlaps.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (get_emojis, search_emojis, get_url).

Tool Count5/5

Three tools is appropriate for a focused emoji server; each tool contributes without being overwhelming or insufficient.

Completeness4/5

Covers listing, searching, and URL retrieval. Missing a direct get_emoji by exact name, but search with fuzzy matching likely compensates.

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