SRIFT

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.

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.

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.

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

Annotations already flag the operation as destructive and not read-only. The description adds meaningful context beyond those annotations by specifying that only a host may use it and that it acts on the 'active room,' plus 'ban' clarifies the user will be disconnected and prevented from returning. This aligns with the destructiveHint rather than contradicting it.

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 names the audience ('Host-only'), the action ('Disconnect and ban a peer'), and the context ('from the active room') without any filler. Every word contributes to the agent's understanding.

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 one-parameter tool with an output schema and destructive annotations, the description covers all critical operational context: who may invoke it, what it does, and where it applies. There is no meaningful gap that would prevent an agent from selecting or invoking this tool 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 input schema already fully documents the single parameter: 'User ID of the participant to disconnect and remove.' With 100% schema description coverage, the baseline is 3, and the tool description adds no additional parameter-specific detail, though it does clarify that the target is in the active room.

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-plus-resource action: 'Disconnect and ban a peer from the active room.' It also adds a clear scope qualifier, 'Host-only,' which helps distinguish this tool from related session-management siblings like srift_approve_join or 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 makes the relevant usage context explicit: this tool is for hosts and applies to the 'active room.' It does not explicitly name alternatives or exclusion criteria, but the host-only and active-room constraints provide clear guidance for when this tool is appropriate.

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

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.

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.

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 a list of returned fields but no additional behavioral context, such as behavior when no session is active or whether the status is live vs. cached. This is adequate given the annotations, but the description itself contributes little beyond output semantics.

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 sentence that leads with the action and resource, followed by a concise field list. Every word earns its place; no filler, redundancy, or unnecessary background.

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 parameterless, read-only status tool with an output schema, the description is complete. The output schema handles return-value structure and the annotations handle safety; the description tells the agent exactly what information is available. No critical gap remains.

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 there is nothing to describe on the input side. Per the baseline for 0-parameter tools, the description appropriately focuses on the returned session details rather than inputs.

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 uses a specific verb ('Get') and resource ('current session details') and enumerates the exact fields returned (id, role, connection state, pending join requests, peer count). This clearly differentiates it from sibling tools that start, close, join, approve, or reject sessions, leaving no ambiguity about what the tool does.

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 makes it implicitly clear this is the read-only status getter among the sibling action tools, but it does not explicitly state when to use it versus alternatives, nor mention that it should be used before performing session mutations. Usage is inferred from the name and description rather than directly stated.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses meaningful security and access-control behavior: the host approves all future joins, and E2EE keys derive locally from the session ID plus optional roomSecret. This gives an agent important context about the trust model without contradicting any annotation.

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 three tight sentences with no filler. The primary action and return values are front-loaded, followed by the most important behavioral and security details. Every sentence 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?

For a tool with zero required parameters, an output schema, and non-destructive mutation annotations, the description covers what the tool returns, how joins are governed, and how E2EE keys are derived. No critical operational aspect appears 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 coverage is 100%, so the schema already documents both roomSecret and sessionName. The description reinforces roomSecret's role in key derivation, which adds a small connection, but it does not meaningfully expand on the schema's parameter descriptions.

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 uses a specific verb ('Create a new SRIFT secure session') and clearly distinguishes this tool from siblings like srift_join_session and srift_close_session by framing it as session creation. It also states the key outputs (7-character session ID and shareable URL), leaving no ambiguity about what the tool does.

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 this is the tool to use when starting a new session rather than joining or managing an existing one, and the sibling names reinforce that. It does not explicitly name alternatives or state 'use this when creating a new session,' so it stops short of full explicit routing.

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