Skip to main content
Glama
ponisha-mcp

ponisha-mcp

by Kia-Karami

ponisha_send_message

Sends a text message in a Ponisha conversation; confirm the content with the user unless they allow autonomous replies, and avoid sharing contact details.

Instructions

Send a text message in a conversation. The other person sees it immediately — confirm the text with the user unless they've told you to reply autonomously. Sharing contact details is against Ponisha rules.

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": {
      "conversation_id": "<conversation_id>",
      "content": "<content>"
    },
    "name": "ponisha_send_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
contentYes
reply_toNoMessage id to reply to
conversation_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds what the annotations cannot: the message is visible to the other person immediately (i.e., effectively irreversible once sent), and a platform policy constraint forbids sharing contact details. It does not state error behavior or rate limits, which keeps it below 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences: purpose first, then the consequential behavior, then the policy limit. No filler, and the confirmation requirement is placed before the send happens rather than buried.

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 three-parameter mutation tool with annotations and no output schema, the description covers the essentials an agent needs before calling: effect visibility, user confirmation, and a policy constraint. It stops short of describing failure modes or confirmation of delivery, which are the only remaining gaps.

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 only 33% — only reply_to carries a description — and the description offers just enough implicit meaning to map 'text message' to content and 'in a conversation' to conversation_id. It never mentions reply_to or any constraint on content length, so it only partially compensates for the coverage gap.

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.' An agent can immediately tell this is a write action on an existing conversation, distinct from ponisha_get_messages or ponisha_list_conversations, though those siblings are never named explicitly.

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 concrete when-to-do-what guidance: confirm the text with the user unless the user has authorized autonomous replies. It does not mention alternatives such as reading the thread first with ponisha_get_messages, but the decision rule for sending is explicit.

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