spring-projects/spring-ai · error

Method must not be null

Error message

Method must not be null

What it means

AbstractMcpToolListChangedMethodCallback.validateMethod rejects a null java.lang.reflect.Method before checking its signature. The callback cannot dispatch tool-list-changed notifications without a reflective Method target, so the library fails fast during construction/validation rather than at notification time.

Source

Thrown at mcp/mcp-annotations/src/main/java/org/springframework/ai/mcp/annotation/method/changed/tool/AbstractMcpToolListChangedMethodCallback.java:68

		Assert.notNull(bean, "Bean can't be null!");

		this.method = method;
		this.bean = bean;
		this.validateMethod(this.method);
	}

	/**
	 * Validates that the method signature is compatible with the tool list changed
	 * consumer callback.
	 * <p>
	 * This method checks that the return type is valid and that the parameters match the
	 * expected pattern.
	 * @param method The method to validate
	 * @throws IllegalArgumentException if the method signature is not compatible
	 */
	protected void validateMethod(Method method) {
		if (method == null) {
			throw new IllegalArgumentException("Method must not be null");
		}

		this.validateReturnType(method);
		this.validateParameters(method);
	}

	/**
	 * Validates that the method return type is compatible with the tool list changed
	 * consumer callback. This method should be implemented by subclasses to handle
	 * specific return type validation.
	 * @param method The method to validate
	 * @throws IllegalArgumentException if the return type is not compatible
	 */
	protected abstract void validateReturnType(Method method);

	/**
	 * Validates method parameters. This method provides common validation logic.
	 * @param method The method to validate

View on GitHub (pinned to 98a7beda4f)

Solutions

  1. Ensure the Method passed to the callback or builder is non-null before construction: this.getClass().getDeclaredMethod("handlerName", List.class)
  2. Fix the method lookup — verify the handler method name and parameter types (exactly one List<McpSchema.Tool>) match the bean class
  3. If using the builder, call .method(m) with a resolved Method before .build(); check that the reflection lookup did not swallow a NoSuchMethodException

Example fix

// before
Method m = beanClass.getMethod("onToolListChanged"); // throws NoSuchMethodException, m may be unset
builder.method(m).build();
// after
Method m;
try { m = beanClass.getMethod("onToolListChanged", List.class); }
catch (NoSuchMethodException e) { throw new IllegalStateException("Handler method missing", e); }
builder.method(m).build();
Defensive patterns

Strategy: validation

Validate before calling

java.util.Objects.requireNonNull(method, "method must be resolved before building the callback");

Type guard

static boolean methodResolved(java.lang.reflect.Method m) { return m != null; }

Try / catch

try { builder.method(method).build(); } catch (IllegalArgumentException e) { log.error("Callback validation failed: {}", e.getMessage()); }

Prevention

When it happens

Trigger: Building an AbstractMcpToolListChangedMethodCallback (or subclass, e.g. via the builder or the AbstractMcpPromptListChangedMethodCallback reuse path) with method = null, or calling validateMethod(null) directly from subclass code.

Common situations: Reflection failures upstream — e.g. Class.getMethod/getDeclaredMethod throwing NoSuchMethodException being swallowed and null propagated, bean classes that lost the handler method after a rename/refactor, or builder code assembling the callback before resolving the method.

Related errors


AI-assisted analysis of spring-projects/spring-ai@98a7beda4f (2026-09-11). Data as JSON: /api/errors/8467ce334c7cef65. Report an issue: GitHub.