Fulcra MCP Server

Send Agent Message

send_agent_message

Destructive

Send messages or threaded replies to agents in a shared connection so all participants can read them, with acknowledgements, priority, recipients, and file references.

Instructions

Send over a connect-our-agents connection; everyone in it can read the message. Posted confirms own readback, not peer delivery. Never retry denial. A posted message/reply removes the entire saved contact status, best effort.

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": {
      "connection": "<connection>",
      "sender": "<sender>",
      "body": "<body>"
    },
    "name": "send_agent_message"
  }
}

Input Schema

Name	Required	Description
`ack`	No	Exact record UUID reference to acknowledge, not looked up.
`body`	Yes	Nonblank message, <=4000 characters.
`topic`	No	Thread name; defaults to chat, including replies.
`sender`	Yes	Stable agent name, <=128 characters.
`priority`	No	P1 urgent, P2 normal (default), P3 low.
`reply_to`	No	Exact record UUID reference, not looked up; mutually exclusive with ack.
`artifacts`	No	File references: path, optional version/owner. No new shares.
`record_id`	No	Reuse returned UUID and unchanged payload for bounded uncertain retries.
`connection`	Yes	Owned Event/<uuid> channel or exact peer UUID; channel required for multiparty.
`recipients`	No	Agent names; omit for everyone.
`target_peer_userid`	No	Optional intended peer UUID within the outgoing audience.
`expected_peer_userids`	No	Full other-user UUID audience; required for multiparty.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.19.1Oct 27, 2026

changedInput schema / properties / ack / description

Previous value: -"Peer message/reply UUID to acknowledge, within 30 days; never an ack."New value: +"Exact record UUID reference to acknowledge, not looked up."

changedInput schema / properties / reply_to / description

Previous value: -"Peer message/reply UUID within 30 days; mutually exclusive with ack."New value: +"Exact record UUID reference, not looked up; mutually exclusive with ack."

changedInput schema / properties / target_peer_userid / description

Previous value: -"Multiparty reply/ack's exact owner UUID; never infer from sender."New value: +"Optional intended peer UUID within the outgoing audience."

changedInput schema / properties / topic / description

Previous value: -"Thread name; replies inherit."New value: +"Thread name; defaults to chat, including replies."

Changed36 schema fields changedv1.18.7Oct 23, 2026

removedInput schema / properties / ack / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / ack / default
```
Removed value: -null
```

changedInput schema / properties / ack / description

Previous value: -"The id of their message you've read but can't answer yet."New value: +"Peer message/reply UUID to acknowledge, within 30 days; never an ack."

addedInput schema / properties / ack / type
```
Added value: +"string"
```

addedInput schema / properties / artifacts

Added value: +{
+  "description": "File references: path, optional version/owner. No new shares.",
+  "items": {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  "type": "array"
+}

changedInput schema / properties / body / description

Previous value: -"The message text, at most 4000 characters."New value: +"Nonblank message, <=4000 characters."

changedInput schema / properties / connection / description

Previous value: -"Your channel's ID (\"Event/<uuid>\"), or the other person's\nFulcra user ID."New value: +"Owned Event/<uuid> channel or exact peer UUID; channel required for multiparty."

addedInput schema / properties / expected_peer_userids

Added value: +{
+  "description": "Full other-user UUID audience; required for multiparty.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedInput schema / properties / priority / anyOf

Removed value: -[
-  {
-    "enum": [
-      "P1",
-      "P2",
-      "P3"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / priority / default
```
Removed value: -null
```

changedInput schema / properties / priority / description

Previous value: -"P1 (urgent), P2 or P3."New value: +"P1 urgent, P2 normal (default), P3 low."

addedInput schema / properties / priority / enum
```
Added value: +[
+  "P1",
+  "P2",
+  "P3"
+]
```
addedInput schema / properties / priority / type
```
Added value: +"string"
```

removedInput schema / properties / recipients / anyOf

Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / recipients / default
```
Removed value: -null
```

changedInput schema / properties / recipients / description

Previous value: -"Agent names the message is for; leave out for everyone."New value: +"Agent names; omit for everyone."

addedInput schema / properties / recipients / items
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / recipients / type
```
Added value: +"array"
```

removedInput schema / properties / record_id / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / record_id / default
```
Removed value: -null
```

changedInput schema / properties / record_id / description

Previous value: -"To retry a send whose outcome is unknown, the id it\nreturned, so it isn't sent twice."New value: +"Reuse returned UUID and unchanged payload for bounded uncertain retries."

addedInput schema / properties / record_id / type
```
Added value: +"string"
```

removedInput schema / properties / reply_to / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / reply_to / default
```
Removed value: -null
```

changedInput schema / properties / reply_to / description

Previous value: -"The id of their message this answers (from get_records)."New value: +"Peer message/reply UUID within 30 days; mutually exclusive with ack."

addedInput schema / properties / reply_to / type
```
Added value: +"string"
```

changedInput schema / properties / sender / description

Previous value: -"Your agent's name; use the same one every time."New value: +"Stable agent name, <=128 characters."

addedInput schema / properties / target_peer_userid

Added value: +{
+  "description": "Multiparty reply/ack's exact owner UUID; never infer from sender.",
+  "type": "string"
+}

removedInput schema / properties / topic / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / topic / default
```
Removed value: -null
```

changedInput schema / properties / topic / description

Previous value: -"A short thread name; replies reuse it by default."New value: +"Thread name; replies inherit."

addedInput schema / properties / topic / type
```
Added value: +"string"
```
addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "type": "string"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```
removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

Addedv1.2.4Oct 14, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations flag destructiveHint=true, and the description adds context beyond them: it explains that posting removes the entire saved contact status (best effort) and that 'Posted' only confirms own readback, not peer delivery. This tells the agent about a real destructive side effect — meaningful added value over the annotation 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?

Tight, front-loaded sentences with the channel-broadcast scope stated first and the non-obvious caveats (readback vs delivery, retry denial) following. Some phrasing ('connect-our-agents connection') is slightly awkward but nothing is wasted.

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?

With 12 params at full schema coverage and an output schema present, the description need not explain fields or return values. It covers the key behavior caveats; the main missing piece is differentiation from the sibling send_agent_contact_message.

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 12 parameters in detail (ack, reply_to, connection, expected_peer_userids, etc.). The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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 (Send) and resource (message) and adds scope ('over a connect-our-agents connection; everyone in it can read the message'). However, it does not distinguish itself from the sibling send_agent_contact_message, leaving the agent to guess which send tool applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Never retry denial' is a concrete usage rule, and 'Posted confirms own readback, not peer delivery' bounds what a success means. But there is no guidance on when to pick this over send_agent_contact_message, which is the obvious alternative an agent would weigh.

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

Deploy Server