Skip to main content
Glama

model_metadata

Curate a model's embedded metadata: read current fields, fetch Civitai data, and propose clean updates for review.

Instructions

Curate a model file's embedded .safetensors metadata (Model Explorer). Driven by the action parameter:

  • action:"read" — Read a model file's CURRENT embedded metadata + evidence, for curating it. Returns classify (asset_type/base/precision/rank), the current model_card and prompt_director namespaces, read-only modelspec, top training tags (ss_tag_frequency), the Civitai description, and example prompts. Call this FIRST when the user wants to improve/curate a model's embedded .safetensors metadata, so you propose from real data. NOTE: this is the embedded-in-the-tensor metadata (model_card/prompt_director/modelspec/ss_*) — NOT the separate lora_catalog. category = ComfyUI model folder ('loras','checkpoints','vae',…); name = filename incl. .safetensors — BOTH required for read/propose, e.g. {action:"read", category:"loras", name:"my_model.safetensors"}. DEPENDENCY: the curated read proxies the OPTIONAL 'comfyui-model-explorer' custom node. When that node is absent but the model file is reachable on the LOCAL filesystem, the tool does NOT hard-fail — it degrades to a structured 'model_explorer: unavailable' result with local evidence (file stat, the download_model action:"download_civitai" sidecar, and the raw embedded safetensors metadata). Without local filesystem access, it still returns the same structured unavailable result, but without file evidence.

  • action:"propose" — PROPOSE cleaned embedded metadata into the user's diff-review window. This does NOT write the file — the user sees your proposed fields vs current, edits/discusses, and their Confirm does the write. Call whenever you have a proposal OR the user asks you to revise one; each call REPLACES the live proposal, so send the FULL field set you're proposing. Include only fields you're confident about. Keys: display_name, description_clean, semantic_intent, prompt_guidance, preservation_guidance, trigger_tokens[] (EXACT tokens — never invent), activation_phrases[], negative_tokens[], tags[], compatible_families[], default_strength_model, default_strength_clip, strength_min, strength_max. NEVER write metadata directly.

  • action:"fetch_civitai" — READ-ONLY: pull this model's data from Civitai (civitai.com) — the rich description, trainedWords, example prompts (with the prompt text used in the sample images), tags, nsfw flag, and source_url — WITHOUT writing anything. Call this when the embedded metadata is thin (empty model_card/prompt_director, no ss_tag_frequency) or to flesh out details before proposing. Treat the result as RAW input: distill the (often marketing-heavy) description, and MINE THE EXAMPLE PROMPTS for the real trigger — the trigger is frequently ONLY in the sample prompts even when trainedWords is EMPTY (e.g. every prompt starting with 'photo in the style of X' means X is the trigger). Adult models (civitai.red) resolve through this same API. Then clean it up and call action:"propose". DEPENDENCY: automatic by-hash lookup uses the OPTIONAL 'comfyui-model-explorer' custom node. If that node isn't installed, pass 'version_id' (the CivitAI modelVersionId) and this action degrades to CivitAI's public REST API directly — no node, no auth. Without both the node AND a version_id it returns a clear 'optional feature unavailable' message rather than enriching.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNomodel filename incl. .safetensors. REQUIRED for all three actions.
noteNoaction:"propose" — optional one-line note about this revision.
actionYesWhich metadata operation to perform. All three actions require `category` + `name`; "propose" also requires `fields` (optional `note`); "fetch_civitai" takes an optional `version_id`.
fieldsNoaction:"propose" — REQUIRED proposed field map (see description).
categoryNoComfyUI model folder, e.g. 'loras'. REQUIRED for all three actions.
version_idNoaction:"fetch_civitai" — force a specific Civitai modelVersionId if hash lookup misses.
Behavior5/5

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

No annotations are provided, so the description carries full burden, and it excels: it states read is non-destructive, propose 'does NOT write the file' and 'NEVER write metadata directly,' and fetch_civitai is 'READ-ONLY... WITHOUT writing anything.' It also discloses degradation behavior when the optional node is absent and warns that propose REPLACES the live proposal, requiring full field sets.

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

Conciseness4/5

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

The description is lengthy but efficiently structured with bullet-pointed actions and bolded key terms. It front-loads the primary purpose and each action gets focused guidance; the density of information justifies the length, though it could be tightened slightly.

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

Completeness5/5

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

For a complex three-action tool with no output schema, the description is remarkably complete: it enumerates the read return fields (classify, model_card, prompt_director, modelspec, ss_tag_frequency, etc.), describes propose behavior (diff-review window, no write), and details fetch_civitai's data and mining advice. Dependencies and failure modes are explicitly covered.

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

Parameters5/5

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

Schema coverage is 100%, yet the description adds significant meaning beyond schema: it specifies which params are required per action ('BOTH required for read/propose'), provides an example call, explains the `fields` object for propose, and details the `version_id` fallback. It also clarifies that `note` is optional.

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 opens with a specific verb+resource: 'Curate a model file's embedded .safetensors metadata (Model Explorer).' It clearly distinguishes itself from sibling tools by noting 'NOT the separate lora_catalog' and details three distinct actions (read/propose/fetch_civitai), making its scope unambiguous.

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

Usage Guidelines5/5

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

It provides explicit when-to-use guidance for each action: 'Call this FIRST...' for read, 'Call whenever you have a proposal...' for propose, and 'Call this when the embedded metadata is thin...' for fetch_civitai. It also names a sibling dependency ('download_model action:'download_civitai' sidecar') and clarifies when not to use it via the lora_catalog exclusion.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/artokun/comfyui-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server