Skip to main content
Glama

Approve From Preview

approve_post_from_preview
Destructive

Approves one post at an exact rev. Only the Approve button in Mark's post preview calls this, after a person clicks it. Agents never call it: to approve, use approve_posts, and only when the user has explicitly asked. Related: approve_posts, get_post.

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": {
      "postId": "<postId>",
      "rev": "<rev>"
    },
    "name": "approve_post_from_preview"
  }
}

Input Schema

NameRequiredDescriptionDefault
revYesExact rev the preview showed.
postIdYesPost id.

Output Schema

NameRequiredDescriptionDefault
postYes
approvalYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / approval / properties / outcomes / items / properties / handoff / description
      Previous value: -"An approved social post's handoff to the publisher: handing_off (it moves to scheduled within seconds), stuck with the reason and fix (no scheduled time, no connected account for the channel, or no progress 5 minutes after approval), or null for every other status and every website post. An approved LinkedIn Article has no publisher: publish_by_hand before its scheduled time and publish_now from it on, until someone records its URL with record_post_published."New value: +"An approved social post's handoff to the publisher: handing_off (it moves to scheduled within seconds), stuck with the reason and fix (no scheduled time, no connected account for the channel, or no progress 5 minutes after approval), or null for every other status. An approved LinkedIn Article has no publisher: publish_by_hand before its scheduled time and publish_now from it on, until someone records its URL with record_post_published. An approved website post whose post type no CMS maps reads publish_by_hand (get_post and the review page only); every other website post is null."
  2. Changed1 schema field changed
    • addedOutput schema / properties / approval / properties / outcomes / items / properties / planLimit
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Set when the plan's published-posts limit skipped it.",
      +  "properties": {
      +    "error": {
      +      "const": "plan_limit_reached",
      +      "type": "string"
      +    },
      +    "key": {
      +      "type": "string"
      +    },
      +    "limit": {
      +      "type": "number"
      +    },
      +    "operation": {
      +      "type": "string"
      +    },
      +    "reason": {
      +      "enum": [
      +        "inactive",
      +        "cap",
      +        "fair_use",
      +        "burst"
      +      ],
      +      "type": "string"
      +    },
      +    "resetsAt": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "upgradeUrl": {
      +      "type": "string"
      +    },
      +    "used": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "error",
      +    "key",
      +    "limit",
      +    "operation",
      +    "reason",
      +    "resetsAt",
      +    "upgradeUrl",
      +    "used"
      +  ],
      +  "type": "object"
      +}
  3. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructive=true, idempotent=false, and openWorld=true, so the description is not required to carry the full safety profile. It adds valuable behavior beyond annotations: UI-only invocation, human click prerequisite, and exact-revision requirement. It does not fully explain the resulting post state, but the added caller context is substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: purpose, caller restriction, and alternative. The most important guidance for an agent — never call it — is front-loaded and impossible to miss.

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 agent, the key information is a prohibition plus a correct alternative, both of which are present. Output schema and annotations cover return values and mutation safety, so nothing material is missing for correct tool selection.

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 coverage is 100%, so both postId and rev are already documented. The description repeats the exact-revision idea but adds no syntax or semantic detail beyond the schema, making the baseline score of 3 appropriate.

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 description names a specific verb and resource ('Approves one post') and adds the exact-revision constraint. It clearly distinguishes this tool from approve_posts, so an agent can identify it without opening either 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?

It explicitly says agents should never call this tool and routes them to approve_posts only when the user has explicitly asked. It also states the only legitimate caller is the human-driven Approve button in the post preview.

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.

Resources