When Chat Becomes a Capability
NextChat can turn model output into more than a paragraph: it can call an API, invoke a configured MCP server, publish generated HTML, or carry on a realtime audio session. This chapter compares those paths by asking where execution occurs, which credentials and data cross the boundary, and what controls are visible before an action happens. Readers will be able to identify the extension they are enabling and judge its trust surface instead of treating every feature as simply “a plugin.”
A plugin is a schema plus a callable path
An OpenAPI plugin begins as a description of an external service. NextChat loads the definition, discovers its operations, and converts each operation’s request schema into a function-tool declaration. The model can then see a tool name, description, and parameter shape alongside the chat request. The schema is not the action itself; it is the contract that lets the model propose an action in a form the client can interpret.
The client builds a callable function for each discovered operation. It separates path and query parameters from the request body, attaches authentication according to the plugin configuration, and invokes the corresponding operation through an OpenAPI client. Authentication can be placed in a bearer or basic header, a custom header, a query parameter, or the body. The plugin therefore carries two linked but distinct pieces of state: the description of what an operation accepts and the credential or endpoint needed to call it.
The target path changes with the application mode. In a web build, the call can go through NextChat’s proxy, with the declared server URL passed as a base-URL header for the server-side request. In an app build, the OpenAPI client can target the declared server directly. The model sees the same tool declaration, but the request has a different transport owner. A web deployment can mediate the call; a desktop environment can communicate more directly with the external service.
Plugins are attached to masks, which means capability selection can travel with a conversation policy. A user can choose a mask whose instructions, model settings, and selected tools are intended for a particular kind of work. During a streamed response, the provider may emit a function call in fragments. NextChat accumulates the fragments, invokes the matching plugin function, records success or failure, appends the tool call and result to the provider request, and asks the model to continue.
That continuation is important. The external API result does not automatically become the final answer. It re-enters the model conversation as tool information, allowing the provider to interpret it and produce a response. The action path therefore has at least three stages: the model proposes, NextChat executes, and the model interprets the result. A failure at the external API is not necessarily a failure of the provider adapter, and a valid schema does not guarantee a successful or safe operation.