Skip to main content
Glama

Charming

by io.github.tambo-ai
OverviewDiscussionsAdmin

set_starter_prompt

Destructive

Set or clear an app's authored starter prompt — a short getting-started instruction prefilled in the chat host when a visitor clicks "Open in Claude" or "Open in ChatGPT" on the app, replacing the generic "I'm using this Charming app" body. Use this to frame a shared/remixable app's intended first action for visitors. Write a generic instruction — do NOT embed the app's URL: the app name, description, and URL (and, for unclaimed apps, an access token) are appended automatically at render time, so a hardcoded URL would point every remixer at the template instead of their own copy. Pass starter_prompt: null (or an empty string) to clear and revert to the generic default. Owner-only; anonymous apps must be claimed first. Idempotent (re-setting the same value is a no-op). Length cap: 2000 characters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
app_idYesThe app ID (UUID) whose starter prompt should change.
starter_promptYesGetting-started instruction the chat host receives when a visitor clicks "Open in Claude" / "Open in ChatGPT". The authored text leads; the app's name, description, URL, and (for unclaimed apps) an access token are appended automatically as context — so write a generic 1–3 sentence instruction (the first action you want the visitor to take, plus any persona/voice), NOT a self-contained prompt and NOT the app's URL. Pass null or "" to clear and revert to the generic default. Max 2000 characters.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesIndicates success. Errors arrive as content with isError:true.
messageYesConsequence copy the agent should surface to the user. Explains where the prompt is rendered (Open in Claude / Open in ChatGPT) and how to clear it.
advisoriesNoStructured non-fatal advisories, including authoring issues and unread staff feedback responses. Each advisory.summary is also appended to the text content for the LLM path.
starter_promptYesThe current starter prompt on the app row after this call. Null when the prompt was cleared (or normalized away from whitespace-only input). Otherwise the verbatim authored string.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / advisories
      Added value: +{
+  "description": "Structured non-fatal advisories, including authoring issues and unread staff feedback responses. Each advisory.summary is also appended to the text content for the LLM path.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "data": {
+        "additionalProperties": {},
+        "description": "Kind-specific structured payload. Shape varies per advisory kind.",
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "doc_url": {
+        "description": "Optional docs pointer for this advisory kind.",
+        "type": "string"
+      },
+      "kind": {
+        "description": "Stable advisory identifier (e.g. \"legacy-bridge\").",
+        "type": "string"
+      },
+      "severity": {
+        "description": "Severity; omitted advisories are treated as 'info'.",
+        "enum": [
+          "info",
+          "warn"
+        ],
+        "type": "string"
+      },
+      "summary": {
+        "description": "Agent-facing summary. Self-sufficient; no extra context required.",
+        "type": "string"
+      },
+      "userSummary": {
+        "description": "End-user-facing summary. Set when the advisory should render in-app.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "summary"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • removedOutput schema / properties / starter_prompt / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedOutput schema / properties / starter_prompt / type
      Added value: +[
+  "string",
+  "null"
+]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false, openWorldHint=true, and destructiveHint=true, but the description adds substantial behavioral context beyond those flags: it explains the automatic appending of name/description/URL/access token at render time, the idempotency (re-setting same value is a no-op), the length cap, and the owner-only requirement. It also clarifies that clearing reverts to the generic default. This is rich behavioral disclosure that goes well beyond the annotations.

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?

The description is dense but well-organized, front-loading the core purpose and then covering constraints, clearing behavior, ownership, idempotency, and length cap. Every sentence earns its place, though it is somewhat long. The structure is logical: purpose, usage guidance, anti-pattern warning, clearing semantics, access control, idempotency, and limit. Slightly verbose but not wasteful.

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?

Given the tool's complexity (mutation with ownership constraints, clearing semantics, and a critical anti-pattern about URLs), the description covers everything an agent needs to call it correctly: what to write, what to avoid, how to clear, who can call it, and the length limit. The output schema exists, so return values don't need explanation. The sibling list shows many app-related tools, and this description clearly distinguishes set_starter_prompt from them.

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 100%, so the schema already documents both parameters thoroughly. The description adds value by explaining the render-time auto-append behavior and the 'do NOT embed URL' rule, which directly informs how to fill starter_prompt. It also clarifies the null/empty-string clearing semantics. The only minor gap is that app_id semantics are fully covered by the schema, so the description doesn't add much there, but the starter_prompt guidance is strong.

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 states a specific verb ('Set or clear') and resource ('an app's authored starter prompt'), and explains the exact purpose: prefilling a getting-started instruction in the chat host when a visitor clicks 'Open in Claude' or 'Open in ChatGPT'. It clearly distinguishes this from generic app updates by focusing on the starter prompt behavior and even contrasts it with the generic default. This is unambiguous and differentiates the tool from siblings like update_app or mutate_app.

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?

The description gives explicit when-to-use guidance: 'Use this to frame a shared/remixable app's intended first action for visitors.' It also provides clear exclusions and constraints: do NOT embed the app's URL, write a generic instruction, pass null/empty string to clear, owner-only, anonymous apps must be claimed first, and idempotent behavior. This is comprehensive and leaves little to inference.

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

All Charming toolsInspect
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