planvortex-mcp

Official

by taliasoftworks

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Create or schedule a post

create_publication

Destructive

Publish or schedule a social post on one connected account, saving it as a draft for review, validating limits, and handling platform-specific media and board requirements.

Instructions

Publish now or schedule a post on ONE connected account. Pass state 'ready' with a future publish_date to schedule, or 'draft' to leave it for a person to review. Media has to be uploaded first with upload_media; pass the returned ids in files. The text is validated against the network's limits before anything is sent. On Pinterest a pin needs things no other network asks for: a board (destination_id, from list_destinations), at least one image or video — a pin is never text alone — and, if it should lead somewhere, the URL in link. An Instagram video can come back in state publishing while the network processes it: that is not a failure, PlanVortex finishes it by itself within minutes, and creating it again would publish it twice. Always show the user what you are about to publish and let them confirm it: this posts publicly under their brand.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`link`	No	Pinterest only: where the pin takes whoever clicks it. It goes here, not in the text: inside the text it is visible and cannot be clicked.
`text`	No	The post body.
`files`	No	Upload ids from upload_media.
`state`	No	'ready' publishes or schedules it; 'draft' just saves it. A post with problems is stored as 'withErrors' either way, and does not go out.	ready
`title`	No	Only on networks with a title field: YouTube, and the pin's title on Pinterest.
`id_account`	Yes	The connected account to publish on. One post, one account.
`publish_date`	No	ISO 8601. Leave empty to publish immediately.
`destination_id`	No	REQUIRED on Pinterest: the board the pin goes to, an id from list_destinations (never the board's name). Other networks have no destinations; leave it out there.
`social_network`	Yes	The account's network: instagram, facebook, linkedin, telegram…
`id_organization`	No	The PlanVortex organization id. Optional.
`publication_type`	No		profile
`destination_section_id`	No	Pinterest only, optional: a section of that board, from list_destinations.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`publication`	Yes
`already_existed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.7.0Sep 26, 2026

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

addedInput schema / properties / destination_id

Added value: +{
+  "description": "REQUIRED on Pinterest: the board the pin goes to, an id from list_destinations (never the board's name). Other networks have no destinations; leave it out there.",
+  "type": "string"
+}

addedInput schema / properties / destination_section_id

Added value: +{
+  "description": "Pinterest only, optional: a section of that board, from list_destinations.",
+  "type": "string"
+}

addedInput schema / properties / link

Added value: +{
+  "description": "Pinterest only: where the pin takes whoever clicks it. It goes here, not in the text: inside the text it is visible and cannot be clicked.",
+  "type": "string"
+}

changedInput schema / properties / title / description

Previous value: -"Only on networks with a title field, such as YouTube."New value: +"Only on networks with a title field: YouTube, and the pin's title on Pinterest."

Changed1 schema field changedv0.1.1Sep 2, 2026

changedInput schema / properties / state / description

Previous value: -"'ready' publishes or schedules it; 'draft' just saves it."New value: +"'ready' publishes or schedules it; 'draft' just saves it. A post with problems is stored as 'withErrors' either way, and does not go out."

First observedv0.1.0Aug 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare destructive/openWorld, but the description adds real context beyond them: text is validated against network limits before sending, posts appear publicly under the user's brand, an Instagram video returning as 'publishing' is not a failure, and re-creating would publish twice. These are high-value behavioral notes an agent would otherwise get wrong.

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-loaded with the core publish/schedule action, and every sentence carries a constraint or gotcha (Pinterest requirements, Instagram async quirk, confirmation requirement). It is a dense single paragraph rather than scannable structure, but there is little filler.

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 a 12-parameter, branching tool with an output schema already covering returns, the description covers scheduling semantics, media dependency, per-network requirements, idempotency, and confirmation workflow. Nothing essential to invoking 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?

Schema coverage is 92% (baseline 3), and the description still adds meaning: files come from upload_media, destination_id must come from list_destinations and never a board name, and link must go in the field not the text. It enriches cross-parameter sourcing rather than just restating the schema.

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 and resource with scope: 'Publish now or schedule a post on ONE connected account.' An agent can immediately distinguish this from update_publication, retry_publication, and list_publications 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear conditional usage: pass 'ready' with a future publish_date to schedule, 'draft' to leave for review, upload media first, use list_destinations for Pinterest boards. It does not explicitly route the agent to update_publication for edits or retry_publication for retries, but the create-vs-schedule decision is well covered.

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