Model Salt

model_salt

Read-only

Call this before any creative or open-ended request (an image, a picture prompt, a story, a poem, a name, an idea, a design, a plan), so the result is varied instead of your usual answer and still exactly what was asked. First call: send the user's request word for word in request (and randomness only if the user asked for more or less variety). It returns an exploring step and an id. Do that step silently, without showing it to the user, and call this tool again with the id and your whole reply to the step in explored. The second call returns what was decided. Then make the result itself in the same reply: for a request for an image, generate the image with your image generation tool and show it (a written prompt is not the result); for writing, write it. The result shows every decided answer.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "model_salt"
  }
}

Input Schema

Name	Required	Description
`id`	No	Second call: the id the first call returned.
`keep`	No	First call, optional: Only when the user wants to keep part of an earlier Model Salt result and vary the rest ("keep the palette and layout", "same colours, new drawings", or a pasted `Kept:` line): the decided answers they want kept, copied from that earlier Model Salt reply, one item each as "<what> = <answer>", e.g. "palette = burnt orange on cream". If the last Model Salt reply began with a `Kept:` line, send its items again on every later call for this work, until the user says to start fresh. Leave it out when the user wants something new, another one, or a fresh start.
`request`	No	First call: the user's request, word for word.
`explored`	No	Second call: your whole reply to the exploring step, its answer lines with their shares and the final ```json block included.
`randomness`	No	First call, optional: how varied the result should be: 0 the usual answer, 1 clearly varied (the default), 2 as varied as it gets. Leave it out unless the user asks for more or less variety.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare the safety profile (read-only, non-destructive, non-idempotent), and the description adds substantial behavior beyond that: a mandatory two-call protocol, the requirement to perform the exploring step silently without showing the user, and the obligation to produce the actual artifact (image via generation tool, or written text) after the second call. It also clarifies that a written prompt is not an acceptable substitute for a generated image, which is a non-obvious behavioral constraint.

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-loaded with the triggering condition, then ordered by first call, second call, and final output, which matches the agent's execution sequence. It is dense but nearly every clause carries operational meaning; the long parenthetical example lists and the `keep` persistence rule make it heavier than necessary.

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?

For a multi-step, stateful protocol with no output schema and zero required parameters, the description supplies the full workflow, both return values ('an exploring step and an `id`', 'what was decided'), and the post-call obligation to render the artifact. The only residual vagueness is what 'the decided answers' concretely look like, though the `explored` parameter description partially covers that.

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 description coverage is already 100% and each parameter is well documented in-schema. The description adds procedural meaning the schema cannot convey — that `request` is used on the first call only, `id` and `explored` on the second, and that `explored` must contain the entire reply including share lines and the final JSON block. Minor duplication of schema text, but the call-ordering semantics are genuinely additive.

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?

The description states a specific purpose: call before creative/open-ended requests (image, story, poem, name, idea, design, plan) so output is varied rather than the model's default answer. It also explains the mechanism (two-call exploration returning an id, then a decided answer), so the agent knows what the tool is and roughly how it behaves. The metaphor 'Model Salt' is never directly defined, but the surrounding text makes the function 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?

Explicit when-to-use ('before any creative or open-ended request'), explicit per-call procedure (first call with `request`, second call with `id` and `explored`), and explicit when-not guidance for `keep` ('leave it out when the user wants something new, another one, or a fresh start') and `randomness` ('leave it out unless the user asks for more or less variety'). No sibling tools exist, so no alternative routing is needed.

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

All Model Salt tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.