feat: openai custom tool

[seefs001]

fix #2144

Summary by CodeRabbit

• New Features
  • Added support for custom tool types, enabling flexible tool call configurations alongside traditional function-based tools.

[coderabbitai]

Walkthrough

Added support for OpenAI's custom tool type in the Chat Completion API by introducing a CustomType constant and a new optional Custom field to the ToolCallRequest struct, while making the existing Function field optional.

Changes

Cohort / File(s)	Change Summary
DTO Struct Enhancement dto/openai_request.go	Added CustomType constant with value "custom"; modified ToolCallRequest struct to include optional Custom field of type json.RawMessage; updated Function field tag to include omitempty flag for optional serialization

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• No complex logic; straightforward data model modifications
• Addition of a single constant and one optional struct field
• Changes align directly with OpenAI API specification for custom tools

Poem

🐰 A custom tool hops into our code today,
Constants and fields now pave the way,
Optional functions, omitempty and true,
New tools arrive—so much more we can do! ✨

Pre-merge checks and finishing touches

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title 'feat: openai custom tool' clearly summarizes the main change of adding support for OpenAI's custom tool type in the Chat Completion API. The title is concise, follows conventional commit format, and directly relates to the primary objective outlined in the linked issue #2144.
Linked Issues check	✅ Passed	The pull request successfully implements the requirements from issue #2144. The changes add support for the OpenAI custom tool type by introducing a CustomType constant and modifying the ToolCallRequest struct to include a new Custom field for custom tool data. The implementation aligns with OpenAI's documentation by making the Function field optional and adding the custom tool handling capability.
Out of Scope Changes check	✅ Passed	All changes in the pull request are directly related to the stated objective of adding custom tool support to the Chat Completion API. The modifications to dto/openai_request.go (adding CustomType constant and updating ToolCallRequest struct) are minimal and scoped precisely to enable custom tool functionality as required by issue #2144.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

dto/openai_request.go (1)

186-201: Update token counting logic to handle custom tools.

The token counting logic doesn't account for the new custom tool type. Currently, it unconditionally accesses tool.Function fields for all tools, which means:

• Custom tools (with empty Function fields) will add empty strings to the token count
• The Custom field content is completely ignored, potentially leading to inaccurate token counts and billing

Apply this diff to properly handle custom tools in token counting:

 	if r.Tools != nil {
 		openaiTools := r.Tools
 		for _, tool := range openaiTools {
 			tokenCountMeta.ToolsCount++
-			texts = append(texts, tool.Function.Name)
-			if tool.Function.Description != "" {
-				texts = append(texts, tool.Function.Description)
-			}
-			if tool.Function.Parameters != nil {
-				texts = append(texts, fmt.Sprintf("%v", tool.Function.Parameters))
+			if tool.Type == CustomType {
+				// Include custom tool data in token counting
+				if tool.Custom != nil {
+					texts = append(texts, string(tool.Custom))
+				}
+			} else {
+				// Handle function tools
+				texts = append(texts, tool.Function.Name)
+				if tool.Function.Description != "" {
+					texts = append(texts, tool.Function.Description)
+				}
+				if tool.Function.Parameters != nil {
+					texts = append(texts, fmt.Sprintf("%v", tool.Function.Parameters))
+				}
 			}
 		}
-		//toolTokens := CountTokenInput(countStr, request.Model)
-		//tkm += 8
-		//tkm += toolTokens
 	}

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 00782aa and 7028ade.

📒 Files selected for processing (1)

• dto/openai_request.go (1 hunks)

🔇 Additional comments (1)

dto/openai_request.go (1)

235-235: LGTM! Consider using this constant for validation.

The constant declaration follows Go conventions and provides a clear reference for the custom tool type. Consider using this constant in validation logic to ensure type safety when checking tool types.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

Add validation to ensure proper field population based on Type.

The struct changes correctly support both function and custom tools, but there's no validation to ensure:

• When Type is "function", Function should be populated
• When Type is "custom", Custom should be populated
• Invalid combinations are rejected

Consider adding a validation method to ToolCallRequest to enforce these constraints and prevent malformed requests.

Example validation method you could add after the struct definition:

// Validate checks that the tool call request is properly formed
func (t *ToolCallRequest) Validate() error {
	if t.Type == CustomType {
		if t.Custom == nil {
			return fmt.Errorf("custom tool requires 'custom' field")
		}
	} else if t.Type == "function" {
		if t.Function.Name == "" {
			return fmt.Errorf("function tool requires 'function' field with name")
		}
	}
	return nil
}

🤖 Prompt for AI Agents

In dto/openai_request.go around lines 237-242, the ToolCallRequest struct lacks
validation for Type-specific fields; add a Validate() error method that
enforces: when Type == "custom" ensure Custom is non-nil and not empty
(len(Custom)>0), when Type == "function" ensure Function is populated (e.g.,
Function.Name != ""), otherwise return a descriptive error (use fmt.Errorf). Use
existing constants for types if available, make the method receiver pointer
(*ToolCallRequest) and ensure callers invoke Validate() before processing the
request.