planvortex-mcp

Official

by taliasoftworks

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

List connected accounts

list_accounts

Read-only

List social accounts connected to an organization to check network, follower count, and broken connection errors that prevent publishing.

Instructions

The social accounts connected to an organization: network, name, follower count and whether the connection is broken. An account with error_code other than 0 cannot publish until a person reconnects it, and that is usually the answer to 'why did this post not go out'. On LinkedIn, personal_profile marks the person's own profile, as opposed to the pages they manage.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No
`offset`	No
`capability`	No	Only accounts whose network supports this capability.
`social_network`	No	Filter by network, e.g. ['instagram', 'linkedin'].
`id_organization`	No	The PlanVortex organization id. Optional: resolved automatically when there is only one to choose from, or when the server was configured with a default one.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`total`	Yes
`accounts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.11.1Oct 7, 2026

changedInput schema / properties / id_organization / description

Previous value: -"The PlanVortex organization id. Optional: if this app reaches a single organization, or the server was configured with a default one, it is resolved automatically."New value: +"The PlanVortex organization id. Optional: resolved automatically when there is only one to choose from, or when the server was configured with a default one."

addedOutput schema / properties / accounts / items / properties / personal_profile

Added value: +{
+  "const": true,
+  "description": "A LinkedIn personal profile: it publishes, but has no comment inbox.",
+  "type": "boolean"
+}

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

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: an account with error_code != 0 cannot publish until a human reconnects it, and LinkedIn personal_profile distinguishes a person's profile from managed pages. It does not discuss pagination behavior, but the annotation bar is lower here.

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, all front-loaded with the resource definition first, then the error_code consequence, then the LinkedIn nuance. Every sentence carries information; only the opening is slightly compressed into a field list that borders on schema duplication.

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-value explanation is not required, yet the description still maps the key fields usefully. For a low-complexity read-only list tool with a safe annotation profile, this is nearly complete; only pagination defaults and filter semantics are unaddressed.

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 60%: capability, social_network, and id_organization are documented in the schema, while limit and offset are bare. The description contributes nothing about filtering, pagination, or the organization id resolution, so it neither compensates for the gap nor contradicts the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely ('the social accounts connected to an organization') and enumerates the returned fields (network, name, follower count, broken connection), which tells an agent exactly what this tool yields. It is a noun phrase rather than a verb+resource statement, and it never names a sibling it differs from, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

There is no explicit when-to-use-vs-alternatives guidance against siblings like get_account_metrics or get_social_capabilities. However, it does supply a diagnostic use case ('usually the answer to why did this post not go out'), which is implied usage guidance rather than a routing rule.

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