Skip to main content
Glama
Sign In
TMHSDigital

Local AI MCP

Official
by TMHSDigital
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Pull model

pull_model
Idempotent

Download a model onto a chosen local AI provider and stream download progress; omit the provider to let the server select one that can pull it.

Instructions

HEAVY: Download a model onto ONE provider (multiple GB, can take a long time). Streams download progress via MCP progress notifications when the client sends a progressToken. Without provider, uses the provider that already has the model, else the first live local provider that can pull.

Input Schema

NameRequiredDescriptionDefault
modelYesModel id/name to pull (e.g. qwen3:8b, hf.co/<repo>:<quant>)
providerNoProvider instance name. Omit to let the server choose (local providers only, unless LOCAL_AI_ALLOW_HOSTED_FALLBACK is set).

Output Schema

NameRequiredDescriptionDefault
pullYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.5.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / model / description
      Previous value: -"Model id/name to pull (download)"New value: +"Model id/name to pull (e.g. qwen3:8b, hf.co/<repo>:<quant>)"
    • changedInput schema / properties / provider / description
      Previous value: -"Optional provider id"New value: +"Provider instance name. Omit to let the server choose (local providers only, unless LOCAL_AI_ALLOW_HOSTED_FALLBACK is set)."
    • changedInput schema / properties / provider / enum
      Previous value: -[
-  "ollama",
-  "lmstudio",
-  "moonshot",
-  "openaicompat",
-  "llamacpp"
-]New value: +[
+  "ollama",
+  "lmstudio",
+  "llamacpp",
+  "dockermodelrunner"
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "pull": {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "pull"
+  ],
+  "type": "object"
+}
  2. First observedv0.4.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: warns of multi-GB weight and long duration, and discloses that progress is streamed via MCP progress notifications only when the client supplies a progressToken — an actionable detail no annotation conveys. Consistent with destructiveHint=false and idempotentHint=true. It stops short of saying whether the call blocks until completion or how failures midway are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, danger level front-loaded in a single token, then behavior, then parameter fallback logic. No filler and ordering matches how an agent needs to read it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and the long-running/progress mechanics are covered. The remaining gap is whether the call returns before the download finishes and what a partial failure leaves behind — for a multi-GB download that is a meaningful omission, though not a blocking one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so 3 is the floor, and the description earns the bump by detailing the server's provider-selection algorithm ('already has the model', then 'first live local provider that can pull'), which the schema only summarizes. The 'model' parameter gets no extra syntax detail beyond the schema's examples, but none was needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (download a model) and scopes it sharply: onto ONE provider, multiple GB, long-running. The 'HEAVY' prefix and the one-provider constraint immediately separate it from load_model, ensure_model, and remove_model in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It does explain the provider-omission case (reuse the provider already holding the model, else first live local provider), which is real routing guidance. But it never states when to prefer this over close siblings like ensure_model, which presumably also acquires a model, nor any preconditions or exclusions. Usage context is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools