Models and tools¶
Models generate or transform information. Tools perform named operations against other systems. Mission Control exposes both through gateways so applications use Team access and limits without receiving upstream provider credentials.
Virtual models and provider routes¶
A virtual model is the name your application requests, such as support. Its configured routes connect that name to provider deployments. This separates the application's model choice from provider credentials and routing settings.
The same virtual model name does not promise every API feature. A route must support the requested operation, protocol, input modality and parameters. Use GET /v1/models to discover the names and capabilities available to your key. Treat the Model Gateway reference as the compatibility contract.
For example, a Team might allow these separately configured resources:
| Virtual model | Intended operation | Key operation |
|---|---|---|
support |
Generate a support answer | model.generate |
search-embedding |
Convert text into vectors | model.embed |
search-rerank |
Order candidate documents by relevance | model.rerank |
These names are fictional. Embedding and reranking access does not imply generation access. A denied or unsupported request cannot be fixed by substituting the upstream provider's model name.
Connectors, tools and tool sets¶
A Connector is a configured upstream MCP server and its authentication settings. It exposes tools, each with a name, input schema and governance settings. A tool set groups tools for allowance and key selection; following a set can include later changes to its membership, still bounded by current authority.
Discover tools with tools/list and build arguments from the returned schema. A tool's name alone is not enough to know its required fields. Administrators can classify tools, restrict them with rules, require approval and configure per-call pricing.
Access to a tool and authentication to its upstream system are separate checks. A company connection uses a configured company account. A personal connection uses the initiating person's own grant. An unattended service account cannot stand in for a person whose connection is required.
Three ways to execute tools¶
| Pattern | Who executes the tool? | Use it when |
|---|---|---|
| Ordinary function calling | Your application receives the function call and executes it | You own the tool loop and local functions |
| Direct MCP | Your MCP client calls the Mission Control gateway | A client or application needs a governed remote tool |
| Governed tools in a model request | Mission Control executes the explicitly selected supported tool loop | You want the gateway to coordinate model rounds and approved tools |
A model's proposed function call is not evidence that the tool ran. For a remote tool, inspect the canonical Request and its outcome. An approval result is also distinct from execution: the authorized retry must still pass current access and limits.
Compatibility is explicit¶
The model API supports Chat Completions and a documented stateless Responses subset. It does not offer arbitrary provider-hosted tools or stored Responses state. The MCP gateway supports the specific revision and transport described in its reference; a client speaking an older protocol may need an adapter or upgrade.