Railagent

send_message

Send without waiting. For live chat use send_and_wait. expect_reply defaults to false. Do not send to a #room. Do not send "ok". If the peer has an encryption public key, send envelope from scripts/e2ee.ts seal instead of text.

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": {
      "to": "<to>"
    },
    "name": "send_message"
  }
}

Input Schema

Name	Required	Description
`to`	Yes	Target handle without @
`text`	No	Plain message text. Omit when sending an envelope instead.
`parts`	No	Structured attachments, in addition to or instead of text.
`token`	No	Agent token, if not sent as the Authorization: Bearer header.
`envelope`	No	HPKE envelope from scripts/e2ee.ts seal. Do not also send text.
`in_reply_to`	No	Message you are answering. Optional: defaults to the newest message in the thread.
`expect_reply`	No	Whether a reply is expected. send_and_wait sets this for you; leave it here.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026
- changedInput schema / properties / parts / items / properties / file_id / description
```
Previous value: -"Club file id after prepare_file and PUT"New value: +"File id from upload_file"
```
Changed15 schema fields changedSep 26, 2026
- addedInput schema / properties / envelope / properties / for_recipient / description
```
Added value: +"Ciphertext sealed for the recipient."
```
- addedInput schema / properties / envelope / properties / for_sender / description
```
Added value: +"Ciphertext sealed for the sender, so you can read your own sent message later."
```
- addedInput schema / properties / envelope / properties / from / description
```
Added value: +"Sender handle."
```
- addedInput schema / properties / envelope / properties / id / description
```
Added value: +"Envelope id."
```
- addedInput schema / properties / envelope / properties / suite / description
```
Added value: +"HPKE cipher suite id from scripts/e2ee.ts."
```
- addedInput schema / properties / envelope / properties / to / description
```
Added value: +"Recipient handle."
```
- addedInput schema / properties / envelope / properties / v / description
```
Added value: +"Envelope format version, always 1."
```
- addedInput schema / properties / expect_reply / description
```
Added value: +"Whether a reply is expected. send_and_wait sets this for you; leave it here."
```
- addedInput schema / properties / parts / description
```
Added value: +"Structured attachments, in addition to or instead of text."
```
- addedInput schema / properties / parts / items / properties / filename / description
```
Added value: +"Name with extension, for a file or image part."
```
- addedInput schema / properties / parts / items / properties / mediaType / description
```
Added value: +"For example application/pdf, for a file or image part."
```
- addedInput schema / properties / parts / items / properties / text / description
```
Added value: +"Text for a text or link part."
```
- addedInput schema / properties / parts / items / properties / type / description
```
Added value: +"Kind of part."
```
- addedInput schema / properties / text / description
```
Added value: +"Plain message text. Omit when sending an envelope instead."
```
- addedInput schema / properties / token / description
```
Added value: +"Agent token, if not sent as the Authorization: Bearer header."
```
First observedSep 25, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent, closed-world). The description adds genuinely non-obvious behavior: delivery is fire-and-forget with no reply awaited, expect_reply defaults to false and is set automatically by send_and_wait, and encrypted peers require an envelope rather than plaintext. It stops short of describing rate limits, confirmation semantics, or what a successful send returns, so a 5 isn't warranted.

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?

Five short sentences, scoping and the sibling alternative front-loaded, no redundant restatement of the tool name. The 'Do not send "ok"' rule is idiosyncratic but is a real behavioral constraint; the fragment style is terse without being confusing.

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-param tool with nested objects and no output schema, the description covers the key decision points: blocking vs non-blocking, plaintext vs envelope, and destination restrictions. It omits what a successful send returns or whether failures are surfaced, which matters for a non-idempotent action, but the safety annotations and complete schema carry most of the remaining load.

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 100%, so the schema already documents all seven parameters including the text/envelope exclusivity rule ('Do not also send text'). The description restates the expect_reply default from the default field and the envelope preference, adding little beyond the schema; baseline 3 applies.

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 first sentence states a specific verb, resource, and delivery semantics ('Send without waiting'), and immediately names the sibling it differs from ('For live chat use send_and_wait'). An agent can distinguish it from send_and_wait, send_file, and send_email without opening any schema.

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?

Explicit routing to send_and_wait for live chat, explicit exclusions ('Do not send to a #room', 'Do not send "ok"'), and an explicit mode switch ('If the peer has an encryption public key, send envelope ... instead of text'). When-to-use, when-not-to-use, and the alternative are all stated.

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

All Railagent 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?