It seems there isn't validation around tool names. Certain invalid names can cause LLMs to fail.

Expected Behavior Some type of @Tool annotation value validation is done to preemptively catch problems

Current Behavior An invalid tool name (such as having a space in the name) is permitted

Context

An invalid tool name (such as having a space in the name) causes the LLM to fail (GPT 4.1-mini in this case).

Expected a string that matches the pattern '^[a-zA-Z0-9_\.-]+$'."

Comment From: sunyuhan1998

This is indeed an issue, but here's the thing: perhaps different models have varying requirements and constraints regarding tool names. Should we perform uniform, standardized validation of tool names when creating the tools, or should we conduct the actual validation based on each model's specific requirements at execution time? @ilayaperumalg What's your opinion?

Comment From: CodeCodeAscension

Note: I'm a sophomore intern. Through my work, I've come into contact with Spring AI, and I really love knowledge in this field. During my learning process, I got to know the open-source community, and I'm really looking forward to and enjoying discussing with everyone. I hope my ideas can be helpful to everyone.

Regarding the unification of tool names and validation based on personalized requirements, I prefer validating according to the personalized requirements of different models. However, both methods seem to have restrictions on users. Maybe we can unify these personalizations through a layer of "mapping" like MCP. For example, we can implement a processor to correct unexpected naming. Take the example given by the original poster: if a name containing spaces is invalid for GPT 4.1-mini, can this processor make corrections at the underlying level so that users can name freely without being relatively aware of it? (My English is not good, and this is translated into English, so maybe the words don't convey the exact meaning. But my tone is happy and modest. I'm really happy because this is my first comment!)

Comment From: sunyuhan1998

For example, we can implement a processor to correct unexpected naming. Take the example given by the original poster: if a name containing spaces is invalid for GPT 4.1-mini, can this processor make corrections at the underlying level so that users can name freely without being relatively aware of it?

You're absolutely right; this is certainly one possible approach. However, I feel that implicitly modifying user-defined tool names might not be appropriate, as such implicit changes could potentially alter the semantics of the tool names in certain special scenarios.

In fact, I've looked into the implementations of several official SDKs for LLMs, and most of them don't perform tool name validation on the SDK side at all. Instead, they rely on checks performed by the server. Therefore, I'm thinking whether we should only perform some basic validation on the client side—such as disallowing spaces in tool names, which seems to be a common rule across most LLMs—and then, based on exceptions returned by the server, provide users with a clear message like "Invalid tool name", along with the detailed error information from the server.

This approach seems to be a reasonable middle ground.

Comment From: CodeCodeAscension

For example, we can implement a processor to correct unexpected naming. Take the example given by the original poster: if a name containing spaces is invalid for GPT 4.1-mini, can this processor make corrections at the underlying level so that users can name freely without being relatively aware of it?

You're absolutely right; this is certainly one possible approach. However, I feel that implicitly modifying user-defined tool names might not be appropriate, as such implicit changes could potentially alter the semantics of the tool names in certain special scenarios.

In fact, I've looked into the implementations of several official SDKs for LLMs, and most of them don't perform tool name validation on the SDK side at all. Instead, they rely on checks performed by the server. Therefore, I'm thinking whether we should only perform some basic validation on the client side—such as disallowing spaces in tool names, which seems to be a common rule across most LLMs—and then, based on exceptions returned by the server, provide users with a clear message like "Invalid tool name", along with the detailed error information from the server.

This approach seems to be a reasonable middle ground.

I think what you said makes sense. Validating upfront can indeed improve the user experience. Perhaps we can further establish a conventional naming convention for tools, similar to camelCase naming. This might further enhance development standards in another aspect. However, I'm not sure if naming conventions like the underscore naming in MySQL are equally applicable to the naming conventions for our tools.