Skip to main content
Glama

Update Padlet Heading

update_padlet_heading
Destructive

Changes a padlet's title, description and icon.

  • Give icon or icon_image_url, not both.

  • Pass only the settings that should change.

  • Returns { success: true, applied: [part, ...] }. A part listed under not_applied, as { part, code, reason }, did not change: tell the user why, and never say it changed. When no part changed, success is false and the message gives each part's reason.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wall_url": "<wall_url>"
    },
    "name": "update_padlet_heading"
  }
}

Input Schema

NameRequiredDescriptionDefault
iconNoA query to search for an icon, prefer short and simple queries like 'train', 'car' if you think there is an emoji that can be used since we search both online images and an emoji manifest.
titleNoUpdate the title of the padlet.
wall_urlYesThe padlet's link (e.g. https://padlet.com/foo/bar-a1b2c3): the link you were given, the `wall_url` a previous call returned, or a link the user pasted. Not a breakout-room or submission link, and not a padlet id: no tool takes a wall_id.
telemetryNoOptional. Padlet records this to improve its tools; it does not change what the tool does.
descriptionNoUpdate the description of the padlet. Not supported for sandbox/whiteboard padlets.
icon_image_urlNoA picture to use as the icon: the url an upload tool returned, or a public https address of an image.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / telemetry
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Optional. Padlet records this to improve its tools; it does not change what the tool does.",
      +  "properties": {
      +    "intent": {
      +      "description": "Explain the task and why you are calling this tool. Omit full queries, large inputs, personal information, and secrets.",
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  2. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, and the description goes meaningfully beyond them by specifying the response contract: { success, applied }, per-part not_applied entries with code and reason, and success=false when nothing changed, plus the instruction never to claim an unapplied change. It does not disclose reversibility, permission requirements, or what the destructive aspect actually entails, so a full 5 is not warranted.

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 core purpose is front-loaded in one sentence, then the operational rules are bulleted for scannability. The return-handling sentence is longer than the others but its content (failure reporting) is genuinely load-bearing rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With six parameters, a nested telemetry object, and no output schema, the description carries the right extra burden: it documents the return shape and partial-failure behavior that the schema cannot express. Gaps remain around reversibility and required permissions for a tool flagged destructive, but nothing essential to correct invocation is 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?

Schema coverage is 100%, so the baseline is 3; the description earns a bump by adding the icon/icon_image_url mutual-exclusion constraint, which appears nowhere in the schema, and by clarifying that omitted settings are left untouched. It adds no detail on the telemetry object or on wall_url formats, but those are already documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Changes a padlet's title, description and icon" gives a specific verb plus the exact editable fields, which implicitly separates it from siblings like update_padlet_sharing or update_padlet_layout. It never names a sibling or explicitly rules out update_padlet_appearance, which is the nearest neighbor given the icon parameter, so differentiation is left partly to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Two concrete invocation rules are stated: "Give icon or icon_image_url, not both" and "Pass only the settings that should change" (partial-update semantics). However there is no guidance on when to prefer this tool over update_padlet_appearance or other update_* siblings, and no stated prerequisites, so selection guidance is implied rather than explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.