PostRite

Send a direct message

send_message

Send a text message (up to 1000 characters) in a conversation, as the connected account. Only while the conversation's window is open (window.isOpen in list_conversations); outside it the api refuses and says the contact has to write first. A conversation an automation opened from a comment can take its one private reply instead (window.canPrivateReply), once. A send the platform refuses comes back as an error with its reason, never as a success. Needs the organization's "Let AI assistants answer comments and messages" setting (owner-only; without it the api answers MCP_INBOX_DISABLED) and a connection authorized with the comments/chat permissions — one authorized before they existed must reconnect, and a client that kept its own registration from before then must remove PostRite and add it again.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "conversationId": "<conversationId>",
      "text": "<text>"
    },
    "name": "send_message"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	The message, as the contact will read it
`savedReplyId`	No	The saved reply this text started from (list_saved_replies), so the team's usage count includes it. Optional; never changes what is sent — fill the reply's {{name}}/{{firstName}} fields yourself.
`conversationId`	Yes	Conversation ID from list_conversations
`organizationId`	No	Organization to act in — an id from list_organizations. Required when this connection was authorized for more than one organization; omit it when there is only one.

Output Schema

Name	Required	Description	Default
`id`	No
`text`	No
`error`	No
`status`	No
`sentById`	No
`createdAt`	No
`direction`	No
`flowRunId`	No
`attachments`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the supplied annotations by disclosing the window/open-window precondition, the one-time private-reply variant, and that refusals surface as errors carrying a reason rather than a false success. It also names the exact failure mode (MCP_INBOX_DISABLED) for the owner-only organization setting and the reauthorization/re-registration requirements. This is behavioral context an agent cannot get from readOnlyHint/destructiveHint alone.

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-loads the core action and size limit, and every subsequent sentence concerns a real failure or eligibility condition. The delivery is dense and some clauses are long, but there is little filler to cut.

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, the description needn't explain return values, and it covers the remaining gaps: permissions, organization setting, window state, one-time private reply, and error surfacing. An agent has enough to decide whether a send will succeed before calling.

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 description coverage is already 100%, and the description mainly repeats the 1000-character limit that the schema encodes as maxLength. It adds nothing about savedReplyId, organizationId, or the conversationId source beyond what the schema descriptions already state, so the baseline 3 applies.

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 text message ... in a conversation, as the connected account") with a size bound, which is enough to tell it apart from reply_to_comment and create_post. It never names the nearest sibling (reply_to_comment) explicitly, so the differentiation is inferred from "in a conversation" rather than stated.

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 when-not guidance: the conversation window must be open (window.isOpen from list_conversations), and outside it the API refuses and asks the contact to write first. It also names the alternative path for comment-opened conversations (one private reply via window.canPrivateReply). It stops short of routing to specific sibling tools such as update_conversation or reply_to_comment.

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

All PostRite tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?