imessage-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct aspect of messaging: listing conversations, reading messages, searching, sending, viewing participants, and handling attachments. No two tools have overlapping purposes, making selection unambiguous.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern (e.g., get_conversations, send_message, search_messages), making the API predictable and easy to navigate.
Tool Count5/5
With 7 tools, the server is well-scoped for an iMessage interface, covering the core workflows without unnecessary bloat or insufficient functionality.
Completeness5/5
The tool set covers the essential lifecycle of messaging: listing, reading, searching, sending, and managing attachments. No critical operations are missing for the stated purpose.
Average 3.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It covers recipient resolution and attachment support, but omits important details such as message irreversibility, delivery failures, or permission requirements. This is a significant gap for a send operation.
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?
Two concise sentences, front-loaded with the primary action and no filler. Every sentence contributes meaningful information.
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?
The input side is well covered, but the tool has no output schema and the description does not explain return values or error behavior. For a send tool, knowing what the response contains (e.g., success status, message ID) is important, leaving a moderate gap.
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 already describes all three parameters at 100% coverage. The description adds minimal value by rephrasing the recipient types and mentioning file attachments, which the schema already documents. 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 identifies the action ('Send a message') and the resource (contact or group chat), and specifies the message channels (iMessage, SMS, RCS). This clearly distinguishes it from the read-oriented sibling tools like get_messages and search_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to send messages or file attachments to contacts/groups. It does not explicitly mention alternatives or exclusions, but the sibling tools are all retrieval operations, making the send functionality self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 notes the default destination (~/Desktop) but fails to disclose potential side effects like overwriting existing files, directory creation, or required permissions. This is a significant gap for a file-saving operation.
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 sentence that immediately conveys the action and key default. It contains no redundant words and is front-loaded with the core purpose.
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?
For a simple tool with two parameters and no nested objects, the description provides enough context: it states the purpose, the default destination, and the prerequisite tool. It does not explain return values, but the absence of an output schema makes this less critical. It could mention what happens on success/failure, but overall it is sufficiently complete for the tool's simplicity.
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 already covers both parameters with 100% description coverage, including the source_path origin and destination default. The description adds little beyond restating these facts ('defaults to Desktop' and 'from get_attachments results'), so it meets the baseline without enhancing meaning.
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 uses a specific verb ('Save/copy') and clearly identifies the resource ('a message attachment') and destination. It distinguishes from sibling tools like get_attachments, which retrieves rather than saves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Use after get_attachments to save files,' which gives sequencing. However, it does not explicitly mention when not to use or name alternative tools beyond the prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 useful return context (resolved contact names and attachment info), but lacks details on result ordering, scope limitations, or whether attachment content is searchable. It covers basics without being thorough.
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, front-loaded sentence with no wasted words. It efficiently conveys the purpose and key output details.
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 the tool's simplicity (2 parameters, no output schema), the description covers the essential purpose and highlights return fields. It lacks details on pagination or ordering, but for a search tool this is largely sufficient.
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% with descriptions for both query and limit. The description adds minimal extra meaning ('keyword or phrase' vs 'Text to search for'), so the baseline of 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 action ('Search') and the resource ('all messages') with a specific scope ('keyword or phrase'). It distinguishes itself from sibling tools like get_messages (which lists messages) and get_attachments (which retrieves attachments) by emphasizing cross-message search.
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 ('Search all messages') but does not explicitly state when to prefer this tool over alternatives like get_messages or get_attachments. No when-not-to-use information or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It indicates a read-only operation ('Get') and mentions a specific behavior (resolving contact names), but it does not disclose error behavior, authentication needs, or return format details. It adds some value beyond the tool name, but leaves ambiguity.
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 two short sentences with no redundant words. Every phrase earns its place: it states what the tool does, the output enrichment, and a typical use case. Highly scannable and efficient.
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?
The schema shows all three parameters as optional, but the description does not clarify that at least one identifier is needed to select a chat. Since there is no output schema, the description should hint at the return structure; it says 'resolved contact names' but not whether it returns an array, an object, or how empty results are handled. The description is adequate for a simple getter but leaves this operational gap.
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 already includes descriptions for all three parameters (100% coverage), so the description does not need to repeat them. The schema provides clear meanings for 'name', 'chat_id', and 'chat_guid' (with example), so the description adds no extra parameter-level detail. 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 a specific verb ('Get') and resource ('participants of a chat'), and the added detail 'with resolved contact names' clarifies the output. It also explicitly mentions 'useful for group chats,' distinguishing it from sibling tools about conversations, messages, and attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context with 'Useful for group chats,' indicating when this tool is appropriate. However, it does not explicitly name alternatives or exclude other scenarios, but the provided context is sufficient for basic selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that conversations include resolved contact names and group participant counts, which adds useful output behavior. However, it does not mention scope (e.g., current user), ordering, or any rate limits, leaving some behavioral uncertainty.
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?
Two short sentences, front-loaded with the main action. Every word adds value, no redundancy.
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?
For a simple list tool with one optional parameter and no output schema, the description covers the key features (individual/group, contact names, participant counts). However, it omits details like ordering or scope, so it's not fully complete.
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 single parameter 'limit' is fully documented in the schema with a default of 20. The description does not add additional meaning, which is appropriate given the 100% schema coverage.
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 uses a specific verb ('List') and resource ('conversations'), and distinguishes from siblings by noting individual/group chats, resolved contact names, and participant counts. This clearly sets it apart from get_messages and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for displaying recent conversations, but it does not explicitly mention when to prefer it over siblings like get_messages or search_messages. There are no exclusions or alternative recommendations, so it provides clear context without explicit selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It reveals that the tool returns file paths that can be read or saved, and that filtering by mime type is supported. This adds meaningful context beyond a bare 'get attachments' statement, though it does not detail pagination, error conditions, or the relationship between contact and chat_guid.
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 three concise sentences, each adding value: the primary action, the filtering capability, and the return format. There is no redundant or filler content.
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?
For a tool with 4 parameters, no output schema, and no annotations, the description provides a solid overview of purpose, filtering, and return type. It could be improved by explaining how to specify a conversation (contact vs chat_guid) and mentioning the default limit, but overall it is sufficient for an agent to understand the tool's capabilities.
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%, so the parameter descriptions already explain each field. The tool description adds little beyond repeating the mime_filter example and mentions return behavior (file paths). It does not explain the distinction between contact and chat_guid or the default limit, but the schema covers these adequately.
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 it retrieves attachments (images, files, links) from a conversation, distinguishing it from sibling tools like get_messages and get_conversations. It uses a specific verb and resource (get attachments from a conversation) and gives concrete examples of attachment types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving attachments and provides filter examples, but it does not explicitly mention when not to use it or name alternatives like get_messages for text content. The context is clear enough for an agent to select this tool when attachments are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds valuable behavioral details: 'Shows resolved sender names in group chats' and 'includes attachment info', disclosing output nuances beyond a simple read. It does not cover pagination, error handling, or auth, but for a read-only tool this is a reasonable disclosure.
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 two concise sentences, front-loaded with the core action immediately. Every sentence earns its place, adding search identifiers and output features without redundancy.
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?
For a simple read tool with two parameters and no output schema, the description provides sufficient context: identifiers, resolved sender names, and attachment info. It lacks explicit pagination/limit discussion, but the schema covers that, and the tool is straightforward.
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%, and the description essentially repeats the schema's contact description ('Contact name, phone number, email, or group chat name' appears in both). The limit parameter is not elaborated in the description, so it adds no new meaning beyond the schema baseline.
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 'Read messages from a conversation' with a specific verb and resource, and it distinguishes itself from siblings like search_messages (which searches across conversations) and get_conversations (which lists conversations). It also specifies search identifiers (contact name, phone number, email, or group name), making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading messages from a specific conversation identified by contact/group, but it does not explicitly exclude alternatives like search_messages or get_attachments. There is clear context for when to use this tool, but no explicit when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![imessage-mcp MCP server](https://glama.ai/mcp/servers/kamrenkennedy/imessage-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kamrenkennedy/imessage-mcp)

Score Badge

Copy to your README.md:

[![imessage-mcp MCP server](https://glama.ai/mcp/servers/kamrenkennedy/imessage-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kamrenkennedy/imessage-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/kamrenkennedy/imessage-mcp'

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