Skip to main content
Glama

render_prompt

Read-onlyIdempotent

Substitute variables into a prompt template and return the final messages without calling the model, so you can verify output before a completion.

Instructions

Render a prompt by substituting variables and returning the final messages without calling the model. Use this to verify template output before a completion; run_prompt_completion is the tool that actually invokes the model.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prompt_idYesPrompt ID or slug to render
variablesYesVariable values to substitute into the template
hyperparametersNoOverride default hyperparameters

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesWhether the tool call succeeded and returned structured data
dataNoStructured success payload when ok is true
errorNoStructured error payload when ok is false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.12.2
    • removedInput schema / properties / variables / additionalProperties / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "boolean"
      -  }
      -]
    • addedInput schema / properties / variables / additionalProperties / type
      Added value: +[
      +  "string",
      +  "number",
      +  "boolean"
      +]
  2. Addedv1.0.1
  3. Removed
  4. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely new behavior: no model call is made, so there is no completion cost or latency side effect. It stops short of describing error behavior for unresolvable variables or missing prompt IDs.

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?

Two sentences, zero waste. The core behavior is front-loaded and the disambiguation against the sibling follows immediately.

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 no explanation, and the safety profile is carried by annotations. Purpose, routing, and the no-model-call behavior are all present, leaving nothing an agent needs missing.

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

Parameters3/5

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

Schema description coverage is 100%, so prompt_id, variables, and the nested hyperparameters are all documented in the schema. The description only restates that variables are substituted, adding no format or edge-case detail beyond the structured fields.

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 ('Render a prompt by substituting variables') plus the exact output ('returning the final messages'), and explicitly distinguishes itself from the sibling run_prompt_completion. An agent can select it without opening the schema.

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?

Gives an explicit when-to-use case ('verify template output before a completion') and names the alternative tool that actually invokes the model. Both the use condition and the exclusion are stated.

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