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 on a distinct resource: start/join/close session, approve/reject/kick users, status, list transfers, and net_diagnose. Approve vs reject vs kick are clearly differentiated, and descriptions explicitly cross-reference related tools (e.g. get userId from session_status).
All tools share the srift_ prefix and follow a mostly consistent verb_noun pattern (start_session, join_session, approve_join, kick_user, list_transfers). Minor deviations are net_diagnose (noun_verb inversion) and session_status (noun-first status getter), but these remain readable and predictable.
Nine tools is well within a healthy range for a session management server, with each tool covering a distinct lifecycle stage. Nothing feels padded or thin for the stated scope.
Session lifecycle is well covered (start, join, approve/reject, status, kick, close), but the transfer feature only exposes list_transfers with no tool to initiate, cancel, or pause a transfer, and chat history is mentioned in close_session yet no chat tools exist. These are notable gaps agents may hit.
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 cover readOnly/destructive hints. The description adds context by specifying the host-only requirement and that the request must be pending, but it does not describe side effects, error conditions, or state changes beyond the approval itself. That is modest additional transparency.
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, tightly structured sentence front-loads the most important constraint ('Host-only') and delivers the action and input in one breath. 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 with full schema coverage, a clarifying host-only scope, and an output schema present, the description provides all essential context. Return values are covered by the output schema, so nothing 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 already documents tempUserId fully ('Temp user ID from session_status pendingJoins') with 100% coverage, so baseline 3 applies. The description merely restates 'by their temp user ID' without adding new semantic detail.
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'), a clear resource ('pending guest join request'), and the identifying input ('temp user ID'). 'Host-only' further delineates scope. It is easily distinguished from sibling srift_reject_join (reject) and srift_kick_user (remove existing 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?
Explicitly scoped to host use and pending requests, which tells an agent when this tool is applicable. However, it doesn't name alternatives or explicitly state when not to use it (e.g., use srift_reject_join to deny), so it falls short of full 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.
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?
The description goes beyond the destructiveHint annotation by naming concrete side effects: flushing E2EE keys, disconnecting signaling, and clearing chat history. This gives the agent specific knowledge of what will be destroyed or reset, which is exactly what a destructive operation needs.
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 description is a single front-loaded sentence that states the primary action first, then lists three meaningful consequences. Every clause earns its place, and there is no redundant or vague 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 zero-parameter destructive operation with annotations and an output schema already present, the description fully covers what the tool does and what effects it has. An agent has everything needed to invoke it correctly and anticipate consequences.
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 input schema has zero parameters, so the baseline is 4. There is no parameter meaning to clarify, and the description correctly focuses on the operation's behavior rather than inventing parameter details.
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?
The description states a specific verb and resource: 'Close the active session.' It clearly differentiates from siblings like start_session, join_session, and kick_user by focusing on terminating the entire session rather than joining, starting, or managing users.
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 tool is for ending an active session, but it does not explicitly state when to use it versus alternatives. It could be stronger by mentioning that individual-user removal is handled by kick_user or that starting a new session is handled by start_session. The context is clear enough to infer, but not explicit.
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 already indicate this is not read-only and not destructive. The description adds meaningful behavioral context beyond annotations by stating that the request requires host approval before transfers/chat work, which clarifies the join is not immediately effective. This is useful non-obvious behavior for an agent to know.
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 deliver the core action, the required identifier format, and the critical approval behavior with no wasted words. The most important information is front-loaded.
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?
The description is complete enough for a simple join-request tool: it states the purpose, identifier requirement, and approval workflow. The output schema covers return values, and the input schema fully describes all three parameters. It could optionally mention pending-request behavior or failure cases, but these are not essential given the existing structured metadata.
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 the schema already documents sessionId, username, and roomSecret. The description adds the 7-character session ID detail, which is also in the schema, but does not provide additional meaning beyond what the schema offers. The baseline of 3 is appropriate.
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?
The description states a specific verb and resource: 'Request to join an existing SRIFT session by its 7-character session ID.' It clearly differentiates this from sibling tools by emphasizing 'existing' and the approval requirement, so an agent can distinguish joining from starting, approving, or rejecting.
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 clearly implies when to use it: when the agent wants to join an already-created session using a session ID. It provides helpful context about the host approval gate, and the sibling list reinforces the distinction from start/approve/reject. However, it does not explicitly say 'use srift_start_session to create a new session' or 'use srift_approve_join as the host,' so it stops short of full alternative routing.
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 indicate a destructive operation with destructiveHint=true and readOnlyHint=false. The description adds useful context by restricting use to the host and to the active room, and explicitly states the effect of disconnecting and removing a peer. This goes beyond the annotation flags without contradicting them.
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 concise sentences with no filler. The host restriction is front-loaded first, followed by the action, then the source for the required parameter. Every clause earns its place.
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?
The tool is simple, has only one fully documented parameter, and has an output schema. The description supplies the remaining operational context: permission level, applicable room state, and how to obtain the userId. Nothing essential for invoking 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?
The schema already documents userId with full 100% coverage, so the baseline is 3. The description adds practical guidance on how to source the value, namely from srift_session_status participants. This helps the agent construct a valid argument beyond just knowing the parameter type.
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?
The description clearly states a specific action and resource: 'Disconnect and remove a peer from the active room.' It also names where to obtain the required userId, which sharpens the purpose. It does not explicitly contrast with siblings like reject_join or close_session, 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?
The description gives an explicit usage condition ('Host-only') and a precondition ('active room'). It also tells the agent exactly where to get the required parameter value, from srift_session_status participants. It does not state when not to use this tool or mention alternatives, but the context is clear enough for correct selection.
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 and destructiveHint=false, so the safety profile is covered. The description adds scope ('active and recent') and the returned fields, but it does not disclose behaviors like pagination, ordering, or a defined cutoff for 'recent.' With annotations present, this is adequate but not rich.
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 description is a single, front-loaded sentence with no filler. Every phrase earns its place by specifying scope and output 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 parameters and an output schema present, the description is largely complete for invocation. However, the phrase 'active and recent' leaves some ambiguity about time boundaries or state filtering that could affect expectations, even if the output schema partially resolves this.
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 has zero parameters and schema coverage is 100%, so there is no parameter documentation burden for the description. The baseline of 4 applies because no parameter semantics need to be explained.
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?
The description states a specific action ('List') on a specific resource ('all active and recent transfers') and enumerates the included data fields (progress, speed, ETA, status). This clearly distinguishes it from the sibling tools, which all concern session and member management rather than 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 its usage scenario—when transfer status and progress information is needed—but it does not explicitly state when to prefer it over alternatives or when not to use it. Since no sibling tool targets transfers, the context is fairly clear, but the guidance is only implied rather than explicit.
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 declare read-only and non-destructive. The description reinforces this: 'Read-only apart from that temporary self-test link,' and explains the temporary self-test link creation when deep=true. This adds behavioral context beyond annotations, including the output format (WORKS/WARN/BLOCKED) and the plan.
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 description is informative but relatively long, covering many checks and behaviors. However, each sentence contributes value, and the key points are front-loaded. A 4 reflects its efficiency for the complexity.
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?
Given the tool's complexity (many check categories, output schema exists, and deep flag behavior), the description covers the purpose, output, usage, and the temporary link exception. It is complete for an agent to understand when and how to call 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 covers both parameters with detailed descriptions. The tool description adds minimal extra semantic value, only restating deep's effect. With high schema coverage, baseline 3 is appropriate.
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' with a clear resource 'SRIFT on this machine' and enumerates the categories of checks. Clearly distinguishes from sibling session/transfer tools.
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 provides when to run: 'Run this first when a transfer stalls or a quick-share call fails for an unclear reason.' This gives clear usage context and positions it as the diagnostic first step.
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.
| 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 mark this as destructive and non-read-only, so the mutation risk is known. The description adds useful context: it is host-only, applies only to pending requests, and the reason is sent to the guest. However, it does not disclose irreversibility or what happens to the pending request state beyond the 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?
The description is a single compact sentence that front-loads the most important constraint ('Host-only') and then states the action. Every word earns its place, with no redundancy or 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 simple two-parameter tool with a full input schema, an output schema, and annotations that already signal destructive behavior, the description provides all the essential context: who may call it and on what. No meaningful gap remains for an agent to invoke it correctly.
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 schema already documents both parameters with 100% coverage, including where tempUserId comes from and the purpose of the optional reason. The description does not need to repeat these details and does not add significant parameter-level meaning 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?
The description states a clear verb ('Reject'), a specific resource ('a pending guest join request'), and a scope constraint ('Host-only'). It is immediately distinguishable from sibling tools like srift_approve_join or srift_kick_user, which target different lifecycle stages.
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 explicitly scopes usage to the host and to pending join requests, which implies it is for requests not yet approved. It does not explicitly name srift_approve_join as the alternative for accepting, but the pending qualifier plus sibling names make the intended context clear.
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 (local daemon): 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 readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about what the status payload contains and confirms the tool only observes state, with no side effects implied. No further behavioral caveats are needed for a no-param status read.
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?
One front-loaded sentence states the core action and then efficiently maps returned data to relevant sibling actions. No filler or redundant phrasing; every clause carries useful information.
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 no-param, read-only status tool with an output schema and safe annotations, the description fully covers what to expect and what actions to take based on the returned data. Sibling references complete the workflow picture.
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 has zero parameters, so schema description coverage is 100% and there is no parameter burden to shoulder. The description correctly focuses on output rather than inputs, matching the baseline for a zero-param tool.
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'), then enumerates exact contents: session id, role, connection state, userId, pending join requests, and members with userIds. Clearly distinct from sibling action tools like srift_approve_join and 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?
Provides clear context that this is a read-only status retrieval, and explicitly routes follow-up actions to siblings (srift_approve_join for requests, srift_kick_user for members). Lacks an explicit 'use this instead of X' statement, but the action-oriented sibling references make the boundary clear.
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?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses two meaningful behaviors: the host approves all future joins, and E2EE keys are generated per device with roomSecret mixed in. It stops short of covering session lifetime, whether creation is reversible/should be paired with srift_close_session, or any limits on concurrent sessions.
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 with zero filler. The core action and its outputs are front-loaded, and the security-model detail follows rather than delaying the essential information.
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, return values need not be explained, yet the description still names them. It covers the security model and host-approval behavior adequately for a 0-required-param creation tool, though the lifecycle relationship to srift_close_session/srift_join_session 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 description coverage is 100%, so both parameters are already documented in the schema, and the description's mention that roomSecret "is mixed into every key" largely restates it. Baseline 3 applies; the description adds no format, constraint, or default 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?
The description opens with a specific verb and resource ("Create a new SRIFT secure session") and immediately states the resulting artifacts (7-character session ID, shareable URL). This clearly distinguishes it from siblings like srift_join_session and srift_close_session without needing their schemas.
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?
Usage is only implied: an agent can infer this is the entry point that precedes joining, but the description never states when to call this versus srift_join_session, nor any prerequisite or follow-up flow. No exclusions or alternative-selection guidance are given.
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_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_sessionPrivate 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.
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Sovereign E2E cloud storage for AI agents. Zero-knowledge, RGPD-compliant.
Add one secure layer between your agents and this server.
