⚠️ Potential issue | 🔴 Critical

Fix version constraint: @langchain/mcp-adapters version 1.0.0 does not exist on npm.

The latest published version on npm registry is 0.6.0. The current constraint ^1.0.0 will fail during installation. Update to a published version (e.g., ^0.6.0 or later if available).

In core/mcp-client/package.json around line 40, the dependency version for
"@langchain/mcp-adapters" is set to "^1.0.0" which does not exist on npm; change
the version to a published release (for example "^0.6.0" or the latest
available) in the dependencies list so installations succeed, then run npm
install (or yarn) and update lockfile if present.

The use of this as any bypasses TypeScript's type checking and can hide underlying type incompatibility issues. The HttpMCPClient class extends Client, which is likely the type expected by loadMcpTools. If there is a type mismatch causing this cast to be necessary, it should be addressed directly to ensure type safety and prevent potential runtime errors. Please either fix the type incompatibility or add a comment explaining why this cast is unavoidable.

⚠️ Potential issue | 🟠 Major

#!/bin/bash
# First, find where loadMcpTools is defined and its signature
rg -n 'export.*loadMcpTools|function loadMcpTools|const loadMcpTools' --type=ts --type=tsx -A 15

#!/bin/bash
# Find all usages of getLangChainTool
rg -n 'getLangChainTool' --type=ts --type=tsx -B 2 -A 2

#!/bin/bash
# Check the HttpMCPClient class definition and see what interface it implements
rg -n 'class HttpMCPClient|interface.*HttpMCPClient' --type=ts --type=tsx -A 20

#!/bin/bash
# Look for the interface that loadMcpTools expects
rg -n 'MCPClient|MCPClientI' --type=ts --type=tsx | head -30

#!/bin/bash
# Find where loadMcpTools is defined and its signature
rg -n 'export.*loadMcpTools|function loadMcpTools|const loadMcpTools' --type=ts -A 15

#!/bin/bash
# Find all usages of getLangChainTool
rg -n 'getLangChainTool' --type=ts -B 2 -A 2

#!/bin/bash
# Check the HttpMCPClient class definition
rg -n 'class HttpMCPClient' --type=ts -A 30

#!/bin/bash
# Search for MCPClient interface definitions
rg -n 'interface.*MCPClient|type.*MCPClient' --type=ts | head -20

#!/bin/bash
# Find the loadMcpTools function definition
fd -t f -e ts . | xargs grep -l 'loadMcpTools' | head -10

#!/bin/bash
# Get the full file path and context around loadMcpTools definition
rg -n 'loadMcpTools' --type=ts -B 5 -A 20 | head -100

#!/bin/bash
# Check what Client base class HttpMCPClient extends
rg -n "from.*Client|import.*Client" core/mcp-client/src/HttpMCPClient.ts

#!/bin/bash
# Check the return value of loadMcpTools in the usage
cat core/mcp-client/src/HttpMCPClient.ts | head -130 | tail -20

#!/bin/bash
# Check package.json to see the version of @langchain/mcp-adapters
find . -name "package.json" -type f | xargs grep -l "mcp-adapters" 2>/dev/null

#!/bin/bash
# Look at the actual usage in test files to understand the return type better
cat plugin/mcp-client/test/fixtures/apps/mcpclient/app/modules/bar/controller/AppController.ts | head -80 | tail -20

#!/bin/bash
# Check if there are any type definitions or imports related to MCPClient interface
rg -n "MCPClient|interface.*Client" --type=ts core/mcp-client/src/ -A 5 | head -50

#!/bin/bash
# Verify the complete file at HttpMCPClient.ts to ensure we see the full context
wc -l core/mcp-client/src/HttpMCPClient.ts

#!/bin/bash
# Check if there are any other callers of getLangChainTool besides the one in AppController
rg -n 'getLangChainTool' --type=ts

Rename method and remove type bypass to improve naming consistency and type safety.

Three issues need to be addressed:

1. Naming inconsistency: Method is named getLangChainTool (singular) but returns an array of tools, confirmed by the test usage that calls .length and .map() on the result. Rename to getLangChainTools.

2. Type safety bypass: Line 120 uses this as any, circumventing TypeScript's type checking. Remove the cast to rely on proper type compatibility.

3. Missing documentation: Add JSDoc to explain the return type and behavior.

The method has one caller in plugin/mcp-client/test/fixtures/apps/mcpclient/app/modules/bar/controller/AppController.ts:72 that will need updating when renamed.

In core/mcp-client/src/HttpMCPClient.ts around lines 119 to 125, rename the
method from getLangChainTool to getLangChainTools (plural) because it returns an
array of tools, remove the unsafe cast "this as any" so the call uses the proper
typed this (adjust the HttpMCPClient/loader types if necessary to satisfy
TypeScript), and add a concise JSDoc above the method describing that it returns
Promise<Array<...>> of loaded MCP tools and the options used; also update the
sole caller at
plugin/mcp-client/test/fixtures/apps/mcpclient/app/modules/bar/controller/AppController.ts:72
to call getLangChainTools().

The import from zod/v4 is highly unusual. The latest major version of the public zod package is v3, and it does not provide a v4 entry point. While the package.json specifies "zod": "^4.0.0", this version does not exist on the public npm registry, suggesting a private fork or a typo. This can cause confusion and build issues for other developers. Please change the import to import * as z from 'zod'; and adjust the dependency version if this is a mistake. If it's intentional, please add a comment explaining the reason for this specific import path.

The expression (toolsObj.proto as unknown as EggPrototypeWithClazz).clazz! is repeated and uses multiple unsafe type assertions (as unknown as, !). This reduces code readability and introduces a risk of runtime errors if clazz is not present on the prototype. It would be safer and clearer to extract the class into a variable with a proper null check before using it.

        const toolClazz = (toolsObj.proto as EggPrototypeWithClazz).clazz;
        if (!toolClazz) {
          throw new Error(`Could not find class for prototype '${toolsObj.proto.name}'`);
        }
        const toolMetadata = GraphToolInfoUtil.getGraphToolMetadata(toolClazz);
        const ToolDetail = MCPInfoUtil.getMCPToolArgsIndex(toolClazz, 'execute');

⚠️ Potential issue | 🟡 Minor

Inconsistent property access: toolMeta.name vs toolMeta.toolName.

Based on the IGraphToolMetadata interface (from the relevant code snippets), the property is toolName, not name. Lines 71 and 75 use toolMeta.name which may be undefined or incorrect.

         } else {
-          throw new Error(`graph tool ${toolMeta.name ?? clazz.name} not found`);
+          throw new Error(`graph tool ${toolMeta.toolName ?? clazz.name} not found`);
         }
       }
     }
-    SingletonProto({ name: `structured${toolMeta.name ?? clazz.name}`, accessLevel: AccessLevel.PUBLIC })(StructuredTool);
+    SingletonProto({ name: `structured${toolMeta.toolName ?? clazz.name}`, accessLevel: AccessLevel.PUBLIC })(StructuredTool);
     return StructuredTool;

In plugin/langchain/lib/graph/GraphLoadUnitHook.ts around lines 55 to 77, the
code inconsistently accesses toolMeta.name but the IGraphToolMetadata uses
toolName; replace both occurrences of toolMeta.name with toolMeta.toolName
(keeping the existing fallback to clazz.name) so the error message and
SingletonProto name use the correct metadata property.