Treat model tools as a runtime contract

A model choice changes the workflow

An agent workflow often starts with a simple assumption: the selected model can use the tools the prompt describes. That assumption may hold until a model is swapped, a provider changes, or a workflow runs against a model with a different tool set. Then the failure shows up at the point of use, or worse, the workflow quietly produces a weaker answer while behaving as if nothing changed.

I would make tool support part of the workflow’s runtime contract. Before the workflow starts, it should inspect the selected model’s capabilities, decide which paths are available, and state what to do when a required tool is absent. That does not make the agent reliable by itself. It makes an important dependency visible and gives the application a chance to respond deliberately.

This is a timely design question because Anthropic’s October 6, 2026 announcement introduced server-tool capability fields in its Models API update. The Models API reference describes support information for server tools such as web search and code execution. That is useful information to consult before building a request, rather than baking a model-specific assumption into a prompt or workflow.

Discover, then choose a path

Capability discovery should happen where the application selects or prepares a model, not be scattered through prompts. The workflow can translate provider metadata into a small set of decisions it understands: web search available, code execution available, or neither. Then it can select a supported path before asking the model to act.

For example, a research workflow might have three legitimate modes. With web search, it can gather current sources. Without it, it can answer only from supplied context, or stop and tell the caller that current research is unavailable. It should not send the same instruction in both cases and hope the model will improvise its way around a missing tool.

A small adapter keeps provider-specific metadata out of the workflow itself. This TypeScript illustrates the shape of that decision; it is not a claim about a particular SDK’s method names:

type ModelInfo = {
  capabilities?: {
    server_tools?: {
      web_search?: { supported?: boolean };
      code_execution?: { supported?: boolean };
    };
  } | null;
};

type ResearchMode = 'search' | 'context-only' | 'unavailable';

function chooseResearchMode(model: ModelInfo): ResearchMode {
  const canSearch =
    model.capabilities?.server_tools?.web_search?.supported === true;

  if (canSearch) return 'search';
  return 'context-only';
}

The important part is not the helper. It is that the result affects the workflow’s behavior. In a production version, I would make the fallback a policy decision rather than quietly choosing context-only for every task. If the user asks for current information, context-only may be an invalid answer. The workflow should then return an explicit unsupported-capability result, or route to a separately configured search implementation.

Metadata needs careful interpretation. Anthropic’s documentation says a true value for web search or code execution means the model supports at least one version of that tool, not necessarily every version. So a capability flag is a useful discovery signal, not a guarantee that any arbitrary tool configuration will work. I would still validate the exact request shape and handle provider errors at invocation time.

Make fallback behavior part of the contract

There is no universal fallback for an unavailable tool. The right response depends on the task and the consequences of being wrong. A coding workflow might be able to continue without code execution if it clearly labels its output as untested. A workflow asked to calculate a result from a large dataset may need to stop rather than offer a guess. A research agent asked for recent facts should not pretend that static context is current.

I would write those policies down alongside the workflow, in terms an operator can inspect:

• Required capability: Which tools must be present for this workflow to run as designed?
• Fallback: Can it use a different tool, continue with a narrower answer, or must it stop?
• Disclosure: What should the caller be told when the workflow takes a reduced path?
• Failure handling: What happens if metadata says the tool is supported but the actual request is rejected or the tool fails?

A useful distinction is between an optional enhancement and a task prerequisite. If web search only adds citations to an answer that can be grounded entirely in supplied material, it may be optional. If the request is to find the latest documentation, search is a prerequisite. That difference should live in workflow policy, not in the model’s interpretation of an instruction buried in a prompt.

I also would not silently substitute a different tool just because it appears to serve the same purpose. A provider-hosted search tool and an application-managed search service can have different source coverage, access controls, and result formats. Substitution can be a valid fallback, but it changes the workflow’s behavior and should be intentional.

Metadata is not a reliability mechanism

Discovering capabilities answers a narrow question: what does the provider say this model can support? It does not prove that the tool will be available on this request, that the model will use it appropriately, or that the result will be correct. A supported tool can still fail, return irrelevant material, or be used when the task does not warrant it.

That is why I would treat capability metadata as an input to workflow selection, not as the workflow’s safety system. The application still needs bounded retries, error handling, and an explicit decision about whether a failed tool call invalidates the answer. If the tool is essential, failure should usually fail the task rather than produce an answer that looks complete. If it is optional, the fallback should be limited and visible.

The same principle applies when model information cannot be retrieved. I would not interpret missing metadata as support. The workflow can fail closed for required capabilities, use a documented conservative mode for optional ones, or rely on a cached capability record with a clear freshness policy. Which option fits depends on the system; the key is to decide instead of turning an unknown into an implicit yes.

This boundary also helps when a workflow supports several providers or model families. The provider adapter translates their capability descriptions into the application’s own contract. The workflow then asks for a capability it needs, rather than checking vendor-specific fields throughout its logic. That keeps the policy stable even as model selection changes, while leaving the adapter responsible for understanding each provider’s actual metadata.

Choose the workflow, not just the model

I would select a model and a workflow path together. A model is not a drop-in replacement if the task depends on a tool it does not support. Conversely, a workflow should not require a tool merely because one convenient model happens to offer it. Make the dependency explicit, check it before execution, and define the reduced mode or refusal path in advance.

The useful promise of capability discovery is modest but practical: fewer hidden assumptions. It gives the application a chance to say, before execution, whether this model can run this path—and what it will do if it cannot.