What this PR does

Before this PR:

1. The project used an outdated @modelcontextprotocol/sdk version that had security vulnerabilities (GHSA-8r9q-7v3j-jr4g).
2. In MCPService.ts, the code incorrectly accessed params.message field which did not exist in the type definition. The old SDK used looseObject type, so no TypeScript error was raised.
3. The serialize.ts utility was only available in the renderer process and could not be used in the main process (Node.js).

After this PR:

1. Upgraded @modelcontextprotocol/sdk from an older version to 1.27.1 to resolve the security vulnerability.
2. Fixed the incorrect implementation in MCPService.ts by using the data field instead of message to get the log message, following the official MCP specification: https://modelcontextprotocol.io/specification/2025-11-25/server/utilities/logging#log-message-notifications
3. Moved the serialize utility from src/renderer/src/utils/ to packages/shared/utils/ so it can be used by both main and renderer processes.

Refactoring:

• Previously, the packages/shared package only contained a single utils.ts file.
• To add serialize.ts to the shared package, the existing utils.ts was migrated to packages/shared/utils/index.ts.
• The new serialize.ts was added to packages/shared/utils/serialize.ts.

Fixes #

Why we need it and why it was done in this way

The following tradeoffs were made:

1. Security fix: The MCP SDK upgrade was necessary to address GHSA-8r9q-7v3j-jr4g.
2. Type safety: The new SDK type definitions are stricter (no longer looseObject), which exposed the existing bug where params.message was incorrectly used. This is now fixed by using the data field as per the official spec.
3. Code sharing: To safely convert the unknown type data field to string, the serialize utility needed to be accessible from both main and renderer processes. The utility was moved to the shared package since its functions (using only standard JavaScript/TypeScript features like JSON.stringify) are compatible with both Node.js and browser environments.

The following alternatives were considered:

• Keep using message field: Not viable as it doesn't exist in the new SDK types and the official spec recommends using data field.
• Duplicate the serialize logic in main process: Would lead to code duplication and maintenance burden.

Links to places where the discussion took place:

Breaking changes

• Runtime behavior change: MCP log messages now use the data field instead of message. A small number of older MCP servers that use the non-standard message field for log information will no longer be supported. However, this is the correct behavior according to the official MCP specification, so this change is considered a bug fix rather than a breaking change.

Special notes for your reviewer

• Line 701 in MCPService.ts uses as to bypass TypeScript type checking. After manual review, the types do not match correctly. A FIXME comment has been added to indicate this needs future attention, as the exact type mapping is still being determined.

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.

Release note

Security: Upgraded @modelcontextprotocol/sdk to 1.27.1 to fix security vulnerability (GHSA-8r9q-7v3j-jr4g)
Fix: Fixed MCP server log message handling to use the standard `data` field instead of non-standard `message` field per MCP specification