Skip to main content
Glama

pinbridge

by io.pinbridge
OverviewDiscussionsAdmin

Retry scheduled pin

retry_schedule
Idempotent

Re-queue a schedule whose publish failed.

    Use for schedules in failed status (list_schedules with
    status="failed"). To change the board or account first, use retry_pin
    on the linked pin_id; for a failed pin created directly, use retry_pin.

    Returns the schedule. Its status is usually "queued": a schedule that
    failed while publishing has a linked pin_id, and that pin is
    re-published right away. It is "scheduled" only when the schedule
    failed before any pin was created; the scheduler then runs it at
    run_at, or on its next tick when run_at has passed. Fails with
    not_found for an unknown id and bad_request when the schedule is not
    failed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
schedule_idYesUUID of the schedule, from list_schedules or create_schedule.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / schedule_id / description
      Added value: +"UUID of the schedule, from list_schedules or create_schedule."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover the safety profile (idempotent, non-destructive), and the description goes well beyond them: it explains the returned status semantics ("queued" vs "scheduled" and why), the pin re-publish side effect, and the two error conditions (not_found, bad_request when not failed). That is exactly the mutation/retry context annotations cannot express.

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 core action and then layers routing, return semantics, and error modes in a logical order. It is dense and slightly long for a one-parameter tool, but each sentence carries distinct information about the retry branch, so little is wasted.

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?

With no output schema present, the description assumes responsibility for the return value and does so: it describes the returned schedule and its likely status. It also covers failure modes and the alternative tool path, so an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so schedule_id is already fully documented (UUID from list_schedules or create_schedule) and the baseline is 3. The description references the id only indirectly via the not_found error and adds no new syntax or format meaning.

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 (re-queue) and resource (a schedule whose publish failed), and explicitly contrasts itself with the sibling retry_pin and with list_schedules. An agent can distinguish this from create_schedule, update_schedule, and retry_pin without opening any 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?

Gives an explicit entry condition (schedules in failed status, discovered via list_schedules with status="failed") and names the alternative tool (retry_pin) for the board/account-change case and for a directly-created failed pin. Both when-to-use and which-sibling-to-use are spelled out, leaving nothing to inference.

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

All pinbridge 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