Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.changeset/move-mcp-to-package.md:
- Line 9: Update the release note to fix the typo: replace the word "toolst"
with "tools" in the text that currently reads "Extract MCP server and toolst to
`@likec4/mcp` package." so the sentence becomes "Extract MCP server and tools to
`@likec4/mcp` package."
- Around line 3-4: The changeset currently marks '@likec4/language-server' and
'@likec4/language-services' as 'patch' but removing MCP APIs is a breaking
change; update the entries in the .changeset/move-mcp-to-package.md file so both
package lines use a breaking bump (e.g., replace 'patch' with 'major' for
'@likec4/language-server' and '@likec4/language-services') to ensure a breaking
release is published.

In `@packages/mcp/build.config.ts`:
- Around line 4-9: The package is published without type declarations; enable
declaration generation and point package.json at the emitted .d.ts so consumers
can use startLikeC4MCP/initLikeC4MCP. In build.config.ts set dts: true for the
entry that builds ./src/index.ts (the entries array with type 'bundle' and input
['./src/cli.ts','./src/index.ts']), then add a "types": "./dist/index.d.ts"
field to package.json (or alternatively add a separate declaration-emission step
that uses your tsconfig with emitDeclarationOnly and includes the lib/ files) so
the dist .d.ts files are produced and referenced.

In `@packages/mcp/src/cli.ts`:
- Around line 59-80: The local process.on('uncaughtException', ...) and
process.on('unhandledRejection', ...) handlers are being registered twice
because startLikeC4MCP({ ..., configureLogger: true }) also attaches them;
remove the duplication by either deleting the two local handlers or by setting
configureLogger: false when calling startLikeC4MCP if you want to keep the local
handlers — update the code around the process.on(...) blocks and the
startLikeC4MCP call accordingly, referring to the process.on handlers and the
startLikeC4MCP(...) configureLogger option to ensure handlers are only
registered once.
- Around line 24-29: The CLI currently allows invalid --port values; add
validation inside the setup() function to parse the provided port option
(referencing the port option in the CLI config) as an integer only if the string
is all digits (e.g. /^\d+$/), convert to Number/parseInt, and ensure the
resulting integer is between 1 and 65535; if the value is invalid, reject it
immediately by throwing an Error or exiting with a clear message (e.g. "Invalid
--port: must be integer 1-65535") so startup does not continue with NaN or
partial parses.

In `@packages/mcp/src/index.ts`:
- Around line 41-45: The FromWorkspaceOptions flag throwIfInvalid is declared
but not forwarded to the workspace loader; update the call to fromWorkspace(...)
in packages/mcp/src/index.ts (the invocation that currently builds workspace
options) to include throwIfInvalid: opts.throwIfInvalid (or opts.throwIfInvalid
?? false) so the workspace loader receives the caller's strict validation
preference; ensure the option name matches the
FromWorkspaceOptions/throwIfInvalid symbol and is passed into the
fromWorkspace(...) call where other opts fields are forwarded.

In `@packages/mcp/src/tools/mcp-server-links.int.spec.ts`:
- Around line 9-12: The test currently only calls readElement and readDeployment
directly; change it to exercise the MCP server path by instantiating the test
services with createTestServices, registering or loading the tools, then
resolving the tool via the MCP server/name-based lookup and invoking it through
that interface (instead of or in addition to calling readElement/readDeployment
directly). Specifically, use createTestServices to bring up the MCP server, use
the server's registration/lookup API to find the tool by its registered name
(the same name the real wiring uses), then call the resolved tool and assert
results—ensuring the integration path (MCP registration + name lookup + tool
invocation) is covered in the .int.spec.ts.

---

Outside diff comments:
In `@packages/mcp/package.json`:
- Around line 61-79: The package.json currently lists many runtime packages
under devDependencies (see the "devDependencies" block and entries like "hono",
"langium", "citty", "remeda", "vscode-uri", "@hono/mcp", "@hono/node-server",
"@modelcontextprotocol/sdk", "defu", "tinyrainbow", "zod", etc.); move all
externally required runtime packages into the "dependencies" section so they are
installed when this package is consumed standalone, while leaving internal
workspace packages (the "@likec4/*" entries) in devDependencies if they are
bundled by the build. Ensure the package.json "dependencies" object contains
those external package names and remove them from "devDependencies" to prevent
runtime module-not-found errors.

---

Nitpick comments:
In `@packages/mcp/src/server/StdioLikeC4MCPServer.ts`:
- Around line 8-14: Extract the LikeC4MCPServer interface from
StdioLikeC4MCPServer into a new dedicated module (e.g., likeC4MCPServer.ts),
export it as a named type, then update all implementations to import that shared
type instead of redeclaring it; specifically modify StdioLikeC4MCPServer (remove
the inline interface and import LikeC4MCPServer) and StreamableLikeC4MCPServer
(replace the local reference with an import), and run TypeScript checks to
ensure start, stop, mcp, isStarted and port signatures remain consistent across
consumers.

In `@packages/mcp/src/tools/_common.ts`:
- Around line 251-255: The schema projectIdSchema currently hardcodes a default
('default' as ProjectId), creating a second source of truth; remove the
.default(...) so the schema remains optional and does not inject a default
value, i.e., keep z.string().refine(...).optional().describe(...), and rely on
ensureProjectId (and ProjectsManager) to resolve the actual default/aliases at
runtime instead of the schema.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@packages/mcp/src/cli.ts`:
- Around line 51-55: The CLI accepts --port without strict validation and later
uses parseInt (parseInt(...)) so inputs like "12abc" or "foo" can produce
invalid numbers that flow into the mcp transport config (mcp: { port }). Update
the setup({ args }) function to strictly validate args.port: if args.port is
provided, ensure it's composed only of digits and within 1–65535, then parse
with Number.parseInt(args.port, 10) (or Number) and assign the validated numeric
port to the config; otherwise throw a clear Error for invalid --port values so
an invalid string never reaches mcp: { port }.