pinbridge

Update scheduled pin

update_schedule

DestructiveIdempotent

Edit a pending schedule in place: time, board, text or media.

    Use to fix a wrong run_at, board, title, link or alt text on a schedule
    that has not started publishing, instead of cancel_schedule plus
    create_schedule; the id and history are kept. Once the schedule has
    run its pin is published and can no longer be edited; for a failed one
    use retry_schedule. Pass at least one field.

    Returns the updated schedule, still in status "scheduled". A new board
    is preflighted like create_schedule. Fails with not_found for an
    unknown id, schedule_not_editable (409) once publishing started, with a
    remediation naming the right tool, validation_error for a past or
    timezone-less run_at, and sandbox_board_fixed when changing the board
    of a sandbox schedule.

Input Schema

Name	Required	Description
`title`	No	Pin title, at most 100 characters.
`run_at`	No	New publish time, ISO 8601 with timezone, in the future.
`alt_text`	No	New accessibility text, <= 500 characters.
`asset_id`	No	Replace the media with this uploaded asset (drops any image_url).
`board_id`	No	Pinterest board ID (numeric string), from list_boards.
`link_url`	No	Destination URL opened when the pin is clicked.
`image_url`	No	Replace the media with this public URL (drops any asset_id).
`description`	No	Pin description, at most 800 characters.
`schedule_id`	Yes	UUID of the schedule, from list_schedules or create_schedule.
`cover_image_url`	No	Public cover image URL; video pins only.
`cover_image_asset_id`	No	Uploaded image asset UUID used as the video cover.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / alt_text

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "New accessibility text, <= 500 characters.",
+  "title": "Alt Text"
+}

AddedSep 24, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing state preservation (id and history kept), the resulting status ('scheduled'), board preflight behavior, and a full error taxonomy with status codes (not_found, schedule_not_editable/409 with remediation, validation_error for past or timezone-less run_at, sandbox_board_fixed). The annotations carry destructive/idempotent/open-world, and the description does not restate or contradict them, but it also never mentions idempotentHint semantics (repeated calls with the same fields) despite that being a meaningful behavior for an in-place edit.

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 key when-to-use decision before the error list; nearly every clause carries operational weight. The error enumeration is slightly dense but is genuinely actionable, so it earns its place; only the board-preflight sentence is arguably secondary detail.

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 an 11-parameter mutation tool with no output schema, the description covers return value ('the updated schedule, still in status scheduled'), preconditions, side effects, and every documented failure mode. Nothing an agent needs to invoke it correctly 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?

With 100% schema coverage the baseline is 3, but the description adds constraints not visible in the schema: 'Pass at least one field' (the schema marks only schedule_id required, so the at-least-one-optional-field rule is otherwise invisible), plus the validation rule that run_at must be future and timezone-bearing.

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 — 'Edit a pending schedule in place: time, board, text or media' — and immediately scopes it to schedules that 'have not started publishing'. This clearly separates it from create_schedule, cancel_schedule, retry_schedule and update_pin, which operate on different lifecycle states.

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 routes between alternatives: use this 'instead of cancel_schedule plus create_schedule' while the schedule is pending, and 'for a failed one use retry_schedule'. It also states the exclusion condition (once run, the pin is published and no longer editable) and the minimum call requirement ('Pass at least one field').

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

All pinbridge tools Inspect

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

Need Help?