Skip to main content
Glama
Sign In

Padlet

by com.padlet
OverviewDiscussionsAdmin

Save Comments

save_comments
Destructive

Adds and edits comments on a padlet's posts. A comment_id starting with new_ adds a comment to post_id, and an existing comment's id replaces that comment's text. This tool cannot delete comments.

  • Returns { success: true }, plus created_comment_ids mapping each new_ id to the real comment id, and updated_comment_ids.

  • When some comments could not be saved, the result also has not_applied, a list of { comment_id, reason }. Tell the user which comments did not change and why, using the reason, and never say a listed change was made.

  • When the result has awaiting_approval_comment_ids, those comments wait for the padlet's approval or content check, so tell the user others cannot see them yet.

  • You can edit only comments you wrote, unless you are a moderator or admin of the padlet. Nobody can add or edit comments while the padlet is frozen.

  • A new comment takes text, an attachment, or both. An edit replaces only the text, so send the comment's full new text.

  • Take post_id and comment_id from the posts and comments get_padlet returns.

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>",
      "comments": "<comments>"
    },
    "name": "save_comments"
  }
}

Input Schema

NameRequiredDescriptionDefault
commentsYesComments to add or edit.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint, non-idempotent, openWorld), the description discloses the return contract (success plus created_comment_ids/updated_comment_ids), the partial-failure shape (not_applied with reasons and an instruction never to claim those changes were made), and the moderation state (awaiting_approval_comment_ids not visible to others). It also warns that an edit replaces text wholesale, which is the real destructive behavior the destructiveHint signals.

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?

Purpose and the add-vs-edit rule are front-loaded, and the bullet list keeps return-value and permission details scannable. The bullets are dense but each carries a distinct operational rule; only the approval bullet is slightly wordy.

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?

There is no output schema, so the description carries the return contract itself and does so fully, including the partial-failure and pending-approval cases. For a two-parameter mutation tool with nested comment objects, nothing an agent needs to call it correctly or report results accurately 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 would be 3, but the description adds semantics the schema does not: attachment is only for new comments, an edit replaces only text so the full new text must be sent, and post_id/comment_id should be sourced from get_padlet. Only minor detail (e.g. plain-text-only bodies, pattern constraints) is left to the schema.

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 opening sentence gives a specific verb pair and resource ("Adds and edits comments on a padlet's posts") and immediately bounds scope with "This tool cannot delete comments," which separates it from save_posts and delete_padlet_items. An agent can pick this tool without opening the schema.

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?

It states the selection rule between add and edit (a comment_id starting with new_ adds; an existing id replaces text), the permission condition (own comments only unless moderator/admin), and the blocking condition (frozen padlets). It also routes the agent to get_padlet as the source of post_id and comment_id, which is an explicit alternative path rather than an inference.

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