Skip to main content
Glama

Get Padlet

get_padlet
Read-only

Reads a padlet: its title, description, settings, sections, and posts with their comments. Read a padlet before changing it.

  • Returns { success: true, wall_url, padlet: {...} }. padlet.padlet_content holds the title, sections, posts and comments, padlet.padlet_settings the format (by the name create_padlet and update_padlet_layout take), sections, comments, reactions and attribution settings, and padlet.padlet_post_properties the post fields.

  • Posts come in the order they appear on the padlet. Each post has an editable field, and its post_id and section_id are what the post and section tools take.

  • include adds parts the content leaves out, for the padlet's admins. "access" adds access.access_settings: who can see and write, the password, listing and collaborators. "post_fields" adds post_fields: a copy of the post fields, and library_forbidden_attachment_types, the attachment types the padlet's library does not allow and update_padlet_post_fields cannot turn on.

  • Content settings (moderation, content protection and whether others may remake the padlet) are not here.

  • A part the user may not read comes back as { available: false, message }, and the rest still returns.

  • When the padlet itself cannot be read, only the refusal returns. Its message says why, and reason, when present, is trashed, archived, password or private.

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": "get_padlet"
  }
}

Input Schema

NameRequiredDescriptionDefault
includeNoParts to add to the padlet's content.
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.

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

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description adds substantial behavior the annotations cannot convey: the response envelope { success, wall_url, padlet }, per-part graceful degradation via { available: false, message }, and the refusal reasons (trashed, archived, password, private). It also discloses an important negative — content settings are not included — and notes post ordering matches the padlet view.

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 one-sentence summary followed by tight bullets, each covering a distinct concern (return shape, ordering, include, exclusions, partial failure, hard failure). Dense but every line carries information; only the repeated nesting of response-shape details in the first bullet is slightly heavy.

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 3-parameter tool with nested objects and no output schema, the description fully compensates by documenting the return structure, partial-availability semantics, ordering, and failure modes. Nothing an agent needs in order to call and interpret this tool correctly appears to be 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 a 3 would be the baseline, but the description goes further by explaining what each `include` value actually adds ('access' → access.access_settings with visibility, password, listing, collaborators; 'post_fields' → a copy of post fields plus library_forbidden_attachment_types and its interaction with update_padlet_post_fields). It also clarifies that post_id/section_id returned here are the identifiers other tools consume, adding cross-tool meaning beyond 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?

Opens with a specific verb and resource ('Reads a padlet') and enumerates exactly what is returned: title, description, settings, sections, and posts with comments. An agent can immediately distinguish this read tool from the write siblings (create_padlet, update_*, delete_*) without inspecting schemas.

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?

Explicitly states the sequencing rule 'Read a padlet before changing it,' which tells the agent when this tool is a prerequisite for mutation tools. It does not name sibling alternatives or say when NOT to use it (e.g. using find_padlets to discover a wall_url), so it falls short of full routing guidance.

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.