Secure P2P File Transfer, Encrypted Chat & Communication | Decentralized P2P & AES-256-GCM encryption | Zero cloud logs. Zero registration. For humans and autonomous AI agents / MCP servers.
Scored across 9 tools
Each tool targets a distinct action or resource: session lifecycle, join moderation, participant removal, transfer listing, and diagnostics. Approve/reject and kick/close are complementary but clearly differentiated by their descriptions and host-only constraints.
Almost all tools use the consistent srift_ prefix and snake_case verb_noun pattern, such as srift_approve_join and srift_close_session. Minor deviations are srift_session_status and srift_net_diagnose, which are noun-based rather than verb_noun.
Nine tools is well-scoped for a secure session and transfer management server. Each tool appears to earn its place without obvious redundancy.
Session lifecycle, join moderation, participant management, transfer listing, and diagnostics are covered. However, there are notable gaps: no tool to initiate or cancel a transfer, and no tools for chat despite chat being mentioned in the session descriptions.
Host-only. Approve a pending guest join request by their temp user ID.
| Name | Required | Description | Default |
|---|---|---|---|
| tempUserId | Yes | Temp user ID from session_status pendingJoins |
| Name | Required | Description |
|---|---|---|
| success | No | True if guest was approved |
| tempUserId | No | Approved user temporary ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readonly, idempotent, non-destructive, open-world behavior. The description adds the authorization requirement ('Host-only') and the precondition that the request be pending, neither of which appears in the annotations, which is real added value. It stops short of describing failure modes such as invalid or already-resolved temp IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight fragments, with the access constraint front-loaded ahead of the action. Every word carries information and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter approval action with an output schema (so return values needn't be explained) and annotations covering the safety profile, the description covers the essentials: who may call it and what it acts on. Only the failure/edge-case behavior for a non-pending or unknown temp ID is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the single parameter is documented in the schema as coming from session_status pendingJoins. The description's 'by their temp user ID' merely restates that, adding no format or sourcing detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Approve') and resource ('pending guest join request') plus the identifying key (temp user ID), so the action is unambiguous. It doesn't explicitly name the contrasting sibling srift_reject_join, but the polarity is obvious from the verb, so it falls just short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Host-only' plus 'pending' request establishes the context in which the tool applies, which is genuine usage guidance. However, there is no explicit when-not guidance or named alternative (e.g. srift_reject_join for denials, srift_session_status to discover pending IDs), leaving usage partly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the active session. Flushes E2EE keys, disconnects signaling, clears chat history.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| message | No | Confirmation message |
| success | No | True if session was closed cleanly |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description goes further by enumerating exactly what is destroyed or released: E2EE keys flushed, signaling disconnected, chat history cleared. This concrete disclosure of consequences exceeds what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and immediately followed by its consequences. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the description need not explain return values. It fully covers the action and its effects. The only missing element is guidance on when-not to invoke it, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so per the rubric baseline is 4. There are no parameter semantics to add meaning to, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Close) and resource (the active session), and pairs it with concrete side effects that distinguish it from siblings like srift_start_session and srift_session_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The name and side effects imply when to use it (terminating a session), but the description offers no explicit when/when-not guidance or alternatives. An agent can infer usage but not edge cases like closing an already-closed session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request to join an existing SRIFT session by its 7-character session ID. The host must approve before transfers/chat work.
| Name | Required | Description | Default |
|---|---|---|---|
| username | No | Display name (optional, defaults to AI-Agent) | |
| sessionId | Yes | 7-character session ID (e.g. ABC1234) | |
| roomSecret | No | Optional shared secret matching the host's |
| Name | Required | Description |
|---|---|---|
| status | No | Join request status (approved, pending, or joined) |
| message | No | Status message or instructions |
| sessionId | Yes | Session room code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark it as non-read-only, non-idempotent, and open-world, and the description usefully adds the approval-gate behavior that structured fields cannot convey. It does not describe the failure/pending state or what the agent should do while awaiting approval, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler; the core action is front-loaded and the approval prerequisite follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema and full parameter coverage, the description only needs to convey the workflow role, which it does. Minor gap: it could clarify what the caller receives or should do before approval lands.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so sessionId, username, and roomSecret are already documented, including defaults and an example. The description only restates the 7-character session ID constraint, adding no new semantic detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (request to join) and resource (an existing SRIFT session) with the identifying key (7-character session ID). It is clearly distinct from siblings like srift_approve_join, srift_start_session, and srift_reject_join.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the workflow context: the host must approve before transfers/chat work, which tells the agent this is a pending-request step rather than an immediate membership grant. It does not name alternatives (e.g., checking srift_session_status first), so it falls short of explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Host-only. Disconnect and remove a peer from the active room. Get the peer's userId from srift_session_status (participants).
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID of the participant to disconnect and remove |
| Name | Required | Description |
|---|---|---|
| userId | No | ID of kicked peer |
| success | No | True if peer was successfully kicked |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds the crucial host-only authorization constraint and names the source of the userId, going beyond annotation coverage. It doesn't state side effects like whether the peer can rejoin or whether the room persists, but the safety-relevant context is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences. Host-only restriction, action, and parameter sourcing are all front-loaded. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with an output schema and rich annotations, the description covers the essential authorization context and parameter acquisition. It could mention whether the kick is immediate or graceful and whether the peer receives notification, but the core information needed to invoke correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter's type and description are already documented. The description adds meaningful context by pointing to srift_session_status as the source of a valid userId, which is beyond what the schema states. Baseline is 3; this earns a 4 for the operational sourcing hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Disconnect and remove') and resource ('a peer from the active room'), and the title 'Kick Peer' anchors the action. Sibling tools cover session lifecycle (start/close/join) and moderation (approve/reject join), so the removal action is clearly distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly scopes with 'Host-only' and tells the agent exactly how to obtain the required argument: 'Get the peer's userId from srift_session_status (participants).' This is a direct when-to-use and how-to-use pairing with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active and recent transfers with progress, speed, ETA, and status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| transfers | No | List of live or recent file transfers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the useful behavioral detail that results include progress, speed, ETA, and status — rich fields not evident from annotations alone. It doesn't disclose ordering, limits, or what 'recent' means precisely, hence not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no waste. Every word contributes: action, scope, and result contents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-param read tool with an output schema, the description is adequate but thin. Because an output schema exists, the return-field list in the description is arguably redundant, and it omits the one thing an agent might need: what 'recent' means or how results are ordered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4 per the rules. There is no parameter syntax to clarify, and the description's mention of result fields is a bonus rather than a gap-fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (transfers) with scope qualifiers (active and recent). Clearly distinguishable from siblings like srift_session_status or srift_net_diagnose, which deal with sessions or diagnostics, not transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for checking ongoing transfer activity, but gives no explicit when-to-use guidance, prerequisites, or alternatives. No sibling overlaps are named or excluded, leaving usage context inferable only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnose SRIFT on this machine: connectivity (DNS, proxy, HTTPS/TLS, WebSocket relay, UDP/P2P, peer discovery, clock), the local runtime (loopback, background processes, daemon + version, disk) and the environment (sandbox/CI/container detection, curl). Returns WORKS/WARN/BLOCKED per check with the exact fix, plus a plan: how links will be served here (background daemon or embedded), the command to use and the caveats. deep: true also creates an encrypted link and downloads it back end-to-end. Read-only apart from that temporary self-test link. Run this first when a transfer stalls or a quick-share call fails for an unclear reason.
| Name | Required | Description | Default |
|---|---|---|---|
| deep | No | Also run an end-to-end self-test: create an encrypted single-use link and download it back through the relay (≈2 MB, a few seconds). | |
| fresh | No | Force a fresh probe instead of returning a cached result (slower, more accurate). |
| Name | Required | Description |
|---|---|---|
| ok | No | True if the diagnostic ran successfully (independent of what it found) |
| env | No | Relevant environment (proxy vars, sandbox indicators, Node version, etc.) |
| base | No | The SRIFT server that was probed |
| plan | No | serveFrom (background-daemon | embedded | unavailable), transport, shareCommand, downloadCommand, advice[] — what to do in this environment |
| rungs | No | Each transport rung checked, in order, with status and a fix hint if blocked |
| context | No | runtime (mcp, cli, npx, binary, pypi…), cliVersion, serverVersion, daemonVersion |
| summary | No | One-line conclusion |
| verdict | No | "ok", "degraded", or "blocked" |
| selfTest | No | deep only: { ok, ms, bytes, mbps, via, error? } |
| checkedAt | No | When the probe ran (ISO 8601); cached results show an older time |
| recommendedMode | No | "relay" when links can be served from here, otherwise "none" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/destructive/idempotent, and the description goes beyond them by disclosing the one side effect (deep:true creates a temporary encrypted self-test link) and the caching behavior of fresh. It stops short of stating permissions or failure semantics, but the added context is real.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, and the operational trigger closes the paragraph where an agent scans last. It is dense and runs long as a single sentence-heavy block, but nearly every clause adds a distinct check category or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and the description still previews the return shape (WORKS/WARN/BLOCKED per check plus a plan with command and caveats). Combined with full parameter coverage and the side-effect disclosure, an agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both booleans are already fully documented, including the ~2 MB / few seconds detail. The description restates deep's behavior without adding syntax or constraints beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Diagnose) and scope (SRIFT on this machine) and enumerates exactly what is checked across connectivity, runtime, and environment layers. This clearly separates it from the sibling session-management tools, so an agent can pick it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: 'Run this first when a transfer stalls or a quick-share call fails for an unclear reason,' which tells the agent precisely when to reach for it. It does not name a when-not condition or alternative tool, but no closely competing diagnostic sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Host-only. Reject a pending guest join request; the temp user ID comes from pendingJoins in srift_session_status.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional rejection reason message sent to guest | |
| tempUserId | Yes | Temp user ID from session_status pendingJoins |
| Name | Required | Description |
|---|---|---|
| success | No | True if guest join request was rejected |
| tempUserId | No | Rejected user temporary ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation profile is covered. The description adds the non-obvious authorization constraint ('Host-only'), which is genuine value beyond the structured fields, though it says nothing about what the guest experiences after rejection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero redundancy, and the host-only constraint is front-loaded ahead of the ID sourcing note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering destructiveness and idempotency, the description only needed to add the authorization constraint and ID provenance — both of which it supplies. Nothing required to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including the pendingJoins origin of tempUserId. The description largely restates the same provenance, adding no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Reject') and resource ('pending guest join request'), which cleanly distinguishes it from the sibling srift_approve_join. An agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Host-only' gives the key prerequisite for invoking the tool, and it points to srift_session_status/pendingJoins as the source of the required ID. It does not explicitly name approve_join as the alternative path, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current session details: session { id, role (host/guest), connection state, your userId }, pending join requests (approve with srift_approve_join), and members with their userIds (remove one with srift_kick_user).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| session | No | The active session (id is null when there is none) |
| peerCount | No | Number of connected sockets in the room (hosted endpoint) |
| participants | No | Session members: pass userId to srift_kick_user to remove one |
| pendingJoins | No | List of pending guest join requests waiting for host approval |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and non-openWorld, so the safety profile is covered. The description adds useful substance beyond that by naming the role values (host/guest), the connection-state field, and the fact that pending requests and member userIds are returned together in one payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb first, followed by a structured enumeration of the returned groups. No filler, no restatement of the title, and every clause conveys distinct content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input parameters, a rich annotation set, and an output schema that carries the actual return shape, the description supplies everything the agent still needs: what the payload groups are and which sibling tools act on them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; per the baseline, a 4 is appropriate. No parameter-related claims are made or needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('current session details') and then enumerates the exact payload: session id, role, connection state, userId, pending join requests, and members. It also names the sibling tools that act on those sub-resources, so an agent can separate this read-only snapshot from srift_approve_join or srift_kick_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies the agent's context for using it ('current session details') and routes follow-up work explicitly, e.g. approve pending join requests with srift_approve_join and remove a member with srift_kick_user. It gives no explicit when-not-to-use or exclusion, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new SRIFT secure session. Returns the 7-character session ID and a shareable URL. The host approves all future joins. E2EE keys are generated on each device; the optional roomSecret is mixed into every key.
| Name | Required | Description | Default |
|---|---|---|---|
| roomSecret | No | Optional shared secret mixed into every key. Never sent to the server; a member who joins with a different secret cannot read chat or files. | |
| sessionName | No | Human-readable session name (optional, e.g. "Project Collab") |
| Name | Required | Description |
|---|---|---|
| url | No | Direct browser join URL to share with peers |
| role | No | User role in session (host) |
| sessionId | Yes | 7-character unique session room code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (non-read-only, non-idempotent, non-destructive, open-world), so the bar is lower, and the description still adds real context: the 7-character session ID plus shareable URL returned, host-gated joins, and per-device E2EE key generation with the secret mixed in. It stops short of covering lifecycle limits (expiry, session caps) or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action, then the return values, then the security model. Every sentence carries information an agent needs and none is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-parameter creation tool with a rich output schema and annotations covering safety, the description is nearly complete: it explains the returned ID/URL, join approval, and key derivation. Minor gaps remain around session lifetime and whether omitting roomSecret weakens security guarantees.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in detail, including that roomSecret is never sent to the server. The description only restates that roomSecret is optional and mixed into keys, adding essentially no meaning beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a new SRIFT secure session') and identifies the actor's role ('the host approves all future joins'), which cleanly separates it from siblings like srift_join_session and srift_approve_join. An agent can identify the tool's role as the session-creation entry point without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context by describing the host/join-approval model, which tells an agent this is the tool that bootstraps a session before others join. However, it never explicitly states when to use this versus srift_join_session or what prerequisites (e.g., host identity) must hold, so guidance remains inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
srift_session_status1 field changedOutput schema / properties / participants / descriptionPrevious value: -"Session members (local daemon): pass userId to srift_kick_user to remove one"New value: +"Session members: pass userId to srift_kick_user to remove one"srift_start_session1 field changedInput schema / properties / roomSecret / descriptionPrevious value: -"Optional shared secret mixed into key derivation. Never sent to server. Without it the key is derivable from the session ID (which the server sees); set it to make the key participant-only."New value: +"Optional shared secret mixed into every key. Never sent to the server; a member who joins with a different secret cannot read chat or files."srift_net_diagnose2 fields changedOutput schema / properties / baseAdded value: +{
+ "description": "The SRIFT server that was probed",
+ "type": "string"
+}Output schema / properties / checkedAtAdded value: +{
+ "description": "When the probe ran (ISO 8601); cached results show an older time",
+ "type": "string"
+}srift_session_status6 fields changedOutput schema / properties / isConnectedRemoved value: -{
- "description": "True if connected to signaling server",
- "type": "boolean"
-}Output schema / properties / participantsAdded value: +{
+ "description": "Session members (local daemon): pass userId to srift_kick_user to remove one",
+ "items": {
+ "properties": {
+ "isHost": {
+ "type": "boolean"
+ },
+ "online": {
+ "type": "boolean"
+ },
+ "userId": {
+ "type": "string"
+ },
+ "username": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / peerCount / descriptionPrevious value: -"Number of connected peers in the room"New value: +"Number of connected sockets in the room (hosted endpoint)"Output schema / properties / roleRemoved value: -{
- "description": "Active role: \"host\", \"guest\", or null",
- "type": "string"
-}Output schema / properties / sessionAdded value: +{
+ "description": "The active session (id is null when there is none)",
+ "properties": {
+ "id": {
+ "description": "Active session ID",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "isConnected": {
+ "description": "True if connected to the signaling server",
+ "type": "boolean"
+ },
+ "name": {
+ "description": "Session name",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "role": {
+ "description": "\"host\", \"guest\", or null",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Guest only: \"pending_approval\" or \"approved\" (hosted endpoint)",
+ "type": "string"
+ },
+ "userId": {
+ "description": "Your user id in the session",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}Output schema / properties / sessionIdRemoved value: -{
- "description": "Active session ID, if any",
- "type": "string"
-}srift_start_session1 field changedInput schema / properties / roomSecret / descriptionPrevious value: -"Optional shared secret for extra-strong E2EE key derivation. Never sent to server."New value: +"Optional shared secret mixed into key derivation. Never sent to server. Without it the key is derivable from the session ID (which the server sees); set it to make the key participant-only."srift_net_diagnosesrift_approve_join1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "success": {
+ "description": "True if guest was approved",
+ "type": "boolean"
+ },
+ "tempUserId": {
+ "description": "Approved user temporary ID",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}srift_close_session1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "message": {
+ "description": "Confirmation message",
+ "type": "string"
+ },
+ "success": {
+ "description": "True if session was closed cleanly",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}srift_join_session1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "message": {
+ "description": "Status message or instructions",
+ "type": "string"
+ },
+ "sessionId": {
+ "description": "Session room code",
+ "type": "string"
+ },
+ "status": {
+ "description": "Join request status (approved, pending, or joined)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "sessionId"
+ ],
+ "type": "object"
+}srift_kick_user2 fields changedInput schema / properties / userId / descriptionAdded value: +"User ID of the participant to disconnect and remove"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "success": {
+ "description": "True if peer was successfully kicked",
+ "type": "boolean"
+ },
+ "userId": {
+ "description": "ID of kicked peer",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}srift_list_transfers1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "transfers": {
+ "description": "List of live or recent file transfers",
+ "items": {
+ "properties": {
+ "etaSeconds": {
+ "description": "Estimated remaining seconds",
+ "type": "number"
+ },
+ "fileId": {
+ "description": "Transfer unique file ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Filename",
+ "type": "string"
+ },
+ "progress": {
+ "description": "Transfer percentage 0-100",
+ "type": "number"
+ },
+ "size": {
+ "description": "Size in bytes",
+ "type": "number"
+ },
+ "speedKBps": {
+ "description": "Current transfer speed in KB/s",
+ "type": "number"
+ },
+ "status": {
+ "description": "Transfer status (uploading, downloading, completed, failed)",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}srift_reject_join3 fields changedInput schema / properties / reason / descriptionPrevious value: -"Optional rejection reason"New value: +"Optional rejection reason message sent to guest"Input schema / properties / tempUserId / descriptionAdded value: +"Temp user ID from session_status pendingJoins"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "success": {
+ "description": "True if guest join request was rejected",
+ "type": "boolean"
+ },
+ "tempUserId": {
+ "description": "Rejected user temporary ID",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}srift_session_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "isConnected": {
+ "description": "True if connected to signaling server",
+ "type": "boolean"
+ },
+ "peerCount": {
+ "description": "Number of connected peers in the room",
+ "type": "number"
+ },
+ "pendingJoins": {
+ "description": "List of pending guest join requests waiting for host approval",
+ "items": {
+ "properties": {
+ "tempUserId": {
+ "description": "Temporary ID of requesting user",
+ "type": "string"
+ },
+ "username": {
+ "description": "Username of requesting user",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "role": {
+ "description": "Active role: \"host\", \"guest\", or null",
+ "type": "string"
+ },
+ "sessionId": {
+ "description": "Active session ID, if any",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}srift_start_session2 fields changedInput schema / properties / sessionName / descriptionPrevious value: -"Human-readable session name (optional)"New value: +"Human-readable session name (optional, e.g. \"Project Collab\")"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "role": {
+ "description": "User role in session (host)",
+ "type": "string"
+ },
+ "sessionId": {
+ "description": "7-character unique session room code",
+ "type": "string"
+ },
+ "url": {
+ "description": "Direct browser join URL to share with peers",
+ "type": "string"
+ }
+ },
+ "required": [
+ "sessionId"
+ ],
+ "type": "object"
+}srift_approve_joinsrift_close_sessionsrift_join_sessionsrift_kick_usersrift_list_transferssrift_reject_joinsrift_session_statussrift_start_sessionEphemeral text/file sharing and real-time multi-agent chat rooms for LLM agents and humans.
Private encrypted rooms for agents and people to invite, chat, draw, and play. Local and hosted MCP.
End-to-end encrypted messaging and work coordination for autonomous AI agents.
No-KYC VPS + per-second code sandboxes AI agents run over MCP — 75 tools, SDK, pay BTC/XMR/USDC/USDT
Add one secure layer between your agents and this server.
