planvortex-mcp

Official

by taliasoftworks

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Update a pending post

update_publication

DestructiveIdempotent

Edit drafts or ready posts before they go live: change text, media, or scheduled date. Fix Pinterest pins missing a board by passing destination_id.

Instructions

Change the text, media or scheduled date of a post that has NOT gone out yet (state draft or ready). A published post cannot be edited through PlanVortex; if you try, the error will say so. A Pinterest pin saved without a board (error 987) is fixed here by passing destination_id.

Input Schema

TableJSON Schema

Name	Required	Description
`link`	No	Pinterest: the pin's destination URL.
`text`	No
`files`	No
`state`	No
`title`	No
`publish_date`	No	ISO 8601.
`destination_id`	No	Pinterest: the board, an id from list_destinations.
`id_publication`	Yes
`id_organization`	No	The PlanVortex organization id. Optional.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`publication`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.7.0Sep 26, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / destination_id

Added value: +{
+  "description": "Pinterest: the board, an id from list_destinations.",
+  "type": "string"
+}

addedInput schema / properties / link

Added value: +{
+  "description": "Pinterest: the pin's destination URL.",
+  "type": "string"
+}

First observedv0.1.0Aug 31, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With annotations already covering the safety profile (not read-only, destructive, idempotent), the description adds real value beyond them: the allowed state precondition, the fact that editing a published post returns an explicit error, and the error-987 remediation path. It does not discuss permissions or side effects of the destructive flag, but the added behavioral context is substantive.

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?

Three sentences, front-loaded with the core scope constraint and then the error-handling edge case. Every sentence carries information; the error-987 sentence is dense but useful rather than filler.

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?

An output schema exists, so return values needn't be explained. For a 9-parameter mutation tool the description covers scope, state preconditions, and the key Pinterest edge case. The remaining gap is the undocumented parameters, but overall it gives an agent enough to call it 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 coverage is 44%, below the 50% threshold, so the description needs to compensate. It clarifies destination_id (the Pinterest board that fixes error 987) and maps text/media/scheduled date to their fields, but leaves link, title, state, and id_organization unaddressed. Partial compensation, so a middle score.

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 (Change) and the resources it operates on (text, media, scheduled date of a post), and pins the scope tightly to a post that has NOT gone out yet. This clearly separates it from create_publication and retry_publication, so an agent can route correctly without opening the schema.

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 states the positive condition (state draft or ready) and the negative one (a published post cannot be edited, and the error will say so). It gives clear context for when to use this tool, though it stops short of naming a sibling alternative for the published-post case.

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