imessage-mcp

by anipotts

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.5.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no significant overlap; for example, 'get_contact' retrieves detailed contact info, while 'contact_stats' provides analytics, and 'list_contacts' lists contacts with counts. The descriptions are specific enough to prevent misselection, covering unique aspects like message effects, reactions, streaks, or temporal analysis.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, such as 'check_new_messages', 'get_contact', 'list_attachments', and 'search_messages'. There are no deviations in style (e.g., all use snake_case) or verb usage, making the set predictable and easy to navigate.
Tool Count3/5
With 26 tools, the count feels heavy for an iMessage analytics server, potentially overwhelming for agents. While the tools cover a wide range of features (e.g., stats, searches, temporal analysis), it borders on excessive, as some functionalities could be consolidated (e.g., multiple analytics tools like 'contact_stats', 'message_stats', 'yearly_wrapped').
Completeness5/5
The tool surface is comprehensive for iMessage analytics, covering CRUD-like operations (e.g., 'get_conversation', 'search_messages'), lifecycle coverage (e.g., 'first_last_message', 'on_this_day'), and extensive analytics (e.g., 'streaks', 'who_initiates', 'yearly_wrapped'). There are no obvious gaps; agents can perform detailed queries, statistical analysis, and historical lookups without dead ends.
Average 4/5 across 26 of 26 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 52 commits in the last 12 weeks
- Last stable release on August 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the agent knows this is a safe, read-only operation with a closed world. The description adds context about what it queries (expressive_send_style_id) and lists effect types, which helps clarify the scope beyond annotations. However, it doesn't disclose behavioral traits like rate limits, authentication needs, or pagination details (implied by limit parameter). No contradiction with 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 concise and front-loaded, stating the core purpose in the first phrase. It uses examples efficiently ('slam, loud, gentle, etc.') and adds a clarifying note about querying expressive_send_style_id. Every sentence contributes value, with no redundant information. Minor improvement possible by structuring usage hints.
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 moderate complexity (analytics with 4 parameters), annotations cover safety (read-only, non-destructive), but no output schema exists. The description provides purpose and scope but lacks details on return format (e.g., what data is returned per effect) or behavioral context like error handling. It's adequate as a starting point but incomplete for full agent understanding without output schema.
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 schema fully documents all 4 parameters (contact, date_from, date_to, limit) with descriptions and constraints. The description adds no parameter-specific information beyond implying filtering by effect types (e.g., 'slam, loud, etc.'), but this doesn't map directly to schema parameters. Baseline 3 is appropriate as the schema carries the burden.
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: 'iMessage expressive send effects and screen effects analytics' with specific examples like 'slam, loud, gentle, invisible ink, confetti, fireworks, balloons, lasers, etc.' and mentions it 'Queries expressive_send_style_id.' This distinguishes it from siblings like get_reactions or get_read_receipts by focusing on visual/sound effects rather than reactions or read statuses. However, it doesn't explicitly differentiate from all siblings (e.g., message_stats might overlap in analytics).
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 when to choose it over siblings like get_reactions (for reaction analytics) or message_stats (for general message statistics), nor does it specify prerequisites or exclusions. The agent must infer usage from the purpose alone.
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?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the agent knows this is a safe, bounded read operation. The description adds useful context about what data is returned (member counts, message volumes, activity dates) and clarifies what constitutes a group chat. However, it doesn't mention pagination behavior, rate limits, or authentication requirements beyond what annotations provide.
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 efficiently structured in two sentences. The first sentence front-loads the core functionality with specific data points. The second sentence provides necessary clarification about what constitutes a group chat. There's minimal wasted language, though the second sentence could potentially be integrated more smoothly.
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?
For a read-only listing tool with good annotations and 100% schema coverage, the description provides adequate context about what data is returned. However, without an output schema, it doesn't specify the exact structure of returned objects (e.g., whether it's an array of objects with specific fields). The description also lacks information about error conditions, rate limits, or pagination behavior that would be helpful for an 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%, so all parameters are well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema. It implies filtering by message count through the mention of 'message volumes' but doesn't explicitly connect this to the 'min_messages' parameter. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('List') and resource ('all group chats') with specific attributes (member counts, message volumes, activity dates). It distinguishes group chats from other conversation types by defining them as having multiple participants. However, it doesn't explicitly differentiate from sibling tools like 'get_group_chat' or 'conversation_gaps' beyond the basic listing function.
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 sibling tools like 'get_group_chat' (for single chat details), 'conversation_gaps' (for analyzing conversation patterns), or 'search_messages' (for filtering content). There's no context about when this listing approach is preferred over other methods.
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?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation with limited scope. The description adds context about the type of analytics provided (message volumes, response times, patterns, trends) but doesn't disclose additional behavioral traits like performance characteristics, data freshness, or authentication requirements beyond what annotations provide.
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 extremely concise - a single sentence that efficiently communicates the tool's purpose and scope. Every word earns its place, with no redundant information or unnecessary elaboration.
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?
For a read-only analytics tool with good annotation coverage but no output schema, the description provides adequate but minimal context. It states what analytics are available but doesn't explain the return format, data granularity, or how the analytics relate to the date parameters. The combination of annotations + description gives basic understanding but leaves questions about output structure.
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?
With 100% schema description coverage, the input schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions analytics types but doesn't explain how parameters affect those analytics or provide usage examples.
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 performs 'Deep per-contact analytics' and lists specific metrics (message volumes, response time estimates, conversation patterns, yearly trends), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'message_stats' or 'temporal_heatmap' which might offer overlapping functionality.
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. With many sibling tools offering related analytics (message_stats, temporal_heatmap, yearly_wrapped, etc.), there's no indication of what distinguishes this contact-focused analytics tool from other statistical tools in the server.
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?
Annotations already declare this as read-only, non-destructive, and closed-world. The description adds some behavioral context by specifying what types of information will be returned (tier, message stats, yearly breakdown, recent messages), which helps the agent understand the scope of data returned. However, it doesn't mention any limitations, rate limits, authentication requirements, or error conditions beyond what annotations provide.
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 extremely concise - a single sentence that efficiently communicates the tool's purpose and scope. It's front-loaded with the core purpose ('Deep info on a specific contact') followed by specific data elements. Every word earns its place with no wasted text.
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?
For a read-only tool with good annotations and a fully documented single parameter, the description provides adequate but minimal context. It specifies what information will be returned, which is helpful since there's no output schema. However, it doesn't address potential limitations, error cases, or how it differs from similar sibling tools, leaving some gaps in contextual understanding.
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?
With 100% schema description coverage, the input schema already fully documents the single 'contact' parameter. The description doesn't add any additional semantic information about the parameter beyond what's in the schema. The baseline score of 3 is appropriate since the schema handles the parameter documentation adequately.
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: retrieving 'deep info on a specific contact' with specific data elements listed (tier, message stats, yearly breakdown, recent messages). It uses a specific verb ('get') and resource ('contact'), but doesn't explicitly differentiate from sibling tools like 'contact_stats' or 'resolve_contact' that might provide overlapping functionality.
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. With multiple sibling tools related to contacts (contact_stats, resolve_contact, list_contacts) and conversations (get_conversation, get_thread), there's no indication of when this specific 'deep info' retrieval is appropriate versus other contact-related tools.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering safety and scope. The description adds minimal behavioral context by specifying it queries date_read and date_delivered columns, but doesn't disclose details like response format, pagination, or rate limits. With annotations providing core safety info, this earns a baseline score for adding some value without contradiction.
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 concise and front-loaded, with the first sentence stating the core purpose and the second providing technical details. Both sentences earn their place by clarifying scope and data sources. Minor improvement could come from integrating the two sentences more smoothly, but it's efficiently structured.
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 moderate complexity (analytics query with 4 parameters), rich annotations, and 100% schema coverage, the description is adequate but lacks output details (no output schema provided) and usage context. It covers the what but not the how or when, leaving gaps in completeness for an analytics tool.
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%, with all parameters well-documented in the input schema. The description adds no parameter-specific semantics beyond implying date-range filtering through 'Queries date_read and date_delivered columns', which is already covered by the schema's date_from/date_to fields. This meets the baseline for high schema coverage without additional value.
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's purpose with specific verbs ('queries') and resources ('read receipt and delivery timing analytics'), distinguishing it from sibling tools like 'message_stats' or 'contact_stats' by focusing on read/delivery timing metrics rather than general statistics. It explicitly mentions the data columns involved ('date_read and date_delivered columns'), 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 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. While it mentions querying specific columns, it doesn't indicate scenarios where this tool is preferred over sibling tools like 'message_stats' or 'contact_stats', nor does it mention prerequisites or exclusions. The agent must infer usage from the purpose alone.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering safety and scope. The description adds valuable behavioral context: it specifies the exact message types queried (2000-2005) and the reaction types analyzed (love/like/dislike/laugh/emphasize/question). This goes beyond annotations by detailing the data scope and reaction taxonomy.
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?
Two sentences with zero waste. First sentence states purpose and analytics scope. Second sentence provides technical implementation details. Well-structured and appropriately sized for the tool's complexity. Could be slightly improved by front-loading the most critical information even more clearly.
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 moderate complexity, rich annotations (readOnly, non-destructive, closed world), and 100% schema coverage, the description is mostly complete. It lacks output format details (no output schema), but provides good context about what data is analyzed. For a read-only analytics tool with good annotations, this is sufficient though not exhaustive.
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 schema fully documents all 6 parameters. The description doesn't add parameter-specific semantics beyond what's in the schema. It mentions reaction types that align with the enum but doesn't explain parameter interactions or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Tapback/reaction analytics' with specific analytics types (distribution by type, top reactors, most-reacted messages, emoji breakdown). It distinguishes from siblings by focusing on reactions rather than messages, contacts, or conversations. The mention of 'associated_message_type 2000-2005' provides technical specificity.
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 explicit guidance on when to use this tool versus alternatives. While it mentions querying specific message types for reactions, it doesn't compare to sibling tools like 'get_message_effects' or 'message_stats' that might overlap. The description provides context about what it queries but not when it's the appropriate choice among available tools.
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?
Annotations already indicate this is a read-only, non-destructive, closed-world operation. The description adds useful context beyond annotations by explaining the 'conversation initiation' logic ('After a gap of N hours') and the default exclusion of unreplied contacts. However, it doesn't disclose behavioral traits like potential data volume, performance considerations, or output format details, which would be helpful given the lack of an output schema.
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 appropriately sized and front-loaded, starting with the core question ('Who starts conversations?') followed by key functionality and a default behavior note. Every sentence adds value without redundancy, efficiently conveying the tool's purpose and scope in three concise sentences.
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 moderate complexity (7 parameters, no output schema) and rich annotations, the description is adequate but has gaps. It explains the tool's purpose and default behavior well, but without an output schema, it should ideally describe the return format (e.g., ranking, percentages) or result structure. The description relies on annotations for safety but misses opportunities to clarify output expectations.
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 schema fully documents all 7 parameters. The description adds marginal semantic value by implying the 'gap_hours' parameter's role in defining 'conversation initiation' and hinting at 'include_all' with the default exclusion note. However, it doesn't provide additional meaning beyond what the schema already specifies, such as parameter interactions or usage examples.
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's purpose with specific verbs ('shows per-contact who reaches out first and how often') and resources ('conversation initiation'), directly answering the question 'do I always text first?' It distinguishes itself from sibling tools by focusing on conversation initiation patterns rather than general message stats, contact lists, or temporal analysis.
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 this tool ('Answers 'do I always text first?'') and mentions a default exclusion criterion ('By default excludes contacts you've never replied to'), which helps differentiate it from tools like 'contact_stats' or 'message_stats'. However, it doesn't explicitly name alternative tools or specify when not to use it, such as for real-time message checking or detailed conversation analysis.
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?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, indicating a safe, read-only operation with limited scope. The description adds useful context about default exclusions (contacts never replied to) and the comprehensive nature of the summary, but does not detail rate limits, auth needs, or output format beyond listed metrics.
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, starting with the core purpose and key features in a single sentence, followed by default behaviors. It avoids redundancy, though it could be slightly more structured by separating purpose from defaults.
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 complexity (aggregating multiple metrics), rich annotations, and 100% schema coverage, the description is mostly complete. It lacks an output schema, so it doesn't detail return values, but it lists summary components clearly. More behavioral context (e.g., data freshness, permissions) would enhance completeness.
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%, with parameters 'year' and 'include_all' well-documented in the schema. The description adds minimal semantic value by mentioning defaults ('last year', excludes unreplied contacts) but does not explain parameter interactions or usage beyond what the schema provides, meeting the baseline for high 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 clearly states the tool's purpose: 'Returns a complete summary of a year' with specific details like 'total messages, top contacts, busiest day, monthly trends, reactions, group chats, media shared, late-night texting, new contacts, and effects used.' It distinguishes from siblings by focusing on a comprehensive yearly summary rather than specific metrics or searches.
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 this tool: for a 'Year in Review' summary of iMessage data. It mentions defaults (last year, excludes unreplied contacts) but does not explicitly state when not to use it or name specific alternatives among siblings, though it implies this is for aggregated yearly insights.
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?
Annotations already indicate read-only, non-destructive, and closed-world behavior, which the description does not contradict. The description adds valuable context beyond annotations by specifying what the tool detects ('periods where you and a contact stopped talking') and what it returns ('gap duration and when it happened'), enhancing understanding of its behavioral output without redundancy.
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 front-loaded with the core purpose in the first sentence, followed by additional context and output details in subsequent sentences. Each sentence adds meaningful information without redundancy, making it efficiently structured and appropriately sized for the tool's complexity.
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 moderate complexity (3 parameters, no output schema), the description provides sufficient context by explaining what the tool does and what it returns. However, it lacks details on output format (e.g., structure of returned gaps) and potential limitations (e.g., data availability), which could be helpful for an agent despite the good annotations and schema coverage.
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, clearly documenting all parameters (contact, min_gap_days, limit) with their purposes and defaults. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or edge cases, so it meets the baseline for high schema coverage without extra value.
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's purpose with specific verbs ('find', 'detects', 'shows') and resources ('longest silences in a conversation', 'gap duration and when it happened'). It distinguishes from siblings by focusing on conversation gaps rather than messages, contacts, or other conversation metrics, making the purpose distinct and unambiguous.
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 for analyzing conversation patterns like 'falling-outs, busy periods, or drifting apart', but does not explicitly state when to use this tool versus alternatives (e.g., 'streaks' or 'temporal_heatmap' for other temporal analyses). It provides some context but lacks direct comparisons or exclusions, leaving the agent to infer appropriate scenarios.
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?
Annotations already declare this as a read-only, non-destructive, closed-world operation. The description adds useful behavioral context about the default exclusion of contacts you've never replied to, which goes beyond what annotations provide. However, it doesn't describe output format, pagination behavior, or performance characteristics that would be helpful for an agent.
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 perfectly concise with just two sentences that each earn their place. The first sentence states the core purpose, the second adds important behavioral context about the default exclusion. No wasted words, and the most important information comes first.
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 read-only query tool with good annotations and full schema coverage, the description provides adequate context. The lack of output schema means the agent won't know the return format, but the description gives enough information about what the tool does to be useful. The description could be more complete by mentioning what information is returned about each contact.
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?
With 100% schema description coverage, all parameters are well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
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's purpose with specific verbs ('find dormant relationships', 'reconnecting') and identifies the resource ('contacts you used to message'). It distinguishes from siblings like 'list_contacts' or 'get_contact' by focusing specifically on inactive relationships rather than general contact listing or retrieval.
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 this tool ('reconnecting with people you've lost touch with') and implicitly distinguishes it from sibling tools by its unique focus on dormant contacts. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering safety and completeness. The description adds valuable behavioral context beyond annotations: it specifies the database columns queried (date_retracted, date_edited) and the return format (message list with timestamps and per-contact stats), which helps the agent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose. Every sentence earns its place: the first states what the tool does and what it queries, the second describes the return format. No wasted words or redundant information.
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 read-only query tool with good annotations and full parameter documentation, the description provides adequate context. It explains what the tool searches for and what it returns, though there's no output schema. The main gap is lack of explicit usage guidance versus sibling tools, but overall it's reasonably complete for this complexity level.
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 schema fully documents all 5 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
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's purpose with specific verbs ('Find edited and unsent messages') and resources ('messages'), and distinguishes it from siblings by specifying it queries date_retracted and date_edited columns. This is more specific than generic message search tools like 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning what it queries (date_retracted/date_edited columns) and what it returns, but doesn't explicitly state when to use this versus alternatives like search_messages or check_new_messages. No explicit when-not-to-use guidance or named alternatives are provided.
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?
Annotations indicate read-only, non-destructive, and closed-world behavior, which the description aligns with by describing a retrieval operation. The description adds valuable context beyond annotations by specifying what data is returned (members with counts, activity timeline, recent messages), enhancing transparency about the tool's output and scope without contradicting annotations.
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 that front-loads the core purpose ('Detailed info on a specific group chat') and succinctly lists the key data returned. Every part earns its place with no redundant or vague language, making it highly concise and well-structured.
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 moderate complexity (retrieving detailed chat data), rich annotations (read-only, non-destructive), and no output schema, the description is reasonably complete. It specifies the data scope but could improve by mentioning output format or limitations (e.g., pagination). However, it provides enough context for an agent to understand the tool's function and use it effectively.
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%, with clear descriptions for 'chat_id' and 'name' parameters. The description does not add meaning beyond the schema, such as explaining parameter interactions (e.g., using both parameters together) or providing examples. Baseline score of 3 is appropriate as the schema adequately documents parameters.
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's purpose with specific verbs ('get', 'Detailed info on') and resources ('a specific group chat'), distinguishing it from siblings like 'list_group_chats' (which lists chats) and 'get_conversation' (which likely handles individual conversations). It specifies the scope of information returned: members with counts, activity timeline, and recent messages.
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 for retrieving detailed data about a specific group chat, but does not explicitly state when to use it versus alternatives like 'get_conversation' or 'get_thread'. No guidance is provided on prerequisites, exclusions, or specific contexts for selection, leaving usage inferred rather than clearly defined.
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?
Annotations already indicate read-only, non-destructive, and closed-world behavior. The description adds valuable context beyond annotations by specifying that it returns nested thread trees with parent messages and replies in order, which clarifies the output structure and ordering behavior not covered by annotations.
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 front-loaded and concise, with two sentences that efficiently convey the tool's purpose and output. Every sentence adds value without redundancy, making it easy for an agent to quickly understand the tool's function.
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 moderate complexity (3 parameters, no output schema), the description is mostly complete. It explains the core functionality and output format, but lacks details on error handling, performance limits, or how it integrates with sibling tools. With annotations covering safety, it provides sufficient context for basic use.
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 schema fully documents parameters. The description does not add meaning beyond the schema, such as explaining how parameters interact (e.g., combining message_guid and contact) or providing examples. Baseline 3 is appropriate as the schema handles parameter documentation 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 the tool's purpose with specific verbs ('reconstruct', 'returns') and resources ('iMessage reply threads', 'nested thread trees'), distinguishing it from sibling tools like get_conversation or get_message_effects by focusing on thread reconstruction rather than general conversation retrieval or message metadata.
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 for thread reconstruction but does not explicitly state when to use this tool versus alternatives like get_conversation or search_messages. It provides context (using thread_originator_guid) but lacks explicit guidance on exclusions or prerequisites, such as whether it works for group chats or specific message types.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering safety and scope. The description adds valuable context by specifying that it returns 'file metadata, not file contents', which clarifies the output behavior beyond what annotations provide. No contradictions with annotations exist.
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, well-structured sentence that efficiently conveys purpose, filtering options, and output clarification. Every part earns its place with no wasted words, making it easy to parse and understand quickly.
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 moderate complexity (6 parameters, no output schema), the description provides a clear purpose and behavioral context. With annotations covering safety and scope, and schema covering parameters, the description adds necessary context about metadata vs. contents. It could slightly improve by mentioning pagination (implied by limit/offset) but is largely 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?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description mentions filtering by contact, MIME type, and date range, which aligns with the schema but doesn't add significant semantic details beyond it. The baseline score of 3 is appropriate since the schema does the heavy lifting.
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 ('Query') and resource ('message attachments') with specific examples (images, videos, audio, documents). It distinguishes from sibling tools like 'search_messages' by focusing specifically on attachments rather than general messages, and clarifies it returns metadata not file contents.
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 through the filtering parameters (contact, MIME type, date range), suggesting when this tool is appropriate. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_messages' or provide any exclusion criteria. The guidance is contextual but not explicit.
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?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, covering safety and scope. The description adds valuable behavioral context by specifying the default exclusion of contacts never replied to and the types of statistics returned (counts, splits, averages), which are not covered by annotations. No contradiction with annotations.
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 appropriately sized and front-loaded, with two sentences that efficiently convey the tool's functionality and key behavioral trait (default exclusion). Every sentence adds value without redundancy, making it easy to scan and understand.
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 moderate complexity (5 parameters, no output schema) and rich annotations, the description is mostly complete. It covers the tool's purpose, key behavior, and output types, but could benefit from more explicit usage guidance relative to siblings. The lack of an output schema is partially mitigated by describing return values in the description.
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 schema fully documents all parameters. The description adds minimal semantic value beyond the schema, such as implying the purpose of 'include_all' with the default exclusion note, but does not provide additional syntax or format details. Baseline 3 is appropriate given high 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 clearly states the tool's purpose with specific verbs ('aggregate message statistics') and resources ('message statistics'), and distinguishes it from siblings by specifying its unique focus on time-series grouping and exclusion of unreplied contacts. It goes beyond a simple 'get stats' to define the analytical nature of the tool.
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 through its mention of 'flexible time-series grouping' and default exclusions, but does not explicitly state when to use this tool versus alternatives like 'contact_stats' or 'temporal_heatmap'. It provides some context but lacks direct comparisons or exclusions for sibling tools.
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?
Annotations already indicate read-only, non-destructive, and closed-world behavior. The description adds valuable context by detailing the multi-level resolution process (exact match, digits, fuzzy, macOS AddressBook), which helps the agent understand how matching works beyond basic safety.
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 that front-loads the core purpose and adds necessary detail about the resolution process. Every word contributes meaning 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 read-only tool with one parameter and no output schema, the description is mostly complete. It explains the fuzzy matching behavior well, but could benefit from mentioning the expected return format or match confidence levels to fully guide 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%, with the parameter 'query' fully documented. The description adds marginal value by listing the types of queries (name, phone, email) but doesn't provide additional syntax or format details beyond what the schema already states.
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 specific action ('fuzzy-match'), the resource ('contact record'), and the input types ('name, phone number, or email'). It distinguishes from siblings like 'get_contact' by specifying the fuzzy matching approach rather than direct retrieval.
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 when you have partial or inexact contact information, but it doesn't explicitly state when to use this vs. alternatives like 'get_contact' or 'list_contacts'. No exclusions or specific contexts 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows this is a safe, read-only operation with limited scope. The description adds useful context about the default search scope ('only searches contacts you've messaged') and the include_all override, but doesn't provide additional behavioral details like rate limits, performance characteristics, or error conditions.
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 perfectly concise with just two sentences that are front-loaded with the core purpose. Every word earns its place: the first sentence establishes scope and capabilities, while the second clarifies a critical default behavior. There's zero redundancy or wasted verbiage.
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 search tool with comprehensive annotations and full parameter documentation, the description provides adequate context about scope and default behavior. The main gap is the absence of an output schema, leaving return format unspecified. However, given the tool's read-only nature and clear purpose, the description provides sufficient guidance for basic usage.
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?
With 100% schema description coverage, all 11 parameters are well-documented in the input schema. The description provides high-level grouping of filter types ('query text, contact, date range, direction, group chat, and attachment filters') and clarifies the include_all default behavior, but doesn't add significant semantic value beyond what's already in the detailed parameter descriptions.
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 performs 'full-text search across all iMessages with rich filtering', specifying both the verb ('search') and resource ('iMessages'). It distinguishes itself from siblings like 'get_conversation' or 'get_thread' by emphasizing comprehensive search capabilities rather than retrieving specific conversations or threads.
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 about when to use this tool ('full-text search across all iMessages') and includes one explicit usage note about the 'include_all' parameter default behavior. However, it doesn't explicitly contrast when to use this versus alternatives like 'get_conversation' for specific threads or 'list_contacts' for contact-focused operations.
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?
Annotations already indicate read-only, non-destructive, and closed-world behavior. The description adds valuable context by specifying the sentimental use case and clarifying that it retrieves both first and last messages, which helps the agent understand the tool's behavioral intent beyond the basic 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 front-loaded with the core functionality in the first sentence, followed by illustrative examples that reinforce the use case. Both sentences are purposeful, with no redundant or vague language, making it efficiently structured.
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 low complexity (single parameter, no output schema) and rich annotations, the description is mostly complete. It explains the purpose and usage context well, but could slightly enhance completeness by mentioning potential limitations (e.g., data availability for old contacts) or the output format, though not strictly required.
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, fully documenting the 'contact' parameter. The description does not add any parameter-specific details beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without extra semantic value.
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's purpose: retrieving the first and last messages exchanged with a contact. It uses specific verbs ('exchanged', 'lookups') and distinguishes from siblings by focusing on sentimental use cases rather than statistical or operational queries like 'check_new_messages' or '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 this tool ('sentimental lookups') with concrete examples. However, it does not explicitly state when not to use it or name specific alternatives among siblings, though the examples imply it's for personal reflection rather than data analysis.
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?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, covering safety and scope. The description adds valuable behavioral context beyond annotations by explaining pagination mechanics (cursor-based with before_rowid/after_rowid) and the purpose of pagination ('for scrolling through history' and 'for catching up on new messages'), though it lacks details on error handling or rate limits.
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 appropriately sized with two sentences: the first states the core purpose, and the second explains pagination mechanics. Every sentence adds essential information without redundancy, making it front-loaded and efficient.
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 complexity (7 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose and pagination behavior, but lacks details on error cases, response format, or how parameters like 'contact' and 'chat_id' interact, which would enhance completeness for an 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%, so the schema fully documents all 7 parameters. The description adds marginal value by mentioning pagination support and context for before_rowid/after_rowid, but does not provide additional semantic details beyond what the schema already specifies, such as parameter interactions or default behaviors.
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's purpose with specific verbs ('Get a full conversation thread') and resources ('with a specific contact or chat'), distinguishing it from siblings like 'get_thread' or 'search_messages' by emphasizing full thread retrieval with pagination support.
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 usage ('Supports cursor-based pagination... for scrolling through history'), but does not explicitly state when to use this tool versus alternatives like 'get_thread' or 'search_messages', nor does it mention exclusions or prerequisites.
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?
Annotations already indicate read-only, non-destructive, and closed-world behavior. The description adds valuable context beyond this: it explains the default filtering logic (excludes contacts never replied to), the temporal scope (1, 2, 3+ years ago), and the nostalgic purpose. No contradictions with annotations exist.
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 front-loaded with the core purpose in the first sentence, followed by clarifying details. Every sentence adds value: the analogy, temporal scope, and default behavior. It is efficiently written with zero redundant information.
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 moderate complexity, rich annotations, and full schema coverage, the description is nearly complete. It explains the tool's unique purpose and behavioral context well. The main gap is the lack of an output schema, but the description compensates by implying the return type (messages).
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%, providing full parameter documentation. The description does not add specific parameter semantics beyond what the schema already states. It mentions filtering by contact and the include_all option implicitly, but no new syntax or format details are introduced.
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's purpose: retrieving messages from this date in previous years, analogous to 'Memories' for iMessage. It specifies the scope (messages from you and your contacts) and distinguishes it from siblings by focusing on historical date-based retrieval rather than searching, stats, or contact management.
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 this tool: for nostalgic or reflective purposes looking at past conversations. It mentions a default exclusion (contacts never replied to) and an option to override this. However, it does not explicitly state when NOT to use it or name specific alternatives among siblings.
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?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, establishing this as a safe, bounded read operation. The description adds valuable behavioral context beyond annotations: it explains the default filtering behavior (excludes contacts you've never replied to), mentions the streak calculation methodology (consecutive-day messaging), and describes the output format (shows longest streak, when it happened, current status). This goes beyond what annotations provide.
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 perfectly concise and well-structured: three sentences that each earn their place. First sentence defines the core concept, second sentence explains what information is returned, third sentence clarifies default behavior. No wasted words, front-loaded with the most important information.
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 read-only tool with good annotations and full schema coverage, the description provides excellent context about what the tool does and returns. The main gap is the lack of output schema, so the description doesn't specify the exact structure of returned streak data. However, it does describe the semantic content (longest streak, when it happened, current status), which helps compensate. Given the tool's moderate complexity, this is quite 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?
Schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. However, it does provide context about the tool's overall behavior that helps understand parameter usage (like why include_all exists). Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: tracking consecutive-day messaging streaks with contacts, specifically comparing it to Snapchat streaks for iMessage. It distinguishes from siblings by focusing on streak analysis rather than general message retrieval (like get_thread) or contact listing (like list_contacts). The description explicitly mentions showing longest streak, when it happened, and current streak status.
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 about when to use this tool (for streak analysis) and includes a default behavior statement (excludes contacts you've never replied to). However, it doesn't explicitly contrast with specific sibling tools like contact_stats or message_stats that might provide overlapping functionality, nor does it mention when NOT to use this tool.
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?
Annotations already declare this as read-only, non-destructive, and closed-world. The description adds valuable behavioral context beyond annotations: it specifies the output format (168 time slots with message counts) and the default filtering behavior (excluding contacts never replied to). This helps the agent understand what data will be returned and how it's filtered, though it doesn't mention rate limits or authentication requirements.
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 perfectly concise: two sentences that efficiently communicate the tool's purpose, output format, and default behavior. Every word earns its place, with no redundant information. The structure is front-loaded with the core functionality followed by important behavioral 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 annotations cover safety aspects (read-only, non-destructive) and the schema fully documents parameters, the description provides good contextual completeness. It explains the output format and default filtering behavior. The main gap is the lack of an output schema, but the description compensates by specifying what's returned. For a read-only analysis tool, this is nearly 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?
With 100% schema description coverage, the input schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. However, it does provide context about the default behavior ('excludes contacts you've never replied to') which relates to the 'include_all' parameter, offering some semantic clarification.
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's purpose: 'Generate a 7x24 activity heatmap (day-of-week x hour-of-day). Returns message counts for each of the 168 weekly time slots.' It specifies both the action ('generate') and resource ('activity heatmap'), and distinguishes itself from siblings by focusing on temporal message analysis rather than contact lists or conversation retrieval.
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 this tool: analyzing message activity patterns over time. It includes a default behavior ('excludes contacts you've never replied to') that helps guide usage. However, it doesn't explicitly mention when to choose this over similar tools like 'message_stats' or 'yearly_wrapped', which could provide related temporal insights.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable behavioral context about baseline tracking and incremental reporting that goes beyond annotations. However, it doesn't mention rate limits, authentication needs, or response format details.
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 sentences that efficiently convey the core functionality and usage pattern. Every word earns its place with zero waste or redundancy. The description is front-loaded with the main 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 read-only tool with good annotations and full schema coverage, the description provides adequate context about the incremental behavior. However, without an output schema, it doesn't describe what the return format looks like (e.g., message objects, timestamps, structure).
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 schema already fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 specific action ('Check for new messages') and resource ('messages'), with explicit scope ('since your last check'). It distinguishes from sibling tools like 'search_messages' by focusing on incremental updates rather than general searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'First call sets a baseline. Subsequent calls report what arrived since.' This clearly indicates when to use it (for incremental message checking) versus alternatives like 'search_messages' for general queries or 'get_conversation' for specific threads.
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?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only, non-destructive, and closed-world behavior, the description reveals specific output details: 'Shows frequency, longest bursts, and who does it more' and 'global ranking of who you double-text the most'. This gives the agent insight into what kind of analysis and ranking information to expect, which annotations don't cover.
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 perfectly front-loaded and efficient. The first sentence establishes the core purpose, the second explains the mechanism, and the third clarifies the key usage distinction. Every sentence earns its place with no wasted words, making it easy for an agent to quickly understand when and how to use this tool.
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 moderate complexity (5 parameters, no output schema), the description provides good contextual completeness. It covers purpose, usage guidance, and output behavior. The main gap is the lack of output format details (what the 'frequency', 'bursts', and 'ranking' actually look like), but with good annotations and clear parameter documentation, this is a minor omission for a read-only analysis tool.
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?
With 100% schema description coverage, the baseline is 3. The description adds some semantic context for the 'contact' parameter ('omit for global double-text ranking'), but doesn't provide additional meaning for other parameters beyond what's already in their schema descriptions. The description compensates slightly but not significantly beyond the comprehensive schema documentation.
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's purpose with specific verbs ('detect', 'finds', 'shows') and resources ('double-texting and unanswered message patterns', 'multiple consecutive messages without a reply'). It explicitly distinguishes this tool from siblings by focusing on consecutive message analysis rather than general message stats, contact info, or conversation gaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: 'Omit contact for a global ranking of who you double-text the most' gives clear parameter-based usage rules. It also implicitly distinguishes from sibling tools like 'contact_stats', 'message_stats', and 'conversation_gaps' by focusing specifically on consecutive message patterns rather than general statistics or gap analysis.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering safety and scope. The description adds valuable behavioral context: the default filtering logic (only contacts you've replied to) and the override mechanism (include_all). It doesn't mention pagination or rate limits, but with annotations present, this is sufficient for a high score.
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?
Three sentences with zero waste: first states purpose and key features, second explains default behavior, third provides usage guidance. Every sentence earns its place by adding distinct value (scope, filtering logic, parameter guidance).
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 read-only listing tool with good annotations and full schema coverage, the description is nearly complete. It explains the tool's purpose, default behavior, and key parameters. The main gap is lack of output format details (no output schema), but given the annotations and context, this is a minor omission. It adequately supports agent decision-making.
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 parameters are fully documented in the schema. The description mentions filtering by 'tier and minimum message threshold' and the 'include_all' parameter, but doesn't add significant semantic meaning beyond what the schema provides (e.g., it doesn't explain what 'tier' represents or how 'min_messages' is calculated). Baseline 3 is appropriate when schema does the heavy lifting.
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 ('List') and resource ('contacts') with specific scope ('all contacts with message counts and tier assignments'). It distinguishes from siblings like 'get_contact' (single contact) and 'resolve_contact' (identity resolution) by emphasizing comprehensive listing with metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use alternatives: 'By default, only shows contacts you've actually messaged (replied to). Use include_all to see all.' This provides clear guidance on the default behavior versus the override parameter, helping the agent choose between filtered and comprehensive views.
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?
The description adds valuable behavioral context beyond annotations. While annotations indicate read-only, non-destructive, and closed-world operation, the description clarifies this is a guide/show operation with no data manipulation. It doesn't contradict annotations but provides helpful context about what the tool actually returns (a guide with examples).
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 perfectly concise with two sentences that each serve distinct purposes: the first states what the tool does, the second provides usage guidance. There is zero wasted language or redundancy.
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?
For a parameterless, read-only guide tool with no output schema, the description is complete. It explains what the tool provides (a guide with all tools and examples) and when to use it. Given the tool's simple nature and the annotations covering safety aspects, no additional information is needed.
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?
With 0 parameters and 100% schema coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what the tool does, which is correct for a parameterless tool.
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's purpose: 'Show the imessage-mcp guide: all 26 tools and usage examples.' It specifies the exact resource (guide) and verb (show), and distinguishes itself from siblings by being a meta-tool for discovery rather than data retrieval or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Call this when you're unsure what's available.' This provides clear guidance on the specific context for usage versus the 25 sibling tools that perform actual operations on iMessage data.
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/anipotts/imessage-mcp/badges/card.svg)](https://glama.ai/mcp/servers/anipotts/imessage-mcp)

Score Badge

Copy to your README.md:

[![imessage-mcp MCP server](https://glama.ai/mcp/servers/anipotts/imessage-mcp/badges/score.svg)](https://glama.ai/mcp/servers/anipotts/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/anipotts/imessage-mcp'

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