Skip to main content
Glama
yuki-yano

macOS Notify MCP

by yuki-yano
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Server Quality Checklist

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

  • Latest release: v1.0.0

  • Disambiguation5/5

    Each tool has a clearly distinct purpose: get_current_tmux_info retrieves details about the current session, list_tmux_sessions enumerates all available sessions, and send_notification handles macOS notifications with optional tmux integration. There is no overlap or ambiguity between these functions.

    Naming Consistency4/5

    The naming follows a consistent verb_noun pattern (get_current_tmux_info, list_tmux_sessions, send_notification) with clear actions and objects. The minor deviation is that send_notification uses a more generic object term compared to the tmux-specific others, but it remains readable and coherent.

    Tool Count3/5

    With only 3 tools, the set feels thin for a server named 'macOS Notify MCP', which suggests broader macOS notification capabilities. While the tools cover tmux session management and notifications, the scope might be too narrow, potentially lacking other notification-related operations.

    Completeness3/5

    The tools provide basic tmux session info and notification sending, but there are notable gaps. For a macOS notification server, expected features like managing notification settings, handling different notification types, or integrating with other system events are missing, limiting the surface's completeness.

  • Average 3/5 across 3 of 3 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • 0 of 1 community issues answered or closed in the last 6 months
    • 0 commits in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

  • Behavior2/5

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

    With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe any behavioral traits - no information about what 'current' means operationally, whether this requires specific tmux environment, what format the information returns, or any error conditions. The description is minimal and lacks behavioral context.

    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 at just 5 words - 'Get current tmux session information'. It's front-loaded with the core purpose and contains no unnecessary words or sentences. Every word earns its place in conveying the basic function.

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

    Completeness2/5

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

    Given the tool has no annotations, no output schema, and a sibling tool with similar purpose ('list_tmux_sessions'), the description is insufficiently complete. It doesn't explain what 'current' means versus 'list', what information is returned, or how this tool differs from its sibling. For a tool that presumably returns data, the lack of output description is a significant gap.

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

    Parameters4/5

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

    The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist. This meets the baseline expectation for parameterless tools.

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

    Purpose3/5

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

    The description 'Get current tmux session information' clearly states the verb ('Get') and resource ('current tmux session information'), making the purpose understandable. However, it doesn't distinguish this from the sibling tool 'list_tmux_sessions' - both appear to retrieve tmux session data, so the distinction between 'current' and 'list' isn't clarified.

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

    Usage Guidelines2/5

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

    No guidance is provided about when to use this tool versus the sibling 'list_tmux_sessions'. The description implies it retrieves 'current' information, but doesn't specify what 'current' means in this context or when you would choose this over listing all sessions. No alternatives or exclusions are mentioned.

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

  • Behavior2/5

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

    With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool sends notifications and has tmux integration, but doesn't describe what happens when notifications are sent (do they appear immediately? require permissions?), what errors might occur, or any rate limits. The description is minimal and leaves important behavioral aspects unspecified.

    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 core functionality and key feature. Every word earns its place with no wasted text, making it front-loaded and easy to parse.

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

    Completeness2/5

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

    Given this is a notification tool with 7 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, what happens on success/failure, platform requirements (macOS only?), or how the tmux integration actually works. For a tool with this complexity, more context is needed.

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

    Parameters3/5

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

    Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly with descriptions and defaults. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter documentation.

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

    Purpose4/5

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

    The description clearly states the action ('send') and resource ('macOS notification'), and mentions the optional tmux integration feature. However, it doesn't specifically differentiate this tool from its siblings (get_current_tmux_info, list_tmux_sessions), which are query tools while this is a notification tool.

    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 mentions 'optional tmux integration' which implies some context for when tmux parameters might be relevant, but provides no explicit guidance about when to use this tool versus alternatives, when not to use it, or what prerequisites might be needed for macOS notifications or tmux integration to work.

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

  • Behavior2/5

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

    With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves—no information on output format, error conditions, permissions needed, or whether it's read-only/destructive. This is inadequate for a tool with zero annotation coverage.

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

    Conciseness5/5

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

    The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool, making it easy for an agent to parse quickly.

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

    Completeness2/5

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

    Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., session names, IDs, status) or any behavioral context, which is essential for an agent to use it effectively. The simplicity of 0 parameters doesn't compensate for these gaps.

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

    Parameters4/5

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

    The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it correctly doesn't mention any, earning a baseline score of 4 for appropriate compensation.

    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 ('available tmux sessions'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_current_tmux_info' which might overlap in functionality, preventing a perfect score.

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

    Usage Guidelines2/5

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

    The description provides no guidance on when to use this tool versus alternatives like 'get_current_tmux_info' or 'send_notification'. There's no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from tool names alone.

    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

macos-notify-mcp MCP server

Copy to your README.md:

Score Badge

macos-notify-mcp MCP server

Copy to your README.md:

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yuki-yano/macos-notify-mcp'

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