diff --git a/docs/tools/matrix.md b/docs/tools/matrix.md
index 87f2ea77..f6d59350 100644
--- a/docs/tools/matrix.md
+++ b/docs/tools/matrix.md
@@ -8,8 +8,8 @@ streamable-http endpoint as a second MCP server (no stdio bridge —
 see Architecture below). No `matrix.enable` switch exists: the account
 set *is* the switch, and the module declares the hive-internal `main`
 account for you as soon as `services.hyperhive.agent.matrix.url` is
-non-null — which hive-c0re fills in per agent whenever the host-level
-matrix tuwunel is configured. Tools land as `mcp__matrix__<name>`:
+non-null — which hive-c0re fills in per agent whenever the operator
+configures the host-level matrix tuwunel. Tools land as `mcp__matrix__<name>`:
 
 ### Messaging
 
@@ -32,8 +32,8 @@ room you haven't read yet.
 - `send_reaction(room, event_id, key)` — react to a message with an
   emoji key
 - `send_file(room, path, caption?)` — upload a local file and post it
-  as a room attachment; MIME type is inferred from the file extension,
-  50 MiB cap; optional `caption` is sent as a follow-up text message
+  as a room attachment, inferring the MIME type from the file extension
+  (50 MiB cap); an optional `caption` follows as a separate text message
 - `send_redact(room, event_id, reason?)` — redact (delete) a specific
   event; works on your own events, redacting others' requires moderator
   power level
@@ -85,8 +85,8 @@ cache), and an optional `homeserver` (defaults to
 always named `main` and is always the primary; the matrix module
 declares it for you as an ordinary entry of this map, from
 `services.hyperhive.agent.matrix.url` + agent state, so what you add
-here are the *further* accounts. Its `tokenFile` is pinned to
-`<state>/matrix-token` (hive-c0re provisions it there), and the
+here are the *further* accounts. hive-c0re pins its `tokenFile` to
+`<state>/matrix-token` and provisions it there, and the
 dashboard's link-account route refuses to create an account by that
 name.
 
@@ -146,7 +146,7 @@ loose-ends list between turns.
 
 **Invite wakes**: the daemon sweeps `invited_rooms()` after every sync
 callback (deliberately not a one-shot `m.room.member` event handler —
-a one-shot signal that raced a socket-down window was dropped with no
+a one-shot signal that raced a socket-down window vanished with no
 retry, leaving the agent deaf until manually prompted) and upserts a
 todo (keyed `invite:<room>`) for each pending invite on the harness's
 in-agent socket, which drives a turn. The daemon does **not**
@@ -156,9 +156,9 @@ autojoin — the agent calls `list_invites` to see pending invites and
 **Pending invites as loose ends**: the daemon upserts pending invites as
 keyed todos, which appear in `get_loose_ends` output as
 `[matrix] invited to <room> (<room_id>) — use list_invites to see
-pending invites, resolve_invite to accept or reject`. The keyed todo
-is cleared when a `resolve_invite` (or `join_room`) call resolves the
-invite.
+pending invites, resolve_invite to accept or reject`. The daemon clears
+the keyed todo when a `resolve_invite` (or `join_room`) call resolves
+the invite.
 
 See [`docs/integrations/matrix.md`](../integrations/matrix.md) for the homeserver setup,
 provisioning flow, and federation config.