Is there interest in generating ToolOptions from struct tags/annotations?

[WhiskeyJack96]

I've got a helper function I use to generate the mcp config based on struct tags (mcp in this case) that I'd be happy to PR if theres interest! This works well for simple tools (though if multiline comments/descriptions are needed it doesnt work as well in that you still need to provide additional Tool options or have really long struct tags).

Below is the rough proposal for what the api might look like (slight tweaks from my helper library to generalize to the package name/match local style):

Given a struct like:

type GreetingArgs struct {
	Name      string   `json:"name" mcp:"required:true,description:name of the person to greet"`
	Age       int      `json:"age" mcp:"description:Age of the person,maximum:150,minimum:0"`
	IsVIP     bool     `json:"is_vip" mcp:"description:Whether the person is vip,default:false"`
	Languages []string `json:"languages" mcp:"description:languages of the person to greet"`
	Metadata  struct {
		Location string `json:"location" mcp:"description:Current location"`
		Timezone string `json:"timezone" mcp:"description:Timezone"`
	} `json:"metadata" mcp:"description:Additional information about the person"`
}

registration might look like

var s *MCPServer
server.AddTypedTool(s, "greeting", typedGreetingHandler, mcp.WithDescription("Generate a personalized greeting"))

Which under the hood would be invoking some reflection magic to grab/parse the tags into the appropriate json schema

func NewToolT[T any](name string, opts ...ToolOption) Tool {
	t := reflect.TypeFor[T]()
	return NewTool(name, append([]ToolOption{TypeToToolOption(t)}, opts...)...)
}
func TypeToToolOption(t reflect.Type) ToolOption {
	props, required := typeToProps(t)
	return func(tool *Tool) {
		tool.InputSchema.Properties = props
		tool.InputSchema.Required = required
	}
}
func typeToProps(t reflect.Type) (map[string]any, []string) {
	properties := make(map[string]any)
	var required []string
	for i := 0; i < t.NumField(); i++ {
		field := t.Field(i)
		if !field.IsExported() {
			continue
		}
		fn := field.Tag.Get("json")
		if fn == "" {
			fn = field.Name
		}

		fieldType := ""
		kind := field.Type.Kind()
		if kind == reflect.Pointer {
			kind = field.Type.Elem().Kind()
		}
		schema := map[string]any{}
		mcpConfiguration := field.Tag.Get("mcp")
		for config := range strings.SplitSeq(mcpConfiguration, ",") {
			k, v, ok := strings.Cut(config, ":")
			if k == "required" {
				required = append(required, fn)
				continue
			}
			if ok {
				schema[k] = v
			}
		}
		switch kind {
		case reflect.String:
			fieldType = "string"
		case reflect.Bool:
			fieldType = "bool"
		case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64, reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Float32, reflect.Float64:
			fieldType = "number"
		case reflect.Slice, reflect.Array:
			fieldType = "array"
			elemType := ""
			switch field.Type.Elem().Kind() {
			case reflect.String:
				elemType = "string"
			case reflect.Bool:
				elemType = "bool"
			case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64, reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Float32, reflect.Float64:
				elemType = "number"
			}
			if elemType != "" {
				schema["items"] = map[string]any{"type": elemType}
			}
		case reflect.Struct:
			fieldType = "object"
			objProp, _ := typeToProps(field.Type)
			schema["properties"] = objProp
		default:
			fmt.Printf("type %s not supported \n", kind)
		}

		schema["type"] = fieldType
		properties[fn] = schema
	}
	return properties, required
}

[pottekkat]

I'm not sure if it is the job of the SDK to provide this level of abstraction. I think it is better to implement something like this for the specific MCP server implementation. I maintain an MCP server where I have something like this to automatically read a JSON file and convert it to tool properties. It is very opinionated parsing from JSON to tool options to be extracted into an SDK. I think the fact that you have easily do this with Go standard libraries and the mcp-go SDK is good enough.

Unless you or others have strong reasons why this might be useful in general.

Also TBH given the velocity at which this project is being developed and the MCP spec is being improved, this would be a very low priority feature with priority being given to spec compliance and bug fixes and developer experience.