Function Calling Explained: How AI Uses Trading Tools
Learn how AI proposes trading tool calls, how application code executes them, and why argument validation, wallet boundaries, and paper testing matter.
On this page
Disclosure: QuantBase is made by the team behind memecoin.buzz.
Risk: Most meme coins go to zero. Not financial advice.
An AI assistant says it can check a token or prepare a trade. What actually happens next? Here is function calling explained: the model proposes a named operation with structured inputs, and application code decides whether and how to execute it.
That distinction matters when a tool can affect a wallet. A model-generated request is not permission to move funds. The model drafts the work order; the application controls the door.
This guide follows a hypothetical token-checking tool from request to result. The examples describe a software design, not a working trading integration or a tested strategy.
Function calling explained: a request, not an execution
A function is a named operation in software. A tool call is a structured request to run that operation, including its arguments: the inputs it needs.
Imagine an application offers check_token. Instead of answering a token question from memory, the model can request that tool and supply a token address. The application checks the request, runs its token-checking code, and sends the result back. The model can then explain the returned information.
OpenAI’s function-calling guide describes this application-side execution loop. Google’s Gemini guide makes the same distinction: the model supplies the function request; executing the function is the application’s responsibility.
There is an important exception to the shorthand that your code executes tools. Some providers also offer built-in, server-side tools. Claude’s documentation distinguishes client tools, which run in your application, from server tools, which run with the provider.
This guide focuses on custom application-side trading tools. For those tools, receiving a request and allowing an action are separate decisions.
Follow the tool-call loop
Start with a narrow request: check the token address supplied by the user, without preparing or submitting a transaction.
The application first tells the model which tools are available. Each description should explain what the tool does and which inputs it accepts. A read-only token lookup should not quietly double as a trading tool.
- Describe the tool. Give the model its name, purpose, and accepted inputs.
- Receive the proposal. The model returns a tool name and arguments.
- Validate and execute. Application code checks the request before running the permitted operation.
- Return the result. Send the tool’s output or an explicit error back to the model.
- Explain or continue. The model answers using the result or requests another permitted tool.
This follows the loop in OpenAI’s documentation. A task can require further calls, so the application should apply its checks every time—not just when the conversation begins.
Keep requests, execution, and confirmation separate. A proposed lookup has not run yet. A proposed trade has not been submitted. A submitted transaction should not be described as completed merely because the model requested it.
For the broader connection between models and external tool services, see our MCP servers for crypto trading guide. Understanding this execution loop makes that architecture easier to follow.
Define the inputs with a schema
A schema is a machine-readable description of allowed data. JSON is a text format that stores named fields and their values. Together, they give software something more precise to process than a paragraph asking it to check a coin.
For example, this hypothetical OpenAI-style function definition exposes only a paper-mode token check:
{
"type": "function",
"name": "check_token",
"description": "Look up a supplied token address in paper mode; never submit transactions.",
"strict": true,
"parameters": {
"type": "object",
"properties": {
"mint_address": { "type": "string" },
"mode": { "type": "string", "enum": ["paper"] }
},
"required": ["mint_address", "mode"],
"additionalProperties": false
}
}
On Solana, the mint address identifies the token. In this example, mint_address must be text, mode must be paper, and extra fields are not accepted. The description states the intended boundary, but application code still needs to enforce it.
OpenAI’s strict-mode requirements include marking all properties as required and setting additionalProperties to false for parameter objects. Its guide explains that strict function calling uses structured outputs, which constrain generated data to a schema.
These terms are related, but they emphasize different things. Structured outputs concern the shape of generated data. Function calling connects a model’s request to an operation.
Correct shape does not establish correct meaning. A field can contain text and still contain the wrong token address. Schema compliance is a formatting boundary, not authorization to trade.
Validate arguments before doing anything
Treat model-generated arguments as proposed inputs, not trusted instructions. For a hypothetical trading application, use several layers of checks.
Check the operation. Accept only explicitly permitted tool names. Do not let a model-supplied name select arbitrary code or an unrestricted command.
Check the fields. Parse the arguments against the schema. Reject missing inputs, unexpected fields, incorrect types, and unsupported values. An invalid request should produce an error, not a guessed repair that changes the user’s intent.
Check the meaning. Confirm that the token address is valid for the intended chain and matches the user’s request. If the address is missing, ask for it rather than substituting a token with a similar name.
Check the permission. A valid token address does not authorize a purchase. For any wallet-enabled design, enforce approved assets, spending limits, transaction permissions, and any required confirmation separately from the model’s output.
Check the result. Return a clear success or failure status. If a lookup fails, the assistant should explain that failure rather than fill the gap with an invented token fact.
Google’s function-calling guide places execution in the application. That is the natural place to enforce these checks. A prompt can describe a limit; code must reject requests that exceed it.
External text deserves the same separation. A token description telling the assistant to ignore limits should remain data, not become an instruction. Our prompt-injection guide for crypto traders explores that boundary.
Keep wallet authority outside the model
The model does not need wallet secrets to propose a tool call. In a wallet-enabled design, keep signing authority—the ability to approve a transaction—in a separate, controlled component. The application may request an approved action from that component; the model should receive neither the secret nor unrestricted access to it.
Prefer narrow operations over a general-purpose execution tool. Separate reading token information, preparing a transaction, requesting approval, and submitting an approved transaction. Each boundary gives code a place to reject an unauthorized action.
Start on paper money. Set hard limits outside the conversation, including spending and transaction limits. Never share a seed phrase or private key with any AI, bot, agent, plugin, website, or person.
Also test rejection paths: a missing address, an unexpected tool name, a request to switch modes, or arguments outside the configured limits. The question is whether the application refuses correctly—not whether the assistant sounds cautious.
A stop control should block further execution in code. Asking the model to stop is not a substitute for disabling the operation it could request.
Practice the rule before adding wallet access
You do not need wallet access to practice translating an idea into an explicit rule. Keep the proposed action readable, inspect the inputs, and compare what happened with what the rule actually said.
QuantBase is a meme-coin trading app for Solana pump.fun coins. It turns plain-language instructions about what to buy, skip, and when to sell into a readable, editable rule. It tests rules on recorded launches before running them with paper money on live launches.
That illustrates a paper-first workflow, not evidence about QuantBase’s internal function-calling architecture. The official page we checked does not state which model or tool schema it uses. Today, QuantBase runs rules on paper; live trading is coming soon, and nothing in a paper run can touch a wallet.
For a practical starting point, test a plain-language rule on paper with QuantBase, then review its behavior against the rule you wrote.
Our paper-trading guide explains what to inspect during practice. The QuantBase traders’ Telegram also has a free bot that checks coins for developer selling, plus daily pump.fun stats.
The central lesson stays the same: the model proposes, the application validates, and only authorized code executes.
FAQ
Does function calling mean the AI executes a trade?
No. For custom application-side tools, the model produces a request that application code handles. Execution requires the application to accept and run that request.
Are structured outputs the same as function calling?
They are related, but not interchangeable. Structured outputs constrain generated data to a schema; function calling connects a model’s request to an operation. OpenAI uses structured outputs for strict function calling.
Does strict mode make a tool call safe?
Strict mode constrains the request’s format. It does not establish that a token is correct, a purchase is authorized, or an amount fits your limits. Application code needs those additional checks.
Should the model hold the wallet’s keys?
No. Keep signing authority outside the model and never share a seed phrase or private key with an AI, bot, or agent. Start with paper money and enforce hard limits before considering wallet-enabled execution.
Is QuantBase live trading available today?
QuantBase currently runs rules on paper money, and live trading is coming soon. Its paper runs cannot touch a wallet. It does not predict prices or claim it will make anyone money.
Sources
Written with AI assistance and checked by automatic gates: every number must trace to a source above, and quotes are short. Spot an error? Tell us in Telegram.
