Skip to main content
Glama
getsimba-ai

Simba MCP Server

Official
by getsimba-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Update Run

update_run
Destructive

Rename / annotate a saved optimizer or scenario run.

Instructions

Rename / annotate a saved optimizer or scenario run.

Runs are auto-named at creation (e.g. "GBP 1.2M · 12mo · Jan 5", or "1.2M · 12mo · Jan 5" when the model declares no currency); renaming makes run history carry the analysis ("holiday cut -10%", "stretch 130%"). Renaming permanently flips the run's auto_named flag to false so future auto-naming never overwrites it. Only the fields you provide are changed.

Args: artifact: "optimizer" (run_id "opt_...") or "scenario" ("scn_..."). model_hash: Hash of the model the run belongs to. run_id: The run's stable id from run history. name: New display name (non-empty when given; capped at 255 chars). notes: Free-text annotation. Omit to leave untouched; pass "" to clear. tags: Replacement tag list (max 20 tags, 64 chars each).

Input Schema

NameRequiredDescriptionDefault
nameNo
tagsNo
notesNo
run_idYes
artifactYes
model_hashYes

Output 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": "update_runDictOutput",
+  "type": "object"
+}
  2. First observedv0.3.2

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the annotations (destructive=true, non-idempotent, openWorld), the description discloses that renaming permanently flips auto_named to false so future auto-naming won't overwrite, and that omitted fields are left untouched while notes pass "" to clear. These are genuinely useful behavioral facts, though no permission/auth or error behavior is covered.

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?

Front-loads the core action and follows with examples and an Args block. Efficient and informative, though the Args section repeats constraints that could be tighter and the prose carries a little redundancy.

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?

An output schema exists so return values need not be explained, and the description fully covers the partial-update semantics, the auto-named side effect, and every parameter's constraints. Nothing an agent needs to invoke it correctly appears to be missing.

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?

With 0% schema description coverage the description must carry parameter meaning, and it does: artifact maps to opt_/scn_ prefixes, run_id is the stable id, name is non-empty capped at 255 chars, notes omission vs "" clearing, and tags is a replacement list capped at 20 tags/64 chars each.

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

Purpose4/5

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

States a specific verb+resource ('Rename / annotate a saved optimizer or scenario run') and clarifies scope via the artifact param. It distinguishes optimizer vs scenario runs, but does not explicitly differentiate itself from near-neighbors like rename_model or set_run_pinned.

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?

The description gives the rationale for renaming ('makes run history carry the analysis') with concrete examples, implying usage context. However it never states when to use this over alternatives such as set_run_pinned or list_runs, nor any prerequisites or exclusions.

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