module function · N/llm
createToolParameter()
llm.createToolParameter(options)
Creates a tool parameter for a tool.
- Implementation
- Not started
- Design
- Open for proposals suggest how it should read
A
suitescript api
1llm.createToolParameter({2 description: /* string, required */,3 name: /* string, required */,4 type: /* string, required */5});
| Parameter | Type | Required | Description |
|---|---|---|---|
| options.description | string | required | A description of what data the tool parameter represents. This parameter helps the LLM prompt for and fill in the value correctly. |
| options.name | string | required | A unique identifier for the tool parameter. This parameter is used when the LLM refers to this specific input in tool call requests (which are represented as llm.ToolCall objects). |
| options.type | string | required | The data type of the parameter. This parameter ensures the LLM produces correctly typed values. Use values from the llm.ToolParameterType enum to set this parameter. |
B
mynt syntax
No Mynt syntax yet.
Nothing in the language compiles to llm.createToolParameter(options) today. How should it read?
C
community proposals
Competing syntax for createToolParameter, from GitHub Discussions. Select two or more to compare them side by side.
Loading proposals from GitHub…
D
suggest an alternative
Write the Mynt you wish you could write.
A good proposal shows the syntax, the SuiteScript it should become, and argues for it: why it is clearer, how it fits the rest of the language, what it makes harder.
- Clarity. Does it say what happens, without ceremony?
- Consistency. Does it read like
load,saveandRef[field]? - Expressiveness. Does it cover the cases people actually write?
- Honesty. Does it hide a NetSuite cost, such as governance, that a reader should see?