Capabilities

Capabilities are the contract an application and a provider use to agree on what a request can do. The protocol defines Chat, Tools, Images, Reasoning, and structured output as named capabilities; an application declares what it needs and a provider declares what each model supports. Bricoop intersects the two so a request only runs when the model can actually serve it.

Declaring capabilities

Providers declare what their models support through models[].kind and models[].capabilities.*; an entry of kind: chat with capabilities.tools: true means the model accepts tool calls. Applications declare what they need through their model slots and capability flags; a slot that issues tool calls declares the Tools capability. Bricoop reads both declarations and only offers a model to an application when every required capability is present.

Negotiation

When the user picks a model for a slot, Bricoop negotiates by intersecting the application’s required capabilities with the model’s supported capabilities. If every required capability is present, the model is offered; if any is missing, the model is hidden or flagged. Negotiation happens at selection time, not at request time, so the user never sees a “model cannot do this” error after sending a message.

Unavailable capabilities

An unsupported request is rejected explicitly with a clear “unsupported capability” error naming the missing capability. Bricoop never silently degrades a request, never strips a tool call to force a fit, and never treats a missing capability as a sign of pair incompatibility between the application and provider. If the user needs the capability, they pick a model that supports it; the application and provider themselves remain compatible.