From Catalog to Control Plane: Building an Ollama Model Registry

Choosing a local model is not a shopping exercise. It is an engineering decision about capabilities, behavior, and resource limits—and those three things need to be measured separately.

This guide builds a dependable path from Ollama’s catalog to a model registry your application can trust.

API behavior and documentation links were reviewed against Ollama’s official documentation on September 20, 2026.

Ollama has two different model lists: models you’ve already downloaded locally, and the much larger set of models available to download from the Ollama library. The key is to use the catalog to discover models, then inspect and test each model locally before relying on it in an application.

See what you already have

To see the models installed on your machine:

ollama list

You can get the same information through Ollama’s local API:

curl http://localhost:11434/api/tags

This tells you what is immediately available to run on that Ollama instance. It includes things such as the model name, file size, quantization, parameter class, and when the artifact was last modified.

For a cleaner view:

curl -s http://localhost:11434/api/tags | jq '
  .models[] | {
    name,
    size_gb: (.size / 1024 / 1024 / 1024 | round * 100 / 100),
    family: .details.family,
    parameters: .details.parameter_size,
    quantization: .details.quantization_level
  }
'

Find models available to download

The easiest way to browse downloadable models is the Ollama Library. It is where Ollama lists major model families, their variants, approximate sizes, and intended uses.

For example, you might look for:

• General chat and reasoning models
• Coding-oriented models
• Vision models that accept images
• Embedding models for RAG
• Smaller models for laptop or CPU inference
• Larger cloud-hosted models

You can also query Ollama’s public model catalog programmatically:

curl -s https://ollama.com/api/tags | jq '.models[] | {name, size, details}'

Think of this endpoint as a discovery feed. It is useful for building an internal model browser or synchronizing an inventory, but it should not be your only source for deciding which models are production-ready.

Check what a model can actually do

A model name alone is not a reliable indicator of features. Two variants in the same family may differ in context length, quantization, tool-calling behavior, image support, or structured-output reliability.

After downloading a model, inspect it directly:

ollama show qwen3:8b

For more detailed output:

curl -s http://localhost:11434/api/show \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3:8b","verbose":true}' | jq

This is where you should look for the model’s declared capabilities. Depending on the model, you may see support for:

Capability	What it means
completion	Generates text responses
vision	Can accept image input
tools	Can call functions or external tools
thinking	Supports a separate reasoning/thinking channel
embedding	Generates vector embeddings for retrieval or semantic search

For example, a model may be good for chat but not support image input. Another may support tool calling but produce unreliable JSON for complex schemas. The API tells you what a model claims to support; your evaluation suite tells you whether it is good enough for your workload.

A useful local inventory script

If you have multiple models installed, this shell loop gives you a quick capability report:

for model in $(ollama list | awk 'NR > 1 {print $1}'); do
  echo "=== $model ==="

  curl -s http://localhost:11434/api/show \
    -H 'Content-Type: application/json' \
    -d "{\"model\":\"$model\"}" |
    jq '{
      capabilities,
      family: .details.family,
      parameter_size: .details.parameter_size,
      quantization: .details.quantization_level
    }'
done

That is useful for answering questions such as:

• Which installed models can call tools?
• Which ones can accept images?
• Which models are embedding-only?
• Which models are small enough for a particular machine?
• Which model tags are currently deployed on a server?

Treat capability and quality separately

For engineering purposes, I would separate declared capabilities from measured behavior.

A simple internal registry might look like this:

{
  "name": "qwen3:8b",
  "capabilities": ["completion", "tools", "thinking"],
  "input_modalities": ["text"],
  "output_modalities": ["text"],
  "context_window": 32768,
  "parameters": "8B",
  "quantization": "Q4_K_M",
  "artifact_size_gb": 5.2,
  "validation": {
    "tool_calling": "passed",
    "json_schema": "passed",
    "rag_answer_quality": 0.79,
    "tokens_per_second": 37.5,
    "peak_vram_gb": 6.1
  }
}

This prevents a common problem: assuming that a model supporting tools is automatically a good agent model, or that a vision-capable model is automatically good at document understanding.

For production routing, you want both:

• Capability metadata: Can this model accept images, call tools, return embeddings, or expose thinking?
• Operational and evaluation data: Is it fast enough, stable enough, accurate enough, cheap enough, and reliable enough on your real prompts?

A practical workflow

1. Browse the Ollama Library or query the public catalog.
2. Pick specific model tags rather than relying on latest.
3. Pull the model locally.

ollama pull qwen3:8b

4. Inspect its metadata and Modelfile.

ollama show qwen3:8b
ollama show --modelfile qwen3:8b

5. Run small capability tests:

   • Send an image to vision models.
   • Test a function-call schema for tool-enabled models.
   • Validate JSON output against a schema.
   • Run embedding similarity checks for retrieval models.
   • Measure prompt throughput, generation throughput, VRAM, and latency.

6. Add only validated models to your application’s supported-model list.

For an agentic or RAG platform, the model registry becomes a control plane: it decides which models qualify for extraction, retrieval, tool use, coding, vision, and long-context tasks. That is more dependable than letting users pick any model that happens to be downloadable.

The control-plane view

A model registry is more than a catalog page in an admin console. It is the evidence your router uses when it decides whether a workload should reach a particular model. Keep declared metadata, reproducible evaluation results, and live operational measurements separate; update them on different schedules; and make every production route depend on an explicit acceptance threshold.

That turns “this model appears to support tools” into “this exact artifact passed our tool-calling suite on this hardware under these constraints.” The second statement is the one an operating system can trust.

Continue the series

• Ollama in Production: The Architecture Around the Model
• Streaming AI Responses: When to Use SSE, WebSockets, or Plain HTTP
• Engineering with Ollama: A Six-Week Hands-On Course

Official references

• Ollama model library
• List local models API
• Ollama API reference