Skip to content

fix(mcp): use request.params.name in catch block — name is out of scope#1269

Open
memosr wants to merge 1 commit into
coinbase:mainfrom
memosr:fix/mcp-readme-undefined-name
Open

fix(mcp): use request.params.name in catch block — name is out of scope#1269
memosr wants to merge 1 commit into
coinbase:mainfrom
memosr:fix/mcp-readme-undefined-name

Conversation

@memosr
Copy link
Copy Markdown

@memosr memosr commented Jun 4, 2026

Summary

A small but real bug in the MCP framework extension's primary onboarding example. Any developer copy-pasting this code hits a ReferenceError (Node.js) or silently uses window.name (browser) when an error path triggers.

The bug

In typescript/framework-extensions/model-context-protocol/README.md, the example shows:

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;
  
  try {
    // ... tool execution
  } catch (error) {
    throw new Error(`Tool ${name} failed: ${error}`);
    //                  ^^^^ out of scope here
  }
});

The name destructured at the top of the function body lives inside the try block's scope (well, technically the function body, but the catch handler can't see destructured bindings that weren't hoisted). The catch block doesn't have a binding for name.

In a browser, name silently resolves to window.name — an unrelated string. The error message gets a useless value, not the tool name.

In Node.js (where MCP servers actually run), this throws ReferenceError: name is not defined before the intended error message is even constructed.

The fix

- throw new Error(`Tool ${name} failed: ${error}`);
+ throw new Error(`Tool ${request.params.name} failed: ${error}`);

request is the handler parameter and is in scope throughout the handler, including the catch block. This matches the access pattern used elsewhere in MCP server code.

Why it matters

This is the primary MCP onboarding example. Developers building their first MCP server with AgentKit copy this pattern. A broken error path means hard-to-debug failures the moment any tool throws.

Verification

  • ✅ Only the README.md file touched
  • ✅ One-line change
  • request.params.name is verified in scope at the catch site

The error handler at typescript/framework-extensions/model-context-protocol/
README.md:58 referenced \`${name}\` inside a catch block where \`name\` is not
defined. The function uses \`async (request) =>\` and destructures \`name\` from
\`request.params\` only at the top of the try block, so it is not accessible
from the catch.

In a browser, this silently resolves to \`window.name\` (an unrelated string).
In Node.js (where MCP servers actually run), this throws ReferenceError
before the intended error message is constructed.

Changed to \`${request.params.name}\` which is in scope throughout the
handler, matching the access pattern used everywhere else in the file.
@memosr memosr requested a review from murrlincoln as a code owner June 4, 2026 12:47
@cb-heimdall
Copy link
Copy Markdown

🟡 Heimdall Review Status

Requirement Status More Info
Reviews 🟡 0/1
Denominator calculation
Show calculation
1 if user is bot 0
1 if user is external 0
2 if repo is sensitive 0
From .codeflow.yml 1
Additional review requirements
Show calculation
Max 0
0
From CODEOWNERS 0
Global minimum 0
Max 1
1
1 if commit is unverified 1
Sum 2

@github-actions github-actions Bot added documentation Improvements or additions to documentation framework extension New framework extension labels Jun 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation framework extension New framework extension

Development

Successfully merging this pull request may close these issues.

2 participants