Add mcp-notify server manifest

[al-one]

User description

Added manifest for mcp-notify server with details on messaging capabilities and required arguments.

https://github.com/aahl/mcp-notify

---

PR Type

Enhancement

---

Description

• Add mcp-notify server manifest to registry

• Define messaging capabilities for multiple platforms

• Configure WeWork, Telegram integration tools

• Specify installation and authentication requirements

---

Diagram Walkthrough

flowchart LR
  A["mcp-notify Server"] --> B["WeWork Tools"]
  A --> C["Telegram Tools"]
  B --> D["Send Text/Markdown"]
  B --> E["Send Image"]
  C --> F["Send Message"]
  C --> G["Send Photo"]

Loading

File Walkthrough

Relevant files

Configuration changes

mcp-notify.json Complete mcp-notify server manifest configuration                mcp-registry/servers/mcp-notify.json Created new server manifest with complete configuration Defined four messaging tools: WeWork text/image and Telegram message/photo Configured authentication arguments for WeWork, Telegram with optional defaults Specified uvx installation method and metadata including categories and tags +151/-0

---

Summary by CodeRabbit

• New Features
  • Registered a new MCP Notify server for sending notifications.
  • Added support for WeChat Work, Telegram, DingTalk, and Lark messaging.
  • Introduced tools to send text and image/photo messages across those platforms.
  • Added configurable connection options (bot keys/tokens and default chat) and an installation entry to run the server.

[coderabbitai]

Walkthrough

Adds a new MCP Notify server manifest describing metadata, credential configuration arguments, multiple notification tools with input schemas (WeWork, Telegram, Ding, Lark), and an installation entry for launching the server.

Changes

Cohort / File(s)

Summary

New MCP Notify Registry Entry mcp-registry/servers/mcp-notify.json

New manifest adding server metadata (name, display_name, description, repository, author, license, categories, tags); configuration arguments (WEWORK_BOT_KEY, TELEGRAM_BOT_TOKEN, TELEGRAM_DEFAULT_CHAT, DINGTALK_BOT_KEY, LARK_BOT_KEY); tool definitions with input schemas for wework_send_text, wework_send_image, tg_send_message, tg_send_photo, ding_send_text, lark_send_text (required fields, types, descriptions); and an install entry to run via uvx.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant Client as Caller
  participant Manifest as MCP Notify (manifest)
  participant Server as MCP Notify (runtime)
  participant WeWork as WeWork API
  participant Telegram as Telegram API
  participant Ding as Ding API
  participant Lark as Lark API

  Note over Client,Manifest: Caller selects a tool and supplies payload
  Client->>Manifest: select tool + payload
  Manifest->>Server: route request with configured args (tokens, chats)
  alt Telegram tool
    Server->>Telegram: POST sendMessage / sendPhoto (uses TELEGRAM_BOT_TOKEN)
    Telegram-->>Server: response
  end
  alt WeWork tool
    Server->>WeWork: POST send_text or send_image (uses WEWORK_BOT_KEY)
    WeWork-->>Server: response
  end
  alt Ding or Lark tool
    Server->>Ding: POST send_text (uses DINGTALK_BOT_KEY)
    Server->>Lark: POST send_text (uses LARK_BOT_KEY)
    Ding-->>Server: response
    Lark-->>Server: response
  end
  Server-->>Client: success / error

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Validate JSON manifest structure and top-level fields.
• Check each tool schema for correct required fields, types, and descriptions.
• Confirm configuration argument names match runtime expectations.
• Verify the install command and repository URL.

Files needing attention:

• mcp-registry/servers/mcp-notify.json — focus on nested schema correctness, required arrays, and token/field naming.

Poem

🐰 I hopped into the registry to play,
Tokens tucked in pockets, ready to relay.
Messages scurry through tunnels of light,
Bells and pings carried into the night.
Hop — another notify blooms bright.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "Add mcp-notify server manifest" is clear, concise, and directly summarizes the main change in the changeset. It accurately identifies that the PR adds a new server manifest file (mcp-notify.json) to the registry, which is the primary objective of the changeset. The title is specific enough to convey the core intent without being overly detailed, and it uses straightforward language without vague or generic terms. The title aligns perfectly with the actual changes shown in the raw summary and PR objectives.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bb689aa and 47cbedb.

