Skip to main content
Glama
getsimba-ai

Simba MCP Server

Official
by getsimba-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Unsave Model

unsave_model
Destructive

Free up a saved-model slot without deleting the model. Unsave a model to revert it to an unsaved state while keeping it accessible by hash, ideal for managing the 20-saved-models cap.

Instructions

Release a model's saved slot without deleting anything — the inverse of save_model (#673).

Use this for cap management: at the 20-saved-models cap, unsave a model that no longer earns its shelf spot instead of deleting it. The model reverts to the state API-created models start in (unsaved, no project; the name is kept) — it leaves the default listing and the dashboard's Saved Models but stays fully addressable by hash: fetchable, renameable, exportable, re-saveable, and visible via list_models with include_unsaved=true. Idempotent — unsaving an unsaved model is a success with freed_project_id null. delete_model remains failed-only.

Two caveats: the UNSAVED pool is auto-pruned by dashboard model creation (at 10+ unsaved models the oldest is hard-deleted, artifacts included), so re-save anything worth keeping rather than parking it unsaved long-term; and unsaving a shared model hides it from every recipient until it is saved again.

Args: model_hash: Hash of the model whose slot to release.

Returns: {model_hash, is_saved: false, freed_project_id}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_hashYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "unsave_modelDictOutput",
+  "type": "object"
+}
  2. First observedv0.3.2

TDQS

A4.2/5.0
Behavior1/5

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

The description is exemplary in disclosing side effects, idempotency, retention of hash addressability, and auto-pruning risks. However, the annotations state idempotentHint=false while the description explicitly says 'Idempotent — unsaving an unsaved model is a success.' This is a direct annotation contradiction, which per the rubric requires a score of 1.

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?

The description is long but every sentence earns its place: it front-loads the core purpose, then covers use case, state transitions, idempotency, return shape, and important caveats. The structured Args/Returns sections make the information easy to scan.

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 tool with one parameter and an output schema, the description covers everything needed: behavior, model state after unsaving, listing visibility, hash addressability, re-saving, idempotency, pruning caveat, shared-model caveat, and return fields. The only downside is the annotation contradiction, but the description itself is contextually complete.

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?

The single parameter model_hash has zero percent schema description coverage, but the description compensates fully by explaining it as 'Hash of the model whose slot to release.' This is precise and sufficient for an agent to populate the parameter correctly.

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 and resource: 'Release a model's saved slot without deleting anything' and explicitly frames it as the inverse of save_model. It clearly separates unsave_model from delete_model and save_model, making the tool's role 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 gives explicit when-to-use guidance: at the 20-saved-models cap, unsave instead of delete. It also states caveats for shared models and the auto-pruning of unsaved models, helping the agent decide whether this tool is appropriate in a given situation.

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