Send and receive direct, channel, or room messages with message management.
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": {
"action": "<action>"
},
"name": "core_comm"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| params | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent behavior. The description does not clarify which actions are destructive (delete, leave_room, decline_room_invite, unsubscribe_channel) or what side effects or permissions are involved. It underplays the tool's risk by describing it mainly as sending and receiving messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with little wasted wording. However, it is too thin for a 17-action tool, and the phrase 'with message management' is vague filler rather than useful structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a broad, destructive, multi-action tool with 17 enum values, an opaque nested params object, no output schema, and 0% schema description coverage. The one-sentence description does not provide enough information for an agent to select actions, understand parameters, or assess side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain any of the 17 action enum values or the nested params object. The mention of direct, channel, and room messages gives a loose hint about some actions, but most action semantics and all parameter shapes remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a messaging domain (direct, channel, and room messages) and mentions sending, receiving, and management. However, it does not distinguish the tool's 17 actions or differentiate it from siblings such as socnet_post or socnet_interact. The purpose is broadly inferable but not precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any conditions for selecting among the many actions. The only implied usage is that it handles communication messages. For a multi-action tool, this leaves the agent to infer routing entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.