An LLM use case with function-calling

The article Function calling using LLMs by Kiran Prakash writes,

“It’s important to emphasize that when using function calling, the LLM itself does not execute the function. Instead, it identifies the appropriate function, gathers all required parameters, and provides the information in a structured JSON format. This JSON output can then be easily deserialized into a function call in Python (or any other programming language) and executed within the program’s runtime environment.”

This is an approach that works very well when you don’t have a testing environment: build a plan, evaluate validity of the plan, and then apply the plan after verification. You should also be able to slice the work into sub-tasks to make verification more reliable. This is the approach I took for a PowerShell script that runs against an ADOS instance: it’s production data, so you really want to be sure what is going to be executed.

In the implementation, you can see how the code he writes prepares the query to the LLM in a structured way with the required context in an attempt to guide the result. Happily, he begins by writing unit tests!

Function-calling with an LLMThis is another good step-by-step example of working with an LLM, but for a different task: it’s using an LLM as an interpreter for the user’s input. It’s basically a way of adding a natural-language “search-like” interface to an app without forcing the user to structure their input, without developing an UI, and without writing a parser. The advantage is that you get a way of querying a potentially large API surface in a way that in more amenable to more users.

I think of an example from Markus Schenkel from Cudos, who talked about using an MCP plugin for working with a CAD/CAM program—apps that notoriously have dozens of toolbars and thousands of functions. He could formulate his “novice” request as text, and the LLM, together with the mapping to tool functionality, made relatively good guesses about what he was trying to do. It often took a few attempts—but he was able to accomplish his task, whereas he would have either given up or had to invest a lot more time to get it done otherwise.

I think this is great for products that are in proof-of-concept stage, so that you don’t iterate on UIs too early in the design process. But we also have to be aware that we have UIs for a reason. Once there’s a well-established set of use cases and functionality, then it’s unclear that making users continue to use a command-line interface where they compose text is better than a GUI.

At any rate, the article is filled with detail and code (in Python) for using an LLM in the way described above. There’s a section on refactoring at the end, a comparison to the rules-engine-based approach that this technique seeks to replace, and also a comparison of function-calling with MCP.