Claude Desktop이 로컬 Ollama 서버를 쿼리하고 관리할 수 있게 합니다. 터미널을 열지 않고도 설치된 모델 목록 확인, 모델 검사, 로컬 모델에 대한 일회성 generate/chat 완성 실행, 또는 레지스트리에서 모델 가져오기/삭제를 수행할 수 있습니다.
일반적인 사용 사례: 동일한 프롬프트에 대해 Claude의 답변과 로컬 모델의 답변 비교, 양자화된 모델에 대한 저비용 대량 완성 실행, 또는 Ollama로 가져온 사용자 지정 학습 체크포인트 모델 확인 등이 있습니다.
실행 중인 Ollama 서버 (ollama serve 또는 Ollama 앱).
기본 엔드포인트는 http://localhost:11434입니다. Ollama를 다른 호스트나 포트에서 실행하는 경우 Claude Desktop의 확장 설정에서 ollama_url 사용자 구성을 통해 재정의하십시오.
npm 의존성 없음 — HTTP API를 통한 순수 Node.js.
Related MCP server: Ollama MCP Server
Releases 페이지에서 최신 Ollama.mcpb를 다운로드합니다.
Claude Desktop에서: 설정 → 확장 → 확장 개발자 → 확장 설치 → .mcpb 파일을 선택합니다.
(선택 사항) 확장 설정에서 Ollama를 기본값이 아닌 호스트/포트에서 실행하는 경우 Ollama server URL을 설정합니다. http://localhost:11434를 사용하려면 비워 두십시오.
도구 | 주석 | 목적 |
| 읽기 전용 | 상태 확인 + 서버 버전 |
| 읽기 전용 | 크기, 다이제스트, 패밀리, 파라미터 크기, 양자화가 포함된 로컬 모델 |
| 읽기 전용 | 현재 VRAM에 로드된 모델 |
| 읽기 전용 | 모델 세부 정보: modelfile, 파라미터, 템플릿, 기능 |
| 오픈 월드 | 일회성 텍스트 완성 (비스트리밍) |
| 오픈 월드 | 메시지 기록이 포함된 채팅 완성 (비스트리밍) |
| 오픈 월드 | 레지스트리에서 모델 다운로드 |
| 파괴적 | 로컬에 설치된 모델 제거 |
"설치된 로컬 모델은 무엇이며, 현재 VRAM에 로드된 모델은 무엇인가요?"
"이 프롬프트에 대해
forge:b6c1을 실행하세요: ''. 그 결과를 당신의 답변과 비교해 보세요.""
forge:b7c1의 modelfile을 보여주세요. 온도 설정을 확인하고 싶습니다.""
llama3.1:70b를 가져오세요." (대형 모델의 경우 오래 걸릴 수 있음)"
forge:b5c3모델을 삭제하세요. 더 이상 해당 체크포인트가 필요하지 않습니다."
이 확장은 전적으로 로컬 머신에서 실행되며 Ollama 서버(기본값 http://localhost:11434)로만 HTTP 요청을 보냅니다. 사용자가 명시적으로 ollama_url을 원격 Ollama 인스턴스를 가리키도록 구성하지 않는 한 데이터는 머신을 떠나지 않으며, 원격으로 설정한 경우에만 프롬프트와 응답이 해당 서버로 전송됩니다.
Claude가 볼 수 있는 정보는 다음과 같습니다:
generate 및 chat에 전달하는 모든 프롬프트와 채팅 메시지 (이 내용은 Ollama 서버로 전송되며, 서버 구성에 따라 로그가 남을 수 있습니다).
Ollama가 반환하는 완성된 텍스트 전체.
설치된 모든 모델의 메타데이터 (이름, 다이제스트, 크기, 양자화, modelfile 내용).
현재 VRAM에 로드된 모델 및 해당 모델의 크기 점유율.
독점적인 파인튜닝 모델이나 민감한 메타데이터가 포함된 modelfile을 설치한 경우, show_model 또는 list_models를 호출할 때 Claude가 해당 정보를 볼 수 있음을 유의하십시오.
delete_model은 파괴적이며 이 확장 프로그램에서 되돌릴 수 없습니다. 실수로 삭제한 경우 레지스트리에서 다시 가져오거나(또는 소스 블롭에서 다시 가져와야) 합니다.
"cannot reach Ollama at http://localhost:11434 — is the server running?" — ollama serve로 Ollama를 시작하거나 Ollama 앱을 실행하십시오. curl http://localhost:11434/로 확인하십시오 ("Ollama is running"이 반환되어야 합니다).
pull_model이 오랫동안 멈춤 — stream: false를 사용하는 Ollama의 pull API는 전체 다운로드가 완료될 때까지 차단되며, 다중 GB 모델의 경우 몇 분이 걸릴 수 있습니다. 대형 모델을 가져오는 경우 터미널에서 ollama pull <name>을 대신 실행하십시오. 거기서는 스트리밍 진행 상황을 볼 수 있으며, 이후 MCP 호출 시 모델이 이미 설치된 것을 확인할 수 있습니다.
사용자 지정/원격 Ollama 엔드포인트 — 확장 설정에서 ollama_url을 설정하십시오 (예: http://192.168.1.42:11434). 확장 프로그램을 다시 시작해야 합니다.
사용을 중단한 후에도 list_running에 모델이 표시됨 — Ollama는 구성 가능한 TTL(기본값 5분) 동안 모델을 VRAM에 유지합니다. expires_at 타임스탬프는 모델이 언로드될 시간을 알려줍니다. 이는 확장 프로그램이 아닌 Ollama의 동작입니다.
약 400줄의 단일 Node.js 스크립트이며, npm 의존성은 없습니다. .mcpb를 다시 빌드하려면:
cd bundle-source
zip -j ../Ollama.mcpb manifest.json package.json server.js README.md LICENSE icon.png glama.jsonMIT. LICENSE를 참조하십시오.
claude-terminal-mcp — 셸, 파일 시스템 및 백그라운드 작업.
claude-rocm-mcp — AMD GPU 모니터링; Ollama의 로드된 모델이 VRAM을 포화시키는지 확인하는 데 유용합니다.
claude-sessions-mcp — 장기 실행 작업을 위한 tmux 세션 관리.
claude-linux-mcp — X11 데스크톱 제어.
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.
