Space Monkey Mailchimp Dashboard

Render prompt workflow

sm_get_prompt

Read-onlyIdempotent

Render one Space Monkey prompt workflow with concrete argument values, returning the complete instruction text ready to follow, plus the effective arguments that were bound (provided values plus defaults for omitted optionals). Prompt names and their arguments come from sm_list_prompts. If the rendered text still contains {{tokens}} such as {{projectId}} or {{company}}, a required argument was not provided; call again with it filled. The rendered text references sm_ tools by name; call them as instructed.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Prompt name from sm_list_prompts, e.g. sm_brief_before_call.
`arguments`	No	Argument values for the prompt, keyed by argument name (e.g. {"company": "Conversion Sciences", "email": "brian@example.com"}). Omit optional arguments to use their defaults. Multi-line values are supported.

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No	A machine-readable identifier for the error type. For the full code taxonomy, see the sm_get_schema tool or the Enterprise API OpenAPI ErrorResponse component.
`name`	No	Prompt name.
`text`	No	Rendered prompt body with values substituted.
`error`	No	A human-readable error message detailing what went wrong.
`arguments`	No	Argument values used for rendering.
`description`	No	Prompt description.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 11, 2026

changedOutput schema / description

Previous value: -"A single rendered prompt workflow and its effective arguments. Failure payloads arrive in the same envelope as { error, message, code }."New value: +"A single rendered prompt workflow and its effective arguments. Failure payloads arrive in the same envelope as { error, code }."

addedOutput schema / properties / arguments / description
```
Added value: +"Argument values used for rendering."
```
addedOutput schema / properties / description / description
```
Added value: +"Prompt description."
```
addedOutput schema / properties / name / description
```
Added value: +"Prompt name."
```

addedOutput schema / properties / text / description

Added value: +"Rendered prompt body with values substituted."

Changed1 schema field changedSep 10, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "A single rendered prompt workflow and its effective arguments. Failure payloads arrive in the same envelope as { error, message, code }.",
+  "properties": {
+    "arguments": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "code": {
+      "description": "A machine-readable identifier for the error type. For the full code taxonomy, see the sm_get_schema tool or the Enterprise API OpenAPI ErrorResponse component.",
+      "type": "string"
+    },
+    "description": {
+      "type": "string"
+    },
+    "error": {
+      "description": "A human-readable error message detailing what went wrong.",
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "text": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the non-obvious failure signal based on unresolved {{tokens}}, explains that the returned arguments include defaults, and clarifies that the output is the rendered instruction text rather than an execution result. This meaningfully improves an agent's ability to verify and recover from incomplete input.

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 four sentences are front-loaded with the core action and outputs, then address error detection and next steps. Every sentence earns its place with no redundant filler, keeping the definition informative without becoming bloated.

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?

Combined with the complete input schema, output schema, and annotations, the description covers valid prompt name sourcing, argument binding, missing-token failure handling, and subsequent tool usage. An agent has everything needed to invoke the tool correctly and respond to incomplete renders.

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%: both 'name' and 'arguments' already document their meaning, examples, and default behavior in detail. The description reinforces the source of names and the default-binding behavior, but adds no material parameter-level information beyond the schema, so the baseline 3 is appropriate.

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 'Render one Space Monkey prompt workflow with concrete argument values' – a specific verb, resource, and operation. It clearly defines outputs as 'complete instruction text ready to follow' plus 'effective arguments', and explicitly names sm_list_prompts as the source of names, which helps distinguish it from sibling listing tools.

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?

It provides clear operational context: obtain prompt names from sm_list_prompts, fill missing required arguments if {{tokens}} remain, and call referenced sm_ tools afterwards. It lacks an explicit 'do not use this when...' or direct comparison with alternatives, so it is not a perfect 5.

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

All Space Monkey Mailchimp Dashboard tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?