Skip to main content
The XMPP server at /MCP/XMPP associates each MCP client with an XMPP account. It publishes roster contacts and received messages as account-specific resources.

​
Resources

  • xmpp: resources represent contacts in the account’s roster.
  • message resources represent messages received by the agent.
  • listing and reading require .Resources.List and .Resources.Read privileges.
The in-memory client connection is cached and removed after prolonged inactivity. An agent that must retain a message should read and store it rather than treating the MCP resource list as permanent archival storage.

​
Tools

The full root is OAUTH.Scope.MCP.XMPP.
1

Request presence

Ask the contact for a presence subscription before sending messages or information queries.
2

Wait for approval

The remote party can accept or decline. Presence state and roster resources show the relationship.
3

Send a message

Send plain text plus optional Markdown/HTML representations only after the relationship permits it.
4

Read and persist replies

Read or pop incoming messages. Persist business-relevant messages in an appropriate application store.

​
Credentials

If no XMPP account is associated with the MCP client, the server can elicit XMPP credentials. Prefer an operator-created, role-scoped account for production. Dynamic OAuth registrations create an XMPP account but leave normal XMPP communication disabled until an operator enables it.

​
Safety

  • Do not let an agent auto-accept arbitrary presence requests.
  • Maintain an allowlist for automated outbound destinations.
  • Treat message bodies as untrusted input that can contain prompt injection.
  • Keep the identity of the human or workflow that authorized a message in the audit log.
  • Rate-limit retries and presence operations.