The four custom-tool options

Once you have decided the agent needs to call your own code, there are four ways to arrange it. Questions here give you a constraint and expect you to pick the arrangement that fits it, so the useful thing is to know what each option is for rather than what each one is.

Choosing by the constraint

Option	Reach for it when	The detail that decides it
Custom function calling	The code is local and short	You write the dispatcher, and it runs on client compute
Azure Functions	You need separation of concerns, reusable or centralised tools, security isolation, external dependencies, or long-running and asynchronous work	Queue-based. Requires the standard agent setup
OpenAPI tool	You already have a REST API with an OpenAPI 3.0 or Swagger specification	Add the OpenAPI specification tool, with operation_id and descriptions
Azure Logic Apps	You want low-code integration	The low-code sibling of Functions
Model Context Protocol	You want standardised discovery, or you are reusing an existing server	Covered on the next card

What Functions and Logic Apps have in common

Three things, and they explain why both appear as answers to the same kinds of question:

• Both expose an HTTP endpoint.
• Both move execution off the client.
• Both survive long-running work.

The difference between them is who builds it. Functions is code; Logic Apps is low-code, which makes it the answer when the question mentions citizen developers or business users assembling the integration themselves.

Sizing the choice

A compressed version of the table, in the order the constraints usually appear:

• Short, local, synchronous → function calling
• Long, shared, isolated, asynchronous → Azure Functions
• An existing REST service → the OpenAPI tool
• Citizen-developer integration → Logic Apps

Notice the second row is doing the work that card 13 set up. In-process function calling runs on client compute and races the ten-minute run expiry, so anything long or shared moves to Functions. The two cards are answering the same underlying design question from different sides.

The definition to recognise

A custom tool is defined as a callable function that extends an agent's capabilities. That phrasing turns up as an answer option, so it is worth recognising rather than reasoning your way to.

The trap

When a question says you already have an OpenAPI 3.0 web service, there is exactly one answer: add the OpenAPI specification tool to the agent definition.

Two wrong answers are offered and both are tempting because they involve doing real work. Do not wrap it in a custom function. Do not rebuild it as an Azure Function. The service already exists and already describes itself — the specification is the integration. Rebuilding it is effort that produces something worse.