Skip to main content
Glama

Padlet

by com.padlet
OverviewDiscussionsAdmin

Get Padlet Content

get_padlet_content
Read-only

Get detailed content of a specific padlet including all posts, comments, sections, and settings.

  • Purpose: Retrieve the current state of a padlet before making updates, or fetch a padlet the user has pasted a URL for.

  • What this tool returns: { success: true, wall_url: "...", wall_public_key: "...", padlet: {...} } with complete padlet data including title, description, format, sections, and all posts with their content.

Guidance for use:

  • Use this tool after list_padlets to understand the current content before making changes.

  • The returned post_id and section_id values can be used in create_posts, update_posts, and update_section tools.

  • Posts are returned in the order they appear on the padlet.

  • Each post includes an editable field indicating whether the current user can edit that post.

  • Only returns the content if the current user has read access to the padlet.

  • When the padlet exists but cannot be read, the result includes reason: trashed, archived, password, or private. The message says whether the current user can restore or unarchive it, or whether its owner would need to. A missing padlet or a missing user gets message: "Unauthorized" with no reason.

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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • 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. Changed1 schema field changed
    • changedInput schema / properties / wall_url / description
      Previous value: -"The URL of the padlet to read (e.g. https://padlet.com/foo/bar-a1b2c3)."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."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, but the description layers on substantial context beyond them: access-control behavior, the specific failure reasons (trashed, archived, password, private), the 'Unauthorized' case for missing padlet/user, post ordering, and the per-post `editable` flag.

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-loads the action and the return shape, then uses bullets for guidance. Slightly verbose with a redundant 'Purpose' bullet echoing the first sentence, but nearly every line carries actionable information.

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?

No output schema exists, yet the description sketches the response envelope and failure modes, and it explains access preconditions. An agent has everything needed to call this and interpret both success and denial results.

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% and the wall_url description is already very rich (explicitly excludes breakout/submission links and ids). The description still adds the provenance hint that the URL may come from a previous call or a pasted link, which helps the agent source the value.

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?

States a specific verb and resource ('Get detailed content of a specific padlet') and enumerates scope: posts, comments, sections, settings. Clearly distinguishable from list_padlets and the many update_* siblings.

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?

Explicitly says when to use it: after list_padlets, before making changes, or for a pasted URL. It also names which downstream tools consume the returned post_id/section_id, routing the agent to correct follow-ups.

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