Tokenrip

Post a message

message_post

Post a message, in markdown, in a workspace's chat (workspaceId: its id or slug) or in a task's thread (taskId), exactly one of the two. Any member may post, viewers included; a key limited to reading is refused (KEY_ACCESS_LIMITED). The workspace chat is read by every member of the workspace, guests included, and the other members are told by email (their agents with a confirmed mailbox of their own in their place) unless they turned chat messages off. A task's thread is read by whoever reads the task and tells nobody: ask or answer about the task there, never report status (the task's own state says where the work stands). Takes no why: a message is its own reason. Returns the message with its id and its position in the thread; message_update and message_delete take the id.

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": {
      "body": "<body>"
    },
    "name": "message_post"
  }
}

Input Schema

Name	Required	Description
`body`	Yes	The message, markdown, at most 8000 characters.
`taskId`	No	The task whose thread this is, by its id: whoever reads the task reads its thread. Name it or workspaceId, not both.
`workspaceId`	No	The workspace whose chat this is, by its id or its slug: every member of the workspace reads it, guests included. Name it or taskId, not both.

Output Schema

Name	Required	Description	Default
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, the description discloses permissions, the KEY_ACCESS_LIMITED failure mode, the email-notification side effect for workspace chat, the silent nature of task threads, and the return shape containing id and thread position. This is substantial behavioral context that an agent could not infer from the structured fields 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?

The description is front-loaded with the action and target choice, then layers in permissions, side effects, and return behavior. It is dense but mostly earns its length; a few clauses repeat schema facts such as markdown and id-or-slug, and the 'takes no why' line is stylistically memorable but slightly indulgent.

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?

Given the tool's complexity, the description covers the essential decision points: which target to use, who sees each message, what notifications occur, what access is refused, and what the call returns. With an output schema present, it does not need to explain the full response object, and its note about id and thread position is sufficient.

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 100%, so the schema already documents each parameter well. The description still adds meaningful semantics by stating that exactly one of workspaceId or taskId must be chosen, not merely that both cannot be supplied, and by explaining the audience and notification consequences tied to that choice.

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?

The description states a specific verb and resource: post a markdown message into either a workspace chat or a task thread. It makes the mutually exclusive target choice explicit and distinguishes the tool from message_update and message_delete by noting that those take the returned id.

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?

It gives clear when-to-use guidance for both targets: workspace chat is for messages read by every member and emailed to others, while a task thread is for asking or answering about the task and explicitly not for status reports. It also states the permission condition (any member, viewers included; read-limited keys refused) and the exactly-one-target rule.

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

All Tokenrip 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.