What causes "invalid method %s" in googleapis/mcp-toolbox?

METHOD_NOT_FOUND

METHOD_NOT_FOUND

Error message

invalid method %s

What it means

ProcessMethod dispatches incoming MCP JSON-RPC requests by method name. This METHOD_NOT_FOUND error is returned when the method string does not match any handler for the 2025-03-26 protocol version (initialize, tools/list, tools/call, prompts/list, prompts/get, etc.), usually meaning the client sent a method this server version does not implement.

Source

Thrown at internal/server/mcp/v20250326/method.go:57

)

// ProcessMethod returns a response for the request.
func ProcessMethod(ctx context.Context, id jsonrpc.RequestId, method string, g group.Group, primitiveMgr *primitives.PrimitiveManager, body []byte, header http.Header) (any, error) {
	switch method {
	case INITIALIZE:
		return initializeHandler(ctx, id, body)
	case PING:
		return pingHandler(id)
	case TOOLS_LIST:
		return toolsListHandler(ctx, id, primitiveMgr, g, body)
	case TOOLS_CALL:
		return toolsCallHandler(ctx, id, g, primitiveMgr, body, header)
	case PROMPTS_LIST:
		return promptsListHandler(ctx, id, primitiveMgr, g, body)
	case PROMPTS_GET:
		return promptsGetHandler(ctx, id, g, primitiveMgr, body)
	default:
		err := fmt.Errorf("invalid method %s", method)
		return jsonrpc.NewError(id, jsonrpc.METHOD_NOT_FOUND, err.Error(), nil), err
	}
}

// InitializeResponse runs capability negotiation and protocol version agreement.
// This is the Initialization phase of the lifecycle for MCP client-server connections.
// Always start with the latest protocol version supported.
func initializeHandler(ctx context.Context, id jsonrpc.RequestId, body []byte) (any, error) {
	v, err := util.ToolboxVersionFromContext(ctx)
	if err != nil {
		return jsonrpc.NewError(id, jsonrpc.INTERNAL_ERROR, err.Error(), nil), err
	}

	var req InitializeRequest
	if err := json.Unmarshal(body, &req); err != nil {
		err = fmt.Errorf("invalid mcp initialize request: %w", err)
		return jsonrpc.NewError(id, jsonrpc.INVALID_REQUEST, err.Error(), nil), err
	}

View on GitHub (pinned to 8cc6e09de2)

Solutions

Use a supported method name: initialize, tools/list, tools/call, prompts/list, prompts/get (plus notifications the version allows)
Negotiate the correct protocolVersion in the initialize request so requests route to the right handler
Check client spelling/casing of the method string
Upgrade the server if the method requires a newer MCP protocol version

Example fix

// before
{"jsonrpc":"2.0","id":1,"method":"tools/listAll"}
// after
{"jsonrpc":"2.0","id":1,"method":"tools/list"}

Defensive patterns

Strategy: validation

Validate before calling

const supported = ["initialize","notifications/initialized","tools/list","tools/call","prompts/list","prompts/get"]
if !supported.includes(request.method) {
    throw new Error(`method ${request.method} not supported by this server version`)
}

Prevention

Pin the client to the negotiated protocolVersion and use only its methods
Check the server version's supported method list before calling new methods
Handle METHOD_NOT_FOUND by falling back to older method names where possible

When it happens

Trigger: A JSON-RPC request whose method field is misspelled, unsupported (e.g. resources/list, logging/setLevel), or belongs to a newer MCP protocol version routed to the v20250326 handler.

Common situations: MCP clients negotiating an older protocol version then calling newer-version methods; typos in custom client code; clients assuming features (resources, sampling) the server doesn't support.

Related errors

AI-assisted analysis of googleapis/mcp-toolbox@8cc6e09de2 (2026-09-05). Data as JSON: /api/errors/bcb97b747849e591. Report an issue: GitHub.