Space Monkey Mailchimp Dashboard

List prompt workflows

sm_list_prompts

Read-onlyIdempotent

List the Space Monkey prompt workflows: user-invocable recipes that chain sm_ tools into this week's sales actions (build call sheets, strike after a send, save cooling leaders, harvest an event, brief before a call). Each entry lists its arguments and its category. Use sm_get_prompt to render one with concrete argument values, then follow the rendered instructions to run the workflow.

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": "sm_list_prompts"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output 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.
`error`	No	A human-readable error message detailing what went wrong.
`prompts`	No	Prompt workflow rows.
`version`	No	Version string for the enclosing catalog or document.
`lastUpdated`	No	ISO 8601 instant the underlying data was last refreshed.
`promptCount`	No	Number of prompts in the catalog.
`catalogSource`	No	Source descriptor for the enclosing catalog.

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedSep 11, 2026
- changedOutput schema / description
```
Previous value: -"Flattened catalog of available prompt workflows. Failure payloads arrive in the same envelope as { error, message, code }."New value: +"Flattened catalog of available prompt workflows. Failure payloads arrive in the same envelope as { error, code }."
```
- addedOutput schema / properties / catalogSource / description
```
Added value: +"Source descriptor for the enclosing catalog."
```
- addedOutput schema / properties / lastUpdated / description
```
Added value: +"ISO 8601 instant the underlying data was last refreshed."
```
- addedOutput schema / properties / promptCount / description
```
Added value: +"Number of prompts in the catalog."
```
- addedOutput schema / properties / prompts / description
```
Added value: +"Prompt workflow rows."
```
- addedOutput schema / properties / prompts / items / properties / arguments / description
```
Added value: +"Prompt arguments with metadata."
```
- addedOutput schema / properties / prompts / items / properties / arguments / items / properties / description / description
```
Added value: +"Argument description."
```
- addedOutput schema / properties / prompts / items / properties / arguments / items / properties / name / description
```
Added value: +"Argument name."
```
- addedOutput schema / properties / prompts / items / properties / arguments / items / properties / required / description
```
Added value: +"True when the argument is required."
```
- addedOutput schema / properties / prompts / items / properties / arguments / items / properties / ui / description
```
Added value: +"Suggested input control."
```
- addedOutput schema / properties / prompts / items / properties / category / description
```
Added value: +"Sales-stage category."
```
- addedOutput schema / properties / prompts / items / properties / description / description
```
Added value: +"Prompt description."
```
- addedOutput schema / properties / prompts / items / properties / name / description
```
Added value: +"Prompt name."
```
- addedOutput schema / properties / prompts / items / properties / title / description
```
Added value: +"Prompt title."
```
- addedOutput schema / properties / version / description
```
Added value: +"Version string for the enclosing catalog or document."
```

Changed1 schema field changedSep 10, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Flattened catalog of available prompt workflows. Failure payloads arrive in the same envelope as { error, message, code }.",
+  "properties": {
+    "catalogSource": {
+      "type": "string"
+    },
+    "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"
+    },
+    "error": {
+      "description": "A human-readable error message detailing what went wrong.",
+      "type": "string"
+    },
+    "lastUpdated": {
+      "type": "string"
+    },
+    "promptCount": {
+      "type": "number"
+    },
+    "prompts": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "arguments": {
+            "items": {
+              "additionalProperties": true,
+              "properties": {
+                "description": {
+                  "type": "string"
+                },
+                "name": {
+                  "type": "string"
+                },
+                "required": {
+                  "type": "boolean"
+                },
+                "ui": {
+                  "type": "string"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "category": {
+            "type": "string"
+          },
+          "description": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "version": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 10, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe/read-only nature is covered. The description adds useful behavioral context: these are user-invocable recipes that chain sm_ tools and require following rendered instructions to execute, which indicates this tool only lists metadata rather than running workflows.

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 description is two sentences with no filler. It front-loads the action and resource, gives illustrative examples, and ends with a practical next step, all in a compact and scannable structure.

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?

For a zero-argument, read-only list tool with a rich annotation set and an output schema, the description provides everything an agent needs: what is listed, what each entry contains, and how to proceed with sm_get_prompt. No critical behavioral or usage details are 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?

The tool has zero input parameters and 100% schema coverage, so there are no parameter semantics for the description to clarify. The description still adds relevant context by noting that each returned entry lists its arguments and category, which is helpful for understanding the output.

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 uses a specific verb ('List') and a specific resource ('Space Monkey prompt workflows'), and distinguishes this tool from the sibling sm_get_prompt by framing listing vs. rendering. It also gives concrete examples of what these workflows are, so an agent can identify the tool's purpose without ambiguity.

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 explicitly directs the agent to use sm_get_prompt after listing, saying to render one with concrete argument values and then follow the rendered instructions. This provides clear routing to the relevant sibling, though it does not enumerate when not to use this tool relative to other list tools.

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?