Skip to main content
Glama
taliasoftworks

planvortex-mcp

Official
by taliasoftworks
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Send a private message

send_message
Destructive

Send a private message to a contact via social channels; use approved text within 24h or an approved WhatsApp template with parameters for older conversations.

Instructions

Send a private message to a contact. Two rules that cause most failures: on Facebook, Instagram and WhatsApp a free-form message only reaches someone within 24 hours of their last message, and outside that window WhatsApp needs an approved template: pass template_name and template_language instead of text, and template_parameters with the values of its variables in order ({{1}}, {{2}}...). Show the user what you are about to send and let them approve it first — this goes out under their brand.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoThe message, already approved by the user. Not used with a template.
id_accountYes
id_contactYes
template_nameNoAn approved WhatsApp template, for messages outside the 24h window.
id_organizationNoThe PlanVortex organization id. Optional.
template_languageNoThe template's language code, as approved (for example es or en_US).
template_parametersNoValues for the template's body variables, in order: the first fills {{1}}. No line breaks, tabs or more than four spaces in a row.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
already_existedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.9.0
    • addedInput schema / properties / template_language
      Added value: +{
+  "description": "The template's language code, as approved (for example es or en_US).",
+  "type": "string"
+}
    • addedInput schema / properties / template_parameters
      Added value: +{
+  "description": "Values for the template's body variables, in order: the first fills {{1}}. No line breaks, tabs or more than four spaces in a row.",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / text / description
      Previous value: -"The message, already approved by the user."New value: +"The message, already approved by the user. Not used with a template."
    • changedInput schema / required
      Previous value: -[
-  "id_account",
-  "id_contact",
-  "text"
-]New value: +[
+  "id_account",
+  "id_contact"
+]
  2. Changed1 schema field changedv0.7.0
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the description is not carrying the safety burden alone. It still adds real value: the 24h messaging-window constraint, the approved-template requirement, and the instruction to get user approval because the message goes out under their brand. It does not mention irreversibility or failure/rollback behavior, so not a 5.

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 purpose followed by tightly packed operational rules; every sentence carries new constraints. The second sentence is long and somewhat run-on, which slightly hurts scannability, but there is no 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?

For a 7-parameter mutation tool with an output schema, it covers the risky parts: window rules, template vs text mode, the {{1}} ordering convention, and approval before sending. The id_account/id_contact identifiers are left unexplained, which is a minor gap given they are required.

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 71% and the description goes beyond it by defining the relationship between the two modes — pass template_name/template_language 'instead of text' — and by explaining that template_parameters fills {{1}}, {{2}}... in order. That adds mode-selection meaning the schema only hints at.

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?

States a specific verb and resource ('Send a private message to a contact'), which is clearly distinct from reads like list_messages or conversation tools. It does not explicitly distinguish itself from the closer sibling reply_to_comment, so it stops 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 Guidelines5/5

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

Gives explicit conditional routing: free-form text works only inside the 24h window on Facebook/Instagram/WhatsApp, and outside it WhatsApp requires template_name/template_language plus template_parameters. That is a concrete when-to-use-which-parameter rule with no inference required.

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

Deploy Server

Other Tools