chore(mcp): trim comments to match codebase density

Author: waleedlatif1

apps/sim/lib/mcp/client.ts

@@ -105,10 +105,7 @@ export class McpClient {
       }
     )
 
-    // The SDK invokes onerror for out-of-band transport failures (SSE
-    // disconnects, exhausted reconnects) that are not tied to an in-flight
-    // request. Without a handler these are silently dropped, so wire one for
-    // observability. See @modelcontextprotocol/sdk Protocol.onerror.
+    // Observe out-of-band transport errors the SDK would otherwise drop silently.
     this.client.onerror = (error) => {
       logger.warn(`MCP transport error for ${this.config.name}`, {
         serverId: this.config.id,
@@ -242,10 +239,7 @@ export class McpClient {
 
     try {
       const result: ListToolsResult = await this.client.listTools(undefined, {
-        // `timeout` bounds silence between progress notifications; `maxTotalTimeout`
-        // is the hard ceiling regardless of progress. `resetTimeoutOnProgress` only
-        // takes effect when an `onprogress` callback is supplied (the SDK sets the
-        // request progressToken only then), so both are passed together.
+        // resetTimeoutOnProgress only takes effect when onprogress is supplied.
         timeout: idleTimeoutMs,
         maxTotalTimeout: maxTotalTimeoutMs,
         resetTimeoutOnProgress: true,

apps/sim/lib/mcp/service.ts

@@ -100,23 +100,14 @@ function isTimeoutError(error: unknown): boolean {
   return getErrorMessage(error, '').toLowerCase().includes('timed out')
 }
 
-/**
- * Transient transport failures that a read-only `tools/list` may safely retry.
- * `tools/list` is idempotent, so re-issuing it after a timeout, dropped
- * connection, or 5xx/429 cannot double-apply side effects — unlike `tools/call`,
- * which is never retried on these. OAuth-authorization and terminal 4xx errors
- * are intentionally excluded: they need re-auth or a config fix, not a retry.
- * The MCP TypeScript SDK does not retry POST requests itself (only SSE streams),
- * so the app owns this.
- */
+/** Transient failures a read-only `tools/list` may safely retry (idempotent, unlike `tools/call`); excludes OAuth and terminal 4xx. */
 function isRetryableDiscoveryError(error: unknown): boolean {
   if (isTimeoutError(error)) return true
   if (error instanceof McpError) {
     return error.code === ErrorCode.ConnectionClosed
   }
   if (error instanceof StreamableHTTPError) {
-    // 404/400 = stale/malformed session id: retrying rebuilds the client with no
-    // session id, which re-initializes per MCP spec. 429/5xx = transient upstream.
+    // 404/400 = stale session (retry re-initializes); 429/5xx = transient upstream.
     const code = error.code
     return (
       code === 404 ||

apps/sim/lib/mcp/utils.ts

@@ -51,19 +51,9 @@ export function sanitizeHeaders(
 export const MCP_CLIENT_CONSTANTS = {
   CLIENT_TIMEOUT: DEFAULT_EXECUTION_TIMEOUT_MS,
   AUTO_REFRESH_INTERVAL: 5 * 60 * 1000,
-  /**
-   * Idle timeout for a `tools/list` request. Raised from the former aggressive
-   * 10s toward the MCP TypeScript SDK's 60s default (`DEFAULT_REQUEST_TIMEOUT_MSEC`)
-   * so a legitimately slow-to-enumerate server is not spuriously failed with
-   * `McpError -32001`. Combined with `resetTimeoutOnProgress`, this is the gap
-   * allowed between progress notifications, not the absolute ceiling.
-   */
+  /** Idle timeout for tools/list (gap between progress events); raised from 10s toward the SDK's 60s default. */
   LIST_TOOLS_TIMEOUT_MS: 30_000,
-  /**
-   * Absolute ceiling for a `tools/list` request regardless of progress, mirroring
-   * the SDK's `maxTotalTimeout` safeguard. Matches the SDK's 60s default so a
-   * server emitting continuous progress still cannot hang discovery indefinitely.
-   */
+  /** Hard ceiling for tools/list regardless of progress (SDK maxTotalTimeout safeguard). */
   LIST_TOOLS_MAX_TOTAL_TIMEOUT_MS: 60_000,
   FAILURE_CACHE_TTL_MS: 120_000,
 } as const