refactor: remove console logs and simplify error handling in examples…

[syucream]

… and server code

[Copilot]

Pull Request Overview

The pull request refactors logging and error handling by removing console output and type-specific arguments from server startup and example scripts.

• Eliminates informational console.log calls in src/index.ts for cleaner output.
• Removes logging, schema imports, and explicit result handling in both HTTP and Stdio example scripts.
• Simplifies error handling in examples by replacing try/catch with try/finally.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/index.ts	Removed startup and fallback console.log statements
examples/list_spaces_http.ts	Stripped out logging, type imports, and schema parameter for calls
examples/list_spaces.ts	Stripped out logging, type imports, and schema parameter for calls

Comments suppressed due to low confidence (9)

src/index.ts:31

• Removing these console.log statements reduces visibility into server startup. Consider using a configurable logging framework or retaining debug-level logs to preserve observability.

console.log(`[INFO] Starting HTTP mode on port: ${httpPort}`);

examples/list_spaces_http.ts:43

• [nitpick] The example no longer logs connection status, which can make it unclear when the client is ready. Consider reintroducing a simple log or an explanatory comment.

console.log('Connected to MCP server via HTTP');

examples/list_spaces_http.ts:45

• The toolsResponse is no longer captured or used, limiting example clarity. Reintroduce capturing the response or document how to consume its data.

const toolsResponse = await client.listTools();

examples/list_spaces_http.ts:41

• The example removes the catch block, so errors will go unhandled. It’s better to add error handling to log failures and exit gracefully in demos.

try {

examples/list_spaces.ts:57

• [nitpick] With this log removed, readers won't know when the client is connected. Consider adding a log or comment to indicate readiness.

console.log('Connected to MCP server');

examples/list_spaces.ts:59

• The example no longer captures the listTools response, which reduces clarity on how to handle the returned tool list. Reintroduce capturing or document the expected usage.

const toolsResponse = await client.listTools();

examples/list_spaces.ts:55

• Example now lacks a catch block for errors, leading to potential unhandled promise rejections. Adding a catch to log errors would improve robustness.

try {

examples/list_spaces_http.ts:56

• The callTool invocation no longer passes the result schema, which may lead to untyped or unexpected responses. Consider supplying CallToolResultSchema for validation and typing.

await client.callTool({

examples/list_spaces.ts:70

• Similar to the HTTP example, the schema argument was removed from callTool. Consider passing CallToolResultSchema to maintain type safety and response validation.

await client.callTool({