Skip to main content
Glama

models

Destructive

List, check, configure, or remove local embedding profiles for offline semantic, hybrid, and image search, verifying downloaded files against pinned hashes without network access.

Instructions

Local model profiles: bge-m3 (text) for semantic and hybrid search, and siglip-base (image) for search with image or imageRef. list shows the documented profiles with modality, model, revision, license and the files each needs; status reports each configured profile ready or unavailable with the reason, and the setup steps for each modality no profile serves; configure checks a model directory the user already downloaded against pinned SHA-256 digests, starts the figlens-embed shipped beside figlens once offline and records the profile; remove forgets the profile and keeps its files. Nothing is downloaded and no design content leaves the machine.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "models"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYeslist, status, configure or remove
profileNoconfigure and remove: a profile name from list
modelDirNoconfigure: the local directory holding the profile's files, inside the server's roots

Output Schema

NameRequiredDescriptionDefault
setupNostatus: the steps to configure a profile for each modality (text, image) no configured profile serves
removedNo
profilesNolist: name, modality, model, revision, license, files, configured, profileId, dataFlow; status: name, modality, profileId, model, runtime, dim, state ready or unavailable, code (runtime_missing, runtime_changed or model_missing), reason and recovery (models configure with the same files)
configRootNostatus: the config directory models.json lives in (ask write access to it before configure)
configuredNoconfigure: the recorded profile and its profileId
defaultRuntimeNostatus: {path, available} of the figlens-embed beside this figlens; available means the file exists, not that a model is ready

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.3

TDQS

A4/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description usefully narrows that risk by stating that remove 'keeps its files,' that configure operates offline against pinned digests, and that nothing is downloaded and no design content leaves the machine — genuine context the annotations do not carry. It stops short of describing what a failed digest check or a missing binary does to the recorded profile.

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

Conciseness3/5

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

It is front-loaded with the resource, which is good, but the entire body is a single ~110-word sentence chained with semicolons across four actions, making it slow to parse for an agent scanning for one action. Little is wasted word-for-word, but a per-action breakdown would be materially clearer for the same length.

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 and annotations cover the safety profile, so return-value and permission explanations aren't owed. The description accounts for all four enum values plus the offline/privacy posture, leaving only edge behavior (digest mismatch, profile already configured) unspecified.

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

Parameters3/5

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

Schema description coverage is 100%, so the enum and both optional parameters are already documented, including the 'inside the server's roots' constraint on modelDir. The description adds only the loose hint that a profile name comes 'from list'; it gives no syntax, path conventions, or behavior for a profile that is already configured. Baseline 3 applies.

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?

The description names the resource (local model profiles) and enumerates all four actions with a specific verb and outcome each: list shows documented profiles, status reports readiness and setup steps, configure verifies a local directory against SHA-256 digests and starts figlens-embed, remove forgets the profile. No sibling tool among inspect/workflow/index/jobs deals with model profiles, and the opening clause makes that separation obvious.

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

Usage Guidelines4/5

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

Each action carries its own condition of use: status is for checking readiness and for learning setup steps for modalities no profile serves, configure is for a directory the user has already downloaded, remove for discarding a profile. What is missing is any explicit 'use X before Y' sequencing (e.g. call list before configure) or a stated exclusion, so it falls short of the top band.

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