Skip to main content
Glama

sim_prompt

Destructive

Ask an LLM to derive something from a stored entity: a variant model, a report, a piece of generated code — whatever the prompt asks for. The parent's JSON rides along as context after a fixed instruction: answer a request for a new or changed model with only the complete model JSON (the shape sim_create_model takes), and anything else in plain text or markdown. The parent is looked up as a model first, then a prompt, then an artifact, then a map — whichever resolves — and the context block is labelled by what kind it found ("## Parent model", "## Parent prompt", ...), so the LLM is never told a report is a Petri net. When the parent is a prompt with no requestTemplate, its text and system are withheld from its readers (sim_get_artifact says why), and so is the content of an artifact such a prompt produced; unless you are its author, the LLM gets the document sim_get_artifact serves in its place, without them. The prompt is stored first and content-addressed like a model, so it has an id of its own before the LLM ever answers; both the prompt and whatever came back are placed in lineage under the parent (sim_prompt as the activity), so Ancestry walks parent -> prompt -> result. A Relation{prompt, "produced", result} is recorded alongside — sim_reroll's forward index, and queryable directly via sim_edges/sim_neighbors. Returns promptId, id, kind and url. A reply that decodes and passes the validation sim_create_model applies is stored as a NEW model you own (kind "model"; read it with sim_get_model), with warnings, when there are any, saying what sim_create_model would warn about it (a transition left at the default rate, a guard no run enforces, staff taken and given back in one firing, ...). Any other reply is stored as an artifact (kind "artifact") and returned inline as content, cut at 16384 bytes with truncated: true and contentBytes (the whole reply's length) when longer; sim_get_artifact reads all of it. When that reply held model JSON (an object with places or transitions) that failed to decode or validate, modelErrors lists every reason at once, as sim_create_model words its refusal (a key repeated across elements once, at most 20 of each kind with the rest counted). Needs sign-in (opens OAuth the first time). Refused if this deployment has no LLM provider configured. The stored prompt, text and system both, is readable without sign-in through sim_get_artifact by anyone who has its promptId or the id of anything derived from it, since lineage names the prompt behind every result: leave out of text and system what you would not share with whoever gets a result's id.

Input Schema

NameRequiredDescriptionDefault
textYesthe natural-language instruction; stored with the prompt, and readable by anyone with its id or a result's
parentYesid to run the prompt against — a model, prompt, artifact, or map
systemNooptional system-level instructions, in addition to the parent context this tool always supplies; stored with the prompt, and readable by anyone with its id or a result's

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / system / description
      Previous value: -"optional system-level instructions, in addition to the parent context this tool always supplies"New value: +"optional system-level instructions, in addition to the parent context this tool always supplies; stored with the prompt, and readable by anyone with its id or a result's"
    • changedInput schema / properties / text / description
      Previous value: -"the natural-language instruction"New value: +"the natural-language instruction; stored with the prompt, and readable by anyone with its id or a result's"
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Despite annotations already declaring a destructive, non-idempotent, open-world write, the description adds substantial unannotated behavior: OAuth sign-in requirement, refusal when no LLM provider is configured, content-addressing and lineage placement (Ancestry walks parent -> prompt -> result), the Relation{prompt, produced, result} edge, 16384-byte truncation with truncated/contentBytes, and the privacy caveat that stored prompt text is publicly readable via sim_get_artifact.

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?

Purpose is front-loaded in the first clause, but the body is one very long, parenthesis-heavy passage with nested asides and redundancy (the prompt-readable-by-anyone caveat appears twice). Much of it earns its place, but the structure taxes comprehension.

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?

With no output schema, the description fully carries the return contract (promptId, id, kind, url; inline content; modelErrors), plus failure modes (no LLM provider, decode/validation failure), storage/lineage behavior, and a privacy warning. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100%, so the schema already documents all three params, making 3 the baseline. The description lifts this above baseline by explaining what 'parent' actually resolves to (model, then prompt, then artifact, then map) and how the resolved kind labels the context block, plus the retention/readability of text and system.

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?

States a specific verb and resource — 'Ask an LLM to derive something from a stored entity' — and immediately enumerates the outputs (variant model, report, generated code). It distinguishes itself from siblings by naming sim_create_model's schema, sim_get_model, sim_get_artifact, and sim_reroll.

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?

The description gives strong context: it explains parent resolution order (model -> prompt -> artifact -> map), the reply handling (model JSON vs. plain text/markdown), and points to sim_get_model / sim_get_artifact for reading results. It stops short of explicit 'use this instead of X when Y' exclusion language, but the routing context is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources