Skip to main content
Glama

Padlet

by com.padlet
OverviewDiscussionsAdmin

Update Padlet Post Properties

update_padlet_post_properties

Update the padlet (also known as wall)'s post properties like placeholders for subject, body, and attachment when create/update a post, enable/disable subject and body fields, which fields are required, etc.

  • Purpose: Update the padlet (also known as wall)'s post properties like placeholders for subject, body, and attachment when create/update a post, enable/disable subject and body fields, which fields are required, etc.

  • What this tool returns: { success: true, attachment_settings: } on successful update; otherwise a hash with success set to false and an optional message, e.g. { success: false, message: "..." }.

Guidance for use:

  • Include only the things you need to change under "post_properties".

  • Cannot require a field that is not enabled.

  • attachment_settings as an object is a per-type patch: only the listed types change and unlisted types keep their current value. Example: { "poll": false }.

  • attachment_settings true enables every attachment type the library permits; false disables attachments entirely.

  • photo_album needs at least one image source on (file, media_library, link, photo_booth, drawing, ai_image_search, image_search, gif_search). It is switched off when none is on.

  • device_uploads needs at least one device source on (file, photo_booth, video_recorder, audio_recorder, drawing, photo_album). It is switched off when none is on.

  • Attachment types the library forbids cannot be enabled and are always kept off.

Input Schema

NameRequiredDescriptionDefault
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.
post_propertiesYesThe post properties to update. Only include the properties you need to change.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / wall_url / description
      Previous value: -"The 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."New value: +"The 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."
  2. Changed3 schema fields changed
    • removedInput schema / properties / wall_id
      Removed value: -{
-  "description": "The id of the wall to update",
-  "type": "integer"
-}
    • addedInput schema / properties / wall_url
      Added value: +{
+  "description": "The 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.",
+  "maxLength": 2048,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "wall_id",
-  "post_properties"
-]New value: +[
+  "wall_url",
+  "post_properties"
+]
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

With annotations declaring readOnly=false, destructive=false and idempotent=false, the description still adds substantial behavioral detail beyond them: the exact return shape ({ success, attachment_settings } or { success: false, message }), the merge-patch semantics where unlisted types are preserved, and the hard constraint that library-forbidden types can never be enabled. It does not mention permission/auth requirements or what happens to fields omitted from required_fields, leaving a small gap.

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?

Front-loaded and organized into purpose / returns / guidance sections, with no filler in the guidance bullets. However, the 'Purpose:' bullet restates the opening sentence almost verbatim, which is pure duplication in an otherwise dense definition.

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?

For a mutation tool with a deeply nested 2-parameter schema and no output schema, the description covers the essentials: what's mutable, what gets returned, merge semantics, and validity constraints. The remaining gaps are auth/permission needs and whether previously-set-but-omitted properties are guaranteed untouched (implied, not stated).

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 baseline is 3, but the description genuinely adds semantics the schema lacks: the per-type patch behavior, the true/false shortcut for all attachment types, and the mutual-dependency rules (photo_album needs an image source on; device_uploads needs a device source on). Those rules are not expressed anywhere in the JSON Schema and directly affect how an agent should shape the payload.

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?

The description gives a specific verb+resource (update a padlet's post properties) and enumerates the concrete scope: placeholders, enabling/disabling subject/body, and required-field rules. It doesn't distinguish itself from adjacent settings tools such as update_padlet_content_settings or update_padlet_settings, nor does it name get_padlet_post_properties as the read counterpart, so it's clear but not sibling-differentiated.

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 'Guidance for use' block gives real usage conditions: send only the properties you want changed, cannot require a field that isn't enabled, boolean vs. per-type object semantics for attachment_settings, and the dependency rules for photo_album and device_uploads. What's missing is routing guidance against alternatives (e.g., read current state with get_padlet_post_properties first, or use update_padlet_content_settings for other wall settings).

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

All Padlet 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