Can AI Use Tools Without Writing Code

How Tool Use Works Without Code

When a model "uses a tool," it generates a JSON object like {"name": "get_weather", "arguments": {"city": "Tokyo"}}. This is not code. It is a structured request, similar to filling out a form. The model selected the tool based on its description, chose the arguments based on the user's message, and produced a data structure that the application can act on. The model does not know what programming language the function is written in, where it runs, or how it is implemented. It only knows the interface: what goes in and what comes back.

This separation between request and execution is fundamental to the architecture. The model handles the intelligence (deciding what to do and what arguments to pass). The application handles the engineering (running the function, managing connections, handling errors, enforcing security). The model's output is a decision, not a program.

When AI Does Write Code as a Tool

There is a specific class of tools where the model does write and execute code: REPL tools, code execution sandboxes, and scripting environments. These are tools that accept code as a parameter and execute it in a sandboxed environment. For example, a data analysis tool might accept a Python script that processes a dataset, or a math tool might accept an expression to evaluate.

These code-execution tools are themselves invoked through function calling (the model generates a tool call with the code as a string parameter), but the content of the parameter is code that gets executed. This is a specialized pattern used for tasks like data analysis, visualization, mathematical computation, and file manipulation where the flexibility of code is necessary. It requires careful sandboxing because the model-generated code could contain anything from efficient analysis to infinite loops.

The vast majority of tool interactions do not involve code execution. Looking up a customer, checking order status, sending a notification, searching a knowledge base, storing a memory, and updating a record are all standard tool calls where the model produces structured data, not code.

A Concrete Example

Consider an AI agent that helps users manage their calendar. The developer defines a tool called create_event with parameters for title, date, time, and duration. When the user says "Schedule a meeting with Sarah tomorrow at 2pm," the model generates: {"name": "create_event", "arguments": {"title": "Meeting with Sarah", "date": "2026-05-14", "time": "14:00", "duration": 60}}. No code was written by the model. It produced a data structure describing the desired action. The application receives this structure, calls the calendar API with the specified parameters, and returns the result.

The model did not generate a Python script that imports a calendar library, authenticates with Google, and creates an event object. It did not write JavaScript that calls fetch() against an API endpoint. It produced a JSON object with four fields. The application, which the developer wrote once, handles all the actual API interaction, authentication, error handling, and response formatting. The model's contribution is purely reasoning about what action to take and what parameters to use.

This distinction matters for security and reliability. Because the model produces structured data rather than executable code, the surface area for errors and exploits is much smaller. A malformed JSON argument can be caught by schema validation before it reaches any external system. A malformed code snippet could do anything, from infinite loops to file system access, if executed without sandboxing. Structured tool calls are inherently more constrained and safer than code execution.

No-Code Tool Builders

Several platforms now offer visual tool builders that let non-developers create tools for AI agents without writing code. These platforms provide a drag-and-drop interface for defining tool schemas, connecting to APIs, and mapping parameters. The resulting tools work through the same function calling mechanism: the model generates structured calls, and the platform handles execution.

For developers, the code you write is the tool implementation (the function that runs when the model calls it) and the schema (the JSON definition that describes the tool to the model). The model's interaction with the tool is entirely codeless on the model's side, always a structured JSON request and a structured JSON response.

MCP Makes Tool Building Even More Accessible

The Model Context Protocol adds another dimension to codeless tool use. MCP servers expose tools through a standard protocol that any compatible client can connect to. A developer builds the MCP server once, defining tools with schemas, and any MCP client (Claude Code, Cursor, custom applications) can discover and use those tools automatically. The client-side integration requires no tool-specific code because the MCP protocol handles discovery, schema exchange, and result formatting.

For teams that use memory-backed tools, Adaptive Recall provides its seven memory tools (store, recall, update, forget, reflect, graph, status) through an MCP server. Any MCP-compatible AI application connects to the server and gains persistent memory capabilities without the development team writing any memory-specific code. The model interacts with these tools through the same structured function calling mechanism, generating JSON requests that the MCP server processes and responds to.

The broader trend is toward tools as services. Developers build and host tools that expose capabilities through standard protocols, and AI applications consume those tools through structured calling conventions. The model sits in the middle, reasoning about which tools to use and what parameters to pass, without ever writing or executing code. This architecture separates the intelligence (the model's reasoning) from the capability (the tool's functionality) cleanly, making both independently improvable and replaceable.