Ermöglicht es Claude Desktop, einen lokalen Ollama-Server abzufragen und zu verwalten. Listen Sie installierte Modelle auf, inspizieren Sie diese, führen Sie One-Shot-generate/chat-Vervollständigungen mit jedem lokalen Modell aus oder laden/löschen Sie Modelle aus der Registry – alles ohne ein Terminal zu öffnen.
Typische Anwendungsfälle: Vergleichen von Claudes Antwort mit einem lokalen Modell bei derselben Eingabeaufforderung, Ausführen kostengünstiger Massenvervollständigungen mit einem quantisierten Modell oder Überprüfen benutzerdefinierter Training-Checkpoint-Modelle, die Sie in Ollama importiert haben.
Ein laufender Ollama-Server (ollama serve oder die Ollama-App).
Der Standard-Endpunkt ist http://localhost:11434. Überschreiben Sie diesen über die Benutzerkonfiguration ollama_url in den Erweiterungseinstellungen von Claude Desktop, falls Sie Ollama auf einem anderen Host oder Port ausführen.
Keine npm-Abhängigkeiten – reines Node über die HTTP-API.
Related MCP server: Ollama MCP Server
Laden Sie die neueste Ollama.mcpb von der Releases-Seite herunter.
In Claude Desktop: Settings → Extensions → Extension Developer → Install Extension → wählen Sie die .mcpb aus.
(Optional) Legen Sie in den Einstellungen der Erweiterung die Ollama server URL fest, falls Sie Ollama auf einem nicht standardmäßigen Host/Port ausführen. Lassen Sie das Feld leer für http://localhost:11434.
Tool | Annotation | Zweck |
| schreibgeschützt | Gesundheitsprüfung + Server-Version |
| schreibgeschützt | Lokale Modelle mit Größe, Digest, Familie, Parametergröße, Quantisierung |
| schreibgeschützt | Derzeit im VRAM geladene Modelle |
| schreibgeschützt | Modelldetails: Modelfile, Parameter, Template, Fähigkeiten |
| open-world | One-Shot-Textvervollständigung (nicht-streaming) |
| open-world | Chat-Vervollständigung mit Nachrichtenverlauf (nicht-streaming) |
| open-world | Modell aus der Registry herunterladen |
| destruktiv | Ein lokal installiertes Modell entfernen |
"Welche lokalen Modelle habe ich installiert und welches ist derzeit im VRAM geladen?"
"Führe
forge:b6c1mit diesem Prompt aus: ''. Vergleiche das Ergebnis mit deiner eigenen Antwort."
"Zeige mir das Modelfile für
forge:b7c1– ich möchte die Temperatureinstellung überprüfen."
"Lade
llama3.1:70bherunter." (erwarte eine lange Wartezeit bei großen Modellen)
"Lösche das Modell
forge:b5c3– ich brauche diesen Checkpoint nicht mehr."
Diese Erweiterung läuft vollständig auf Ihrem lokalen Computer und sendet HTTP-Anfragen nur an Ihren Ollama-Server (Standard http://localhost:11434). Es verlassen keine Daten Ihren Computer, es sei denn, Sie konfigurieren explizit ollama_url, um auf eine entfernte Ollama-Instanz zu verweisen. In diesem Fall werden die Prompts und Antworten an diesen Server übertragen.
Die für Claude sichtbaren Informationen umfassen:
Alle Prompts und Chat-Nachrichten, die Sie an generate und chat übergeben (diese gehen an den Ollama-Server, der sie je nach Konfiguration protokollieren kann).
Vollständiger Text der Vervollständigungen, die von Ollama zurückgegeben werden.
Metadaten für jedes installierte Modell (Namen, Digests, Größen, Quantisierung, Modelfile-Inhalte).
Welche Modelle derzeit im VRAM geladen sind und deren Speicherbedarf.
Wenn Sie Modelle installiert haben, die proprietäre Feinabstimmungen oder Modelfiles mit sensiblen Metadaten enthalten, beachten Sie, dass Claude diese Informationen sieht, wenn Sie show_model oder list_models aufrufen.
delete_model ist destruktiv und kann von dieser Erweiterung aus nicht rückgängig gemacht werden – das Modell muss aus der Registry neu geladen (oder aus Quell-Blobs neu importiert) werden, falls es versehentlich gelöscht wurde.
"cannot reach Ollama at http://localhost:11434 — is the server running?" – Starten Sie Ollama mit ollama serve oder starten Sie die Ollama-App. Überprüfen Sie dies mit curl http://localhost:11434/ (sollte "Ollama is running" zurückgeben).
pull_model hängt lange – Die Pull-API von Ollama mit stream: false blockiert, bis der vollständige Download abgeschlossen ist, was bei Modellen mit mehreren GB viele Minuten dauern kann. Wenn Sie ein riesiges Modell herunterladen, führen Sie stattdessen ollama pull <name> in einem Terminal aus – dort sehen Sie den Streaming-Fortschritt, und nachfolgende MCP-Aufrufe werden das Modell als bereits installiert finden.
Benutzerdefinierter/entfernter Ollama-Endpunkt – Legen Sie ollama_url in den Einstellungen der Erweiterung fest (z. B. http://192.168.1.42:11434). Erfordert einen Neustart der Erweiterung.
list_running zeigt ein Modell an, nachdem Sie die Nutzung beendet haben – Ollama hält Modelle für eine konfigurierbare TTL (Standard 5 Minuten) im VRAM aktiv. Der expires_at-Zeitstempel zeigt Ihnen, wann es entladen wird. Dies ist das Verhalten von Ollama, nicht der Erweiterung.
Einzelnes ~400-zeiliges Node.js-Skript, null npm-Abhängigkeiten. Erstellen Sie die .mcpb neu:
cd bundle-source
zip -j ../Ollama.mcpb manifest.json package.json server.js README.md LICENSE icon.png glama.jsonMIT. Siehe LICENSE.
claude-terminal-mcp – Shell, Dateisystem und Hintergrundjobs.
claude-rocm-mcp – AMD GPU-Überwachung; passt gut dazu, um zu prüfen, ob das geladene Modell von Ollama den VRAM auslastet.
claude-sessions-mcp – tmux-Sitzungsverwaltung für lang laufende Jobs.
claude-linux-mcp – X11-Desktop-Steuerung.
Run a chat completion against a local model with message history (non-streaming). Returns the assistant's reply plus timing.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name. | |
| messages | Yes | Chat history. Each item: {role: "system"|"user"|"assistant", content: string}. | |
| options | No | Ollama sampling/decoding options. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readonly and non-destructive, but description adds 'non-streaming' and 'returns timing'. However, it does not disclose potential side effects (e.g., model state changes) or permission requirements beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence of 15 words. It efficiently conveys the core action, key features (non-streaming, message history), and output (reply + timing) with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, openWorldHint=true, no output schema), the description mentions return type but is vague about timing structure and does not cover error cases or model availability. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no additional parameter details beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a chat completion with message history (non-streaming) and returns reply plus timing. It differentiates from siblings like 'generate' by emphasizing message history and non-streaming, but does not explicitly compare to all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use cases via 'with message history' and 'non-streaming', but provides no explicit guidance on when to use this tool versus alternatives like 'generate' or 'pull_model'. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a locally-installed model. Does not affect the remote registry copy. Free the disk space of a model you no longer need.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Model name to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only nature. The description adds valuable context: 'Does not affect the remote registry copy' and 'Free the disk space', which goes beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficiently front-loaded with purpose and key behavioral constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one required param, no output schema), the description fully covers purpose, scope, and side effect. Annotations provide safety profile. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'name', so the tool description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Delete' and the resource 'locally-installed model', and distinguishes from sibling tools like pull_model, list_models, etc. by specifying local scope and effect (freeing disk space).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you no longer need a model and want to free disk space, but does not explicitly state when not to use or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a one-shot text completion against a local model (non-streaming). Returns the full response text plus timing and tokens/second.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g. "llama3.1:8b"). | |
| prompt | Yes | Prompt text. | |
| system | No | Optional system prompt. | |
| options | No | Ollama sampling/decoding options — e.g. {"temperature": 0.7, "num_predict": 100, "top_p": 0.9}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, and open-world. The description adds behavioral details: non-streaming, returns full text plus timing/tokens/second, which goes beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads the core purpose (one-shot completion) and key behaviors (non-streaming, returns timing/tokens). Every word adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage, annotations, and no output schema, the description sufficiently covers the tool's purpose, behavior, and return values. No critical information missing for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description adds no additional parameter-specific information beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a one-shot text completion (verb+resource) and specifies it's non-streaming, distinguishing it from siblings like 'chat' which may be streaming or multi-turn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for one-shot completions and non-streaming needs, providing clear context. However, it does not explicitly mention alternatives or when not to use it, so it misses a full exclusion guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List locally-installed models: name, size in bytes, digest, modified timestamp, family (e.g. llama), parameter size (e.g. 8.0B), and quantization level (e.g. Q4_K_M).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing the exact fields returned (size, digest, family, params, quantization), providing context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates purpose and return fields with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully documents the return fields. Combined with annotations, it provides complete context for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description correctly avoids adding redundant parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List locally-installed models' and enumerates the specific fields returned. This distinguishes it from sibling tools like list_running (running models) and show_model (single model details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing all installed models but provides no explicit guidance on when to use this tool versus alternatives (e.g., show_model for details, list_running for active models).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List models currently loaded into VRAM with their size, VRAM footprint, and expiry timestamp. Empty list means Ollama is idle.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool returns specific fields (size, VRAM footprint, expiry timestamp), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb, no wasted words. Achieves maximum clarity with minimal text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes the tool's function and output given the lack of parameters and output schema. The note about empty list provides complete context for the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined; the description does not need to add parameter details. Baseline score of 4 applies as there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('models currently loaded into VRAM'), and distinguishes from sibling 'list_models' by specifying the loading status. It also mentions the returned fields (size, VRAM footprint, expiry timestamp).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking current VRAM load and idle status ('Empty list means Ollama is idle'), but does not explicitly mention when to use it vs alternatives like 'list_models' or 'ollama_status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check: whether the Ollama server is reachable and its version. Use this as a precondition before other tools if you're unsure whether Ollama is running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description adds that the tool returns reachability and version info. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no superfluous information. Purpose and usage are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete: it explains what it does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline score of 4 applies. The description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as a health check for the Ollama server, checking reachability and version. It distinguishes itself from sibling tools like chat or generate, which interact with models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this as a precondition before other tools when unsure if Ollama is running, providing clear when-to-use guidance and implying alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a model from the Ollama registry. Blocks until complete — can take a long time for multi-GB models. For very large pulls, prefer ollama pull in a terminal where you can watch progress.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Model name to pull (e.g. "llama3.1:8b"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool blocks until completion and can take a long time, which are important behavioral traits not captured by annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true). It does not elaborate on authentication or error handling, but the blocking behavior is a key disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and every sentence adds value. No redundant or irrelevant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description adequately covers purpose, behavioral aspects, and usage advice. It could mention success indicators or behavior on existing models, but the current level is sufficient for a simple pull operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage (100%) with a description for the 'name' parameter including an example. The tool description does not add additional meaning beyond what the schema already conveys, hence a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a model from the Ollama registry, with a specific verb ('Download') and resource ('model from the Ollama registry'). It distinguishes itself from sibling tools like 'delete_model' and 'generate' by focusing solely on pulling models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises preferring the terminal `ollama pull` for very large models, giving explicit guidance on when to avoid this tool. However, it does not compare against other server tools (e.g., not to use if model is already present), but the external alternative is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show detailed information for a specific model: modelfile excerpt, parameters, template, capabilities, architecture details, quantization level.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Model name (e.g. "llama3.1:8b" or "forge:b6c1"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the returned content but does not disclose additional behaviors like rate limits or authentication needs beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's purpose and lists key details without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one parameter), good annotations, and no output schema, the description adequately explains the return content (modelfile excerpt, parameters, etc.), making it fairly complete for an agent to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the 'name' parameter with an example. The description does not add additional meaning for the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows detailed information for a specific model and enumerates the types of details (modelfile, parameters, etc.), distinguishing it from siblings like list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context makes it clear that this tool is for retrieving details on a single model versus listing all models (list_models) or chatting (chat), but no explicit when-not or alternative names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0chatdelete_modelgeneratelist_modelslist_runningollama_statuspull_modelshow_modelScored across 8 tools
Each tool has a clearly distinct purpose: chat vs generate differentiate by context (with/without history); model management tools (list, pull, delete, show, list_running) are non-overlapping; ollama_status is a standalone health check. No ambiguity in roles.
Most names follow a verb_noun pattern (e.g., delete_model, list_models, pull_model). 'chat' and 'generate' are single verbs but still actions. 'ollama_status' deviates slightly (noun_noun) but is readable. Overall consistent with minor exceptions.
8 tools cover the essential operations for a local Ollama server: model management (list, pull, delete, show, list_running), two inference modes (chat, generate), and a health check. Well-scoped without bloat or deficiency.
Core CRUD and inference are covered, but streaming support is absent (only non-streaming provided). No tool to adjust model parameters or embeddings. Minor gaps for advanced use, but sufficient for standard workflows.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
