planvortex-mcp

Official

by taliasoftworks

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Read a comment thread live

get_comment_thread

Read-only

Read a social post's live comment thread, reconciled with stored data, or fetch Google Business reviews for a listing; use list_comments for Telegram.

Instructions

Read a thread straight from the social network, reconciled with what PlanVortex stored — the network wins. Pass id_publication for a post, or id_account for a Google Business listing, whose reviews hang off the listing and not off any post. On X this costs one credit per reply returned. Telegram has no live read: its comments only exist in the PlanVortex inbox, so use list_comments there. Slack and Pinterest have no comment inbox at all — a Slack thread is not read by PlanVortex, and Pinterest does not expose a pin's comments — so do not try, and do not retry: it is not a temporary failure. Neither does a LinkedIn personal profile (personal_profile in list_accounts): only LinkedIn pages have comments.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No
`offset`	No	The opaque next_cursor from a previous call. Pass it back verbatim.
`id_account`	No	A Google Business account, whose reviews hang off the listing.
`id_publication`	No	The post whose thread to read.
`id_organization`	No	The PlanVortex organization id. Optional.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`total`	Yes
`comments`	Yes
`next_cursor`	No
`credits_consumed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.11.1Oct 7, 2026

removedOutput schema / properties / comments / items / properties / external_id
```
Removed value: -{
-  "type": "string"
-}
```

changedOutput schema / properties / comments / items / required

Previous value: -[
-  "id",
-  "social_network",
-  "author",
-  "text",
-  "read",
-  "replied",
-  "hidden",
-  "external_id",
-  "date"
-]New value: +[
+  "id",
+  "social_network",
+  "author",
+  "text",
+  "read",
+  "replied",
+  "hidden",
+  "date"
+]

Changed1 schema field changedv0.7.0Sep 26, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedv0.1.0Aug 31, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already establish readOnly/openWorld/non-destructive, and the description adds real context beyond them: the network-wins reconciliation rule, a per-reply credit cost on X, and an explicit 'do not retry, this is permanent' warning for unsupported platforms. That is the kind of operational detail the 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-loaded with the core action, then platform routing and restrictions follow. Dense but nearly every clause carries unique information; the platform enumeration is slightly list-like but each entry prevents a real misuse, so it earns its place.

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 an output schema present, return-value detail is not required, and the description covers the remaining gaps: platform availability, credit cost, ID semantics, and fallback to list_comments. An agent has everything needed to call it correctly or decide not to.

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 80%, so limit/offset are already documented and offset's cursor semantics are in the schema. The description goes beyond the schema by explaining the semantic difference between id_publication (a post's thread) and id_account (a Google Business listing whose reviews hang off the listing, not a post), which is not obvious from the schema alone.

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 ('Read a thread straight from the social network') and immediately scopes it against the stored copy ('reconciled with what PlanVortex stored'). This cleanly differentiates it from the sibling list_comments, which reads the stored inbox rather than the live network.

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 the agent: id_publication for a post, id_account for a Google Business listing; use list_comments for Telegram; do not attempt Slack, Pinterest, or LinkedIn personal profiles, and do not retry since it is not a transient failure. This is unusually complete when/when-not/alternative guidance.

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