Charming

rename_app

Change a Charming app's URL slug — the human-readable, URL-safe name, distinct from its title/displayName and from its machine manifest id. Use this to give an app a different public URL. Titles and slugs are independent: editing the title with update_app does not change the slug; this tool does. Renaming changes the public URL, and the old URL keeps working by redirecting to the new one. Slug rules: lowercase letters, digits, and hyphens; 2-48 chars; may start with a letter or digit; no leading, trailing, or consecutive hyphens. When telling the user where to open or share the renamed app, always give them shareUrl from the result — never the url field, which is machine-only and embeds a write-capable access token.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`app_id`	Yes	The app ID (UUID) to rename.
`app_name`	Yes	The new URL slug. Lowercase letters, digits, and hyphens; 2-48 chars; may start with a letter or digit; no leading/trailing or consecutive hyphens. Input is lowercased and trimmed.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	UUID of the renamed app.
`ok`	Yes	Indicates success. Errors arrive as content with isError:true.
`url`	Yes	Machine/API URL for the app (stable /app/<uuid> form). Reflects the new slug.. Embeds a write-capable ?t= access token — NEVER show, paste, or send it to the user. Append /api/<op> to its path for out-of-band operation calls. For anything user-facing, use shareUrl instead.
`appName`	Yes	The new live slug for the app.
`shareUrl`	Yes	The link to give humans whenever the user wants to open or share the app. Friendly /<handle>/<app-name> form when the OWNER has a live handle and the app a slug, /app/<uuid> otherwise. Always token-free — safe to show, paste, and send. Not an API base: appending /api/<op> to the friendly form 404s; use `url` for machine calls.
`advisories`	No	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.
`previousAppName`	Yes	The slug the app had before this rename. Retained as an alias so old URLs keep resolving (a redirect to the new slug).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 10, 2026

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"
+}

First observedJul 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond annotations, the description explains that renaming changes the public URL, old URLs redirect, and the url field is machine-only with a write-capable token (a serious security-relevant behavioral note). It also implies a mutating operation without destructive side effects, consistent with readOnlyHint=false and destructiveHint=false.

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 slightly long, but each sentence contributes meaningful information: identity distinction, redirect behavior, slug rules, and security guidance. The key usage guidance is front-loaded before the slug validation rules.

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 mutating tool with output schema, it fully covers the operation's semantics, parameter meaning, security-relevant urn field warning, and redirect behavior. It even teaches the safe way to share URLs, which closes the loop on how an agent should use the result.

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 schema already covers both parameters with 100% coverage, including slug constraints and lowercasing/trimming. The description adds semantic value by contrasting the slug with title/displayName and machine id, and ties the result's shareUrl to usage guidance.

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 clearly identifies the specific operation (

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 text gives direct guidance: it contrasts this tool with update_app by stating that editing the title via update_app does not change the slug, while this tool does. It also specifies the context (giving an app a different public URL) and the fact that the old URL redirects, so an agent can choose correctly.

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

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