Skip to main content
Glama

Update Padlet Post Fields

update_padlet_post_fields

Changes what a post on a padlet asks for: which fields and attachment types are on, their placeholders, which are required, and new custom fields.

  • A field must be on before it can be required.

  • photo_album needs one of file, media_library, link, photo_booth, drawing, ai_image_search, image_search, gif_search on, and device_uploads one of file, photo_booth, video_recorder, audio_recorder, drawing, photo_album. Each is switched off when none is. An attachment type the library forbids stays off.

  • custom_fields adds fields to every post. A name the padlet already has is left as it is. This tool cannot delete custom fields.

  • The answer also gives attachment_settings, the attachment types now on, and created_custom_field_ids, the ids of the new custom fields.

  • 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_post_fields"
  }
}

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.
telemetryNoOptional. Padlet records this to improve its tools; it does not change what the tool does.
body_enabledNoWhether to enable the body field when create/update a post
color_enabledNoWhether to enable post color when create/update a post
custom_fieldsNoAdd custom fields that show up as named sub-sections in the body of each post. Only add custom fields if they serve a clear purpose.
attachment_textNoText to describe the attachment that should be added to each post. Should not be longer than 100 characters.
required_fieldsNoThe required fields when create/update a post
subject_enabledNoWhether to enable the subject field when create/update a post
body_placeholderNoThe placeholder for the body field when create/update a post. Should not be longer than 2000 characters.
location_enabledNoWhether to enable geolocation for a post when create/update a post
ar_lenses_enabledNoWhether to enable AR lenses when adding images to a post
video_length_limitNoThe maximum length of a video attachment in seconds
attachment_settingsNoWhich attachment types are enabled when create/update a post
subject_placeholderNoThe placeholder for the subject field when create/update a post. Should not be longer than 200 characters.

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. Changed5 schema fields changed
    • changedInput schema / properties / custom_fields / items / properties / field_type / description
      Previous value: -"The type of the custom field. Use 'single_select' for dropdowns (requires selection_options), 'vote' for upvote/downvote, 'rating' for star ratings (1-5), 'score' for numeric scores (0-100)."New value: +"The type of the custom field. Use 'single_select' for dropdowns where a post picks one option and 'multi_select' where a post may pick several (both require selection_options), 'vote' for upvote/downvote, 'rating' for star ratings (1-5 unless max_rating is set), 'score' for numeric scores (0-100)."
    • changedInput schema / properties / custom_fields / items / properties / field_type / enum
      Previous value: -[
      -  "text",
      -  "number",
      -  "date",
      -  "single_select",
      -  "vote",
      -  "rating",
      -  "score"
      -]New value: +[
      +  "text",
      +  "number",
      +  "date",
      +  "single_select",
      +  "multi_select",
      +  "vote",
      +  "rating",
      +  "score"
      +]
    • addedInput schema / properties / custom_fields / items / properties / max_rating
      Added value: +{
      +  "description": "Only for field_type 'rating': the number of stars. Defaults to 5.",
      +  "maximum": 10,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / custom_fields / items / properties / required
      Added value: +{
      +  "description": "Whether a post must fill in this field before it can be published. Defaults to false. Not allowed for vote, rating, or score fields.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / custom_fields / items / properties / selection_options / description
      Previous value: -"Options for the single-select dropdown custom field. Only add options if field_type is 'single_select'."New value: +"Options for a 'single_select' or 'multi_select' field. Only add options for those field types. A 'multi_select' field takes at most 10 options of up to 30 characters each."
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (non-read-only, non-destructive, non-idempotent), it discloses hard cross-field rules (a field must be enabled before it can be required; photo_album and device_uploads need specific companion types and switch off when none remain), library-forbidden types staying off, and that custom_fields cannot be deleted and same-named fields are left untouched. It also documents the exact return contract, including partial application via not_applied entries with code and reason and success=false when nothing changed.

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 one-line summary is front-loaded and the bulleted rules follow in a logical dependency-then-behavior order with no filler. It is dense but long, and the return-value bullet could be tightened, so it is efficient rather than exemplary.

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 14-parameter nested mutation with no output schema, the definition covers the behaviors an agent most needs: partial-failure semantics, dependency constraints, nested attachment_settings patching, and the response shape including created_custom_field_ids. It does not address whether changes take effect immediately for end users or any permission requirements, which are the remaining gaps for a write tool.

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, but the description adds real meaning the schema does not carry: the general patch semantics across all 14 parameters, the enable-before-require dependency, the attachment-type co-dependency rules, and the no-op behavior for duplicate custom field names. It does not add syntax or format guidance for individual scalar parameters like placeholders or video_length_limit, which leaves it just short of 5.

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 names a specific verb and resource and enumerates the exact surface being changed: field toggles, attachment types, placeholders, required flags, and custom fields. That surface is distinct from the sibling update_padlet_* tools (appearance, layout, sharing, engagement) without needing to name them.

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?

It clearly states the calling contract as a patch ('Pass only the settings that should change') and tells the agent what to do when a part is not applied (explain why, never claim it changed). It does not give explicit when-not-to-use guidance or point at an alternative such as save_posts for editing post content, so it stops short of a 5.

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.