📒 Files selected for processing (1)

• mcp-registry/servers/mcp-notify.json (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• mcp-registry/servers/mcp-notify.json

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[qodo-merge-pro]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: No audit logs: The manifest defines messaging tools but does not indicate any logging or audit trail for message sends, which may be required for critical action traceability. Referred Code "tools": [ { "name": "wework_send_text", "description": "Send text or markdown message via WeWork Group Robot", "inputSchema": { "type": "object", "properties": { "text": { "type": "string", "description": "The message content to send." }, "msgtype": { "type": "string", "description": "The parse mode of content. [text/markdown_v2]" }, "bot_key": { "type": "string", "description": "Special robot key specified in the prompts." } }, "required": [ ... (clipped 76 lines)
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Undefined errors: The manifest specifies tool schemas but lacks error/edge-case handling policies or response schemas, making robustness unverifiable from the diff. Referred Code "tools": [ { "name": "wework_send_text", "description": "Send text or markdown message via WeWork Group Robot", "inputSchema": { "type": "object", "properties": { "text": { "type": "string", "description": "The message content to send." }, "msgtype": { "type": "string", "description": "The parse mode of content. [text/markdown_v2]" }, "bot_key": { "type": "string", "description": "Special robot key specified in the prompts." } }, "required": [ ... (clipped 76 lines)
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Error exposure unclear: The manifest does not specify how user-facing versus internal error details are handled by tools, so exposure risk cannot be assessed. Referred Code "tools": [ { "name": "wework_send_text", "description": "Send text or markdown message via WeWork Group Robot", "inputSchema": { "type": "object", "properties": { "text": { "type": "string", "description": "The message content to send." }, "msgtype": { "type": "string", "description": "The parse mode of content. [text/markdown_v2]" }, "bot_key": { "type": "string", "description": "Special robot key specified in the prompts." } }, "required": [ ... (clipped 76 lines)
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Secrets handling: Sensitive arguments like TELEGRAM_BOT_TOKEN and WEWORK_BOT_KEY are defined without guidance on redaction or logging, leaving potential exposure concerns. Referred Code "arguments": { "WEWORK_BOT_KEY": { "description": "The default key for the WeWork group robot can also be specified in the prompt", "required": false, "example": "aabbccdd-eeff-0000-1234-..." }, "TELEGRAM_BOT_TOKEN": { "description": "Telegram Bot Token", "required": false, "example": "123456789:abcdef" }, "TELEGRAM_DEFAULT_CHAT": { "description": "Telegram Default Chat ID", "required": false, "example": "-1234567890" } },
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Missing validation: Tool input schemas accept user-provided strings (e.g., URLs, text) without constraints or validation rules, leaving input sanitization and authentication behavior unspecified. Referred Code "tools": [ { "name": "wework_send_text", "description": "Send text or markdown message via WeWork Group Robot", "inputSchema": { "type": "object", "properties": { "text": { "type": "string", "description": "The message content to send." }, "msgtype": { "type": "string", "description": "The parse mode of content. [text/markdown_v2]" }, "bot_key": { "type": "string", "description": "Special robot key specified in the prompts." } }, "required": [ ... (clipped 76 lines)
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
High-level	Manifest description overstates available integrations The server's description lists support for many platforms, but the manifest only implements tools for WeWork and Telegram. The description should be updated to accurately reflect the available integrations to avoid misleading users. Examples: mcp-registry/servers/mcp-notify.json [4] "description": "Provides an MCP (Model Context Protocol) server for message push, supporting Weixin, DingTalk, Telegram, Bark, Lark, Feishu, and Home Assistant.", mcp-registry/servers/mcp-notify.json [41-138] "tools": [ { "name": "wework_send_text", "description": "Send text or markdown message via WeWork Group Robot", "inputSchema": { "type": "object", "properties": { "text": { "type": "string", "description": "The message content to send." ... (clipped 88 lines) Solution Walkthrough: Before: { "description": "Provides an MCP ... server for message push, supporting Weixin, DingTalk, Telegram, Bark, Lark, Feishu, and Home Assistant.", ... "tools": [ { "name": "wework_send_text", ... }, { "name": "wework_send_image", ... }, { "name": "tg_send_message", ... }, ... ] } After: { "description": "Provides an MCP (Model Context Protocol) server for message push, supporting WeWork and Telegram.", ... "tools": [ { "name": "wework_send_text", ... }, { "name": "wework_send_image", ... }, { "name": "tg_send_message", ... }, ... ] } Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies a critical discrepancy between the advertised features in the description and the actual implemented tools, which is misleading for users of the registry.	High
Possible issue	Correct misleading tool parameter description Correct the description for the msgtype parameter in the wework_send_text tool. The valid values are 'text' or 'markdown', not 'markdown_v2'. mcp-registry/servers/mcp-notify.json [52-55] "msgtype": { "type": "string", - "description": "The parse mode of content. [text/markdown_v2]" + "description": "The message type. Can be 'text' or 'markdown'." }, Apply / Chat Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that the msgtype description for the WeWork tool incorrectly lists markdown_v2 instead of markdown, which would cause user errors.	Low
	Fix inaccurate tool parameter description Update the parse_mode description for Telegram tools. Remove the invalid 'text' option and add the supported 'HTML' option, listing 'MarkdownV2' and 'HTML' as valid values. mcp-registry/servers/mcp-notify.json [96-99] "parse_mode": { "type": "string", - "description": "The parse mode of content. [text/MarkdownV2]" + "description": "The parse mode for the message content. Supported values are 'MarkdownV2' and 'HTML'." }, Apply / Chat Suggestion importance[1-10]: 6 __ Why: The suggestion correctly points out that text is not a valid value for Telegram's parse_mode and that HTML is a missing supported value, improving the accuracy of the tool's documentation.	Low
Organization best practice	Prefix tool names for uniqueness Add unique, server-scoped tool names (e.g., with a server prefix) to prevent collisions with similarly named tools from other servers in the registry. mcp-registry/servers/mcp-notify.json [41-138] "tools": [ { - "name": "wework_send_text", + "name": "mcp-notify::wework_send_text", "description": "Send text or markdown message via WeWork Group Robot", "inputSchema": { ... } }, { - "name": "wework_send_image", + "name": "mcp-notify::wework_send_image", "description": "Send a photo message via WeWork Group Robot", "inputSchema": { ... } }, { - "name": "tg_send_message", + "name": "mcp-notify::tg_send_message", "description": "Send text or markdown message via Telegram bot", "inputSchema": { ... } }, { - "name": "tg_send_photo", + "name": "mcp-notify::tg_send_photo", "description": "Send a photo message via Telegram bot", "inputSchema": { ... } } ] [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 6 __ Why: Relevant best practice - Manage server capability name conflicts by supporting strict mode or auto-prefixing to avoid duplicate tool names across servers.	Low
Update

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

mcp-registry/servers/mcp-notify.json (1)

100-103: Consider type alignment for message ID fields.

The reply_to_message_id fields in both tg_send_message and tg_send_photo are typed as "string", but Telegram's API typically expects integers. Verify whether string type is intentional for flexibility or a type mismatch. If IDs must be integers, consider updating the schema.

Also applies to: 128-131

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c7fa277 and 8d60d29.

📒 Files selected for processing (1)

• mcp-registry/servers/mcp-notify.json (1 hunks)

🔇 Additional comments (1)

mcp-registry/servers/mcp-notify.json (1)

1-151: JSON structure and schema are well-formed.

The manifest follows the expected registry structure with complete metadata, clear tool definitions, proper input schemas with required fields, and installation instructions. All tools have appropriate descriptions and examples.

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8d60d29 and bb689aa.

📒 Files selected for processing (1)

• mcp-registry/servers/mcp-notify.json (1 hunks)

🔇 Additional comments (2)

mcp-registry/servers/mcp-notify.json (2)

41-193: Tool definitions are well-structured.

All six tools have consistent schemas with clear descriptions, appropriate required fields, and descriptive property documentation. The parameter names and types align with their respective platform conventions (e.g., msgtype for WeWork/DingTalk, parse_mode for Telegram). JSON syntax is valid.

---

195-206: Installation and metadata are correct.

The uvx installation configuration and manifest metadata (name, display_name, repository, author, license, categories) are well-defined and consistent with the MCP server registry conventions.