Interface IHttpLlmFunction<Model>

Whether the function is deprecated or not.

If the deprecated is true, the function is not recommended to use.

LLM (Large Language Model) may not use the deprecated function.

Description of the function.

IHttpLlmFunction.description is composed using the following rules:

1. Starts with the OpenApi.IOperation.summary paragraph
2. The next paragraphs are filled with the OpenApi.IOperation.description. If the first paragraph of OpenApi.IOperation.description matches the OpenApi.IOperation.summary, it is not duplicated
3. Parameter descriptions are added with @param tags
4. Security requirements are added with @security tags
5. Tag names are added with @tag tags
6. If OpenApi.IOperation.deprecated, a @deprecated tag is added

For reference, the description is a critical property for teaching the purpose of the function to LLMs (Large Language Models). LLMs use this description to determine which function to call.

Also, when the LLM converses with users, the description explains the function to the user. Therefore, the description property has the highest priority and should be carefully considered.

HTTP method of the endpoint.

Representative name of the function.

The name is a representative name identifying the function in the IHttpLlmApplication. The name value is just composed by joining the IHttpMigrateRoute.accessor by underscore _ character.

Here is the composition rule of the IHttpMigrateRoute.accessor:

The accessor is composed with the following rules. At first, namespaces are composed by static directory names in the path. Parametric symbols represented by :param or {param} cannot be a part of the namespace.

Instead, they would be a part of the function name. The function name is composed with the HTTP method and parametric symbols like getByParam or postByParam. If there are multiple path parameters, they would be concatenated by And like getByParam1AndParam2.

For reference, if the operation's method is delete, the function name would be replaced to erase instead of delete. It is the reason why the delete is a reserved keyword in many programming languages.

• Example 1

• Path: POST /shopping/sellers/sales
• Accessor: shopping.sellers.sales.post
• Example 2

• Endpoint: GET /shoppings/sellers/sales/:saleId/reviews/:reviewId/comments/:id
• Accessor: shoppings.sellers.sales.reviews.getBySaleIdAndReviewIdAndCommentId

Get the Swagger operation metadata.

Get the Swagger operation metadata, of the source.

Expected return type.

If the target operation returns nothing (void), the output would be undefined.

List of parameter types.

If you've configured IHttpLlmApplication.IOptions.keyword as true, number of IHttpLlmFunction.parameters are always 1 and the first parameter's type is always ILlmSchemaV3.IObject. The properties' rule is:

• pathParameters: Path parameters of IHttpMigrateRoute.parameters
• query: Query parameter of IHttpMigrateRoute.query
• body: Body parameter of IHttpMigrateRoute.body

{
  ...pathParameters,
  query,
  body,
}
Copy

Otherwise, the parameters would be multiple, and the sequence of the parameters are following below rules:

[
  ...pathParameters,
  ...(query ? [query] : []),
  ...(body ? [body] : []),
];
Copy

Path of the endpoint.

Get the migration route metadata.

Get the migration route metadata, of the source.

Collection of separated parameters.

Filled only when IHttpLlmApplication.IOptions.separate is configured.

Category tags for the function.

Same with OpenApi.IOperation.tags indicating the category of the function.

Validate function for the arguments.

You know what? LLMs (Large Language Models) like OpenAI frequently make mistakes when composing arguments for function calling. Even with simple types like number defined in the parameters schema, LLMs often provide a string typed value instead.

In such cases, you should provide validation feedback to the LLM using this validate function. The validate function returns detailed information about type errors in the arguments.

Based on my experience, OpenAI's gpt-4o-mini model tends to construct invalid function calling arguments about 50% of the time on the first attempt. However, when corrected through this validate function, the success rate jumps to 99% on the second attempt, and I've never seen a failure on the third attempt.

If you have separated parameters, use the IHttpLlmFunction.ISeparated.validate function instead when validating LLM-composed arguments.

In that case, this validate function is meaningful only after you've merged the LLM and human composed arguments using the HttpLlm.mergeParameters function.