Fulcra MCP Server

Send Agent Message

send_agent_message

Send messages, replies, or acknowledgements to connected agents so all participants can read them, while confirming your own postback rather than peer delivery.

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.

Input Schema

Name	Required	Description
`ack`	No	Peer message/reply UUID to acknowledge, within 30 days; never an ack.
`body`	Yes	Nonblank message, <=4000 characters.
`topic`	No	Thread name; replies inherit.
`sender`	Yes	Stable agent name, <=128 characters.
`priority`	No	P1 urgent, P2 normal (default), P3 low.
`reply_to`	No	Peer message/reply UUID within 30 days; 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	Multiparty reply/ack's exact owner UUID; never infer from sender.
`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.

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

B3/5.0

Behavior1/5

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

The description adds important behavioral details, including that posting confirms only the sender's readback and that denial should never be retried. However, it also states that a posted message/reply removes the entire saved contact status, which is a destructive-side-effect disclosure that contradicts the destructiveHint=false annotation.

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 short and front-loads the primary action. The sentences are terse and mostly meaningful, though some phrasing is compressed enough to be slightly ambiguous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema and output schema are rich, so the description need not explain parameters or return values. It does cover key delivery and side-effect caveats, but it fails to clarify the relationship to send_agent_contact_message and contains a side effect that conflicts with the annotations.

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. The description adds audience context but does not provide additional per-parameter semantics beyond what the schema provides, making the baseline 3 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?

The description clearly states the action and medium: sending a message over a connect-our-agents connection. It specifies the audience as everyone in that connection. However, it does not explicitly distinguish this tool from the sibling send_agent_contact_message.

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?

Usage is implied by 'connect-our-agents connection' and the note that everyone in it can read the message. The warnings about retrying denial and readback status provide operational guidance, but there is no explicit statement of when to choose this tool over send_agent_contact_message.

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

Deploy Server