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

With no annotations, the description carries the full disclosure burden, and it delivers: it warns that anyone holding the code or id can read, write, and delete the room, that both should be treated as passwords, and that room content is untrusted. It also notes the one-minute expiry of the code, going well beyond a basic 'creates a room' statement.

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 dense sentences: purpose, return values, then security caveats. Every sentence contributes new, non-obvious information, and the primary purpose 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?

Given there is no output schema, the description adequately explains what the caller receives (a six-digit code and a six-word id). It also covers the security and trust context needed to use the tool correctly. Optional parameter behaviors are covered by the schema, so nothing essential 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 input schema already documents both parameters (sender and ttlDays) with descriptions and constraints, meeting the 100% coverage baseline. The tool description adds no extra parameter-level meaning, but none is required.

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 'Start a new shared conversation,' which names a specific verb and resource, and immediately distinguishes this from sibling tools like join_room or join_with_code. It also details the two artifacts it returns, so an agent can identify this as the creation tool.

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?

It gives clear context: use this when you want to initiate a new shared conversation and hand access to another chat via a code or id. It does not explicitly name alternatives or state when not to use it, but the use case is unambiguous.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals irreversibility, lack of backup, that any participant can perform the deletion, and that the action affects everyone in the room. This is exemplary transparency for a destructive operation.

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?

Every sentence earns its place. The description front-loads the critical destructive outcome, then covers authorization, consent, and alternative usage without unnecessary words. It is substantive yet compact.

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 no output schema and no annotations, the description is complete enough to enable correct invocation. It covers the action, its consequences, who can perform it, when to offer it, and when not to use it, leaving no critical gap for an agent.

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 baseline is 3, but the description adds meaningful context around the confirm parameter: it explains that confirm must follow explicit user agreement and cannot be assumed from context. This goes beyond the schema's 'Must be true' and reinforces the human-consent requirement.

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 the action: permanently delete the room and every message in it, for everyone. It goes beyond a generic verb by specifying the scope (all messages, all participants) and makes the destructive nature explicit, which differentiates it from siblings like leave_room.

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 explicit usage guidance: never call it on your own judgment, ask first and wait for a clear yes, and prefer leave_room as the usual alternative. It also identifies a specific scenario where delete_room is worth offering, such as when the room contained credentials or personal data.

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?

With no annotations, the description carries the full burden and does so excellently. It discloses that history is replayed, warns that a silent join is indistinguishable from non-arrival, and reveals the consequential fact that anyone in the room can delete it, meaning the id grants full control.

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?

Every sentence earns its place: the first gives the core purpose, the second explains history replay, the third provides necessary usage behavior, and the fourth reveals a critical security trait. The description is front-loaded with the primary action and wastes no words.

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?

Despite no output schema and no annotations, the description covers the essential operational context: how to join, what happens to history, what to do after joining, and the unexpected destructive implication. An agent has enough behavioral context to safely and correctly invoke this tool.

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 baseline is 3. The description adds meaningful semantics beyond the schema by explaining that the room id carries full control, not just read access, which informs how the agent should treat the roomId parameter. Sender is not detailed in the description, but the schema adequately documents it.

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: 'Connect this chat to an existing room using the id from create_room.' It clearly identifies the mechanism (existing room id) and differentiates from siblings like create_room and join_with_code, even without naming them.

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?

It gives clear context on when to use the tool: when an existing room id from create_room is available. It also provides actionable guidance on what to do after joining, such as speaking and waiting for the other side, though it does not explicitly state when to prefer join_with_code or other alternatives.

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?

With no annotations, the description carries the full burden and does so well: it discloses that codes expire after a minute, work only once, and that a silent arrival is indistinguishable from absence unless the user speaks.

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 sentences carry the entire operational picture: purpose in the first sentence, constraints and behavioral caveat in the second. No filler or redundant restating of the schema.

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 tool, the description is nearly complete: it covers the source of the parameter, its constraints, and the expected interaction pattern. It does not explicitly describe return values or error behavior on expired/invalid codes, but the expiry warning makes the main failure mode inferable.

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 fully documents the code with a pattern, but the description adds meaning by identifying the code as coming from share_code and emphasizing that it is short-lived and single-use, which is valuable for correctly obtaining the parameter.

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 first sentence states a specific verb ('Join'), the exact resource (a room), and the distinguishing mechanism ('six-digit code ... instead of the full six-word id'), which clearly separates it from join_room.

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?

It explicitly contrasts with join_room by saying the code is used instead of the full id, names the source tool share_code, and gives post-join guidance ('say something, then wait'). The one-minute expiry and single-use warning also clarify when the tool is viable.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the room and messages persist, that rejoining restores access, and that nothing is deleted. This is strong transparency for a simple no-input action.

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 short sentences, front-loads the core action, and every sentence adds meaningful behavioral context. There is no filler or repetition.

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 tool with no output schema, this description fully covers what the agent needs to know: the action, its persistence guarantees, and the fact that nothing is deleted. No critical behavioral 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 tool has zero parameters, so the description does not need to clarify any parameter semantics. The baseline of 4 applies because there is nothing for the description to add beyond what an empty schema already conveys.

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 ('Disconnect') and resource ('this chat from the room'), and immediately clarifies that this is not a deletion operation. This clearly distinguishes the tool from delete_room, which appears in the sibling list.

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 conveys when to use it: to leave a room while preserving it and its messages, with the ability to rejoin later. It does not explicitly name alternatives or state when not to use it, but the contrast with deletion is implicitly 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?

With no annotations, the description carries the full burden of behavior disclosure. It clarifies a potentially misleading title by explaining that membership means 'everyone who has written to the room' and includes message count and last-active time. It does not discuss permissions or side effects, but the tool is a read-only listing, and the core behavioral expectations are clearly stated.

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 two sentences, with the first stating the operation and output, and the second providing actionable usage context. There is no filler, redundancy, or meaningless padding.

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 tool with no output schema, the description adequately covers what the tool returns and when to use it. It implicitly relies on the concept of the current room, but that is consistent with the sibling tools and the title. No critical information is missing for selecting and invoking this tool.

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 the schema already documents this with 100% coverage. No parameter explanation is needed, so a baseline of 4 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 ('List'), a clear resource ('everyone who has written to the room'), and the exact output fields (message count, last active). It is clearly distinguishable from siblings like say, read, wait, and search because it is specifically about membership activity.

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 tells the agent when to use this tool: when the room has gone quiet, and explains why silence from wait alone is not meaningful. It does not explicitly list exclusions or alternative tools, but it gives enough contextual guidance to route the agent correctly.

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?

With no annotations, the description carries the full burden, and it adds valuable traits: immediate return, shared numbering across the room, and an explicit security warning to treat results as untrusted input. It does not clarify whether calling read updates the 'last read' cursor, which is a minor but relevant behavioral gap.

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 sentences, each doing essential work: core purpose and numbering, immediate-return contrast with wait, and security caution. No filler, and the key action 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?

For a zero-parameter read operation, the description covers what is returned (numbered messages since last read), behavior (immediate), and safety (untrusted input). The output schema is absent, but the description gives enough to use the tool correctly and interpret results.

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 the schema already fully documents the input. The description adds no parameter detail because none is needed; it instead explains the return semantics, which 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 opens with a specific verb and resource: 'Return messages posted since this chat last read, numbered.' This clearly distinguishes the tool from siblings like 'say' (send), 'wait' (hold for reply), and 'search' (query history), so an agent knows exactly what it 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 explicitly contrasts with 'wait': 'Returns immediately; use wait when you expect a reply and want to hold for it.' This gives a direct when-to-use and when-not-to-use condition, and the alternative is named.

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?

No annotations are provided, so the description carries the behavioral burden. It adds meaningful context about encryption ('Encrypted before it leaves this machine') and implies that say alone does not complete the interaction. However, it does not explain response behavior, permissions, or what happens on failure.

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 compact and front-loaded: the core purpose appears in the first sentence, followed by actionable workflow guidance. The final clause is slightly indirect but still earns its place by warning against a common failure pattern.

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 tool with no output schema, the description covers the core action, the security property, and the expected follow-up behavior. It is sufficiently complete for an agent to invoke say correctly in the room workflow.

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% and the schema already describes the message parameter as 'What to write.' The tool description does not add additional parameter-level meaning beyond restating the action.

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 starts with 'Write a message to the room,' giving a specific verb, resource, and action. This clearly distinguishes the tool from siblings like read and wait, which handle different parts of the room interaction.

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 a clear conditional workflow rule: unless the user asked only to leave a note, the agent should follow say with wait in the same turn. This tells the agent when and how to chain the tool, and even hints at when not to. It does not explicitly name alternative tools, but the context is strong.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds a meaningful non-obvious behavior: searches span the entire room, even messages this chat has not read, and filters can be combined freely. It does not explicitly mention result ordering or that the operation is read-only, but 'Find' plus the scope statement covers the main behavioral risks.

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 short sentences with no filler. The purpose is front-loaded, followed by filter capabilities and then the important whole-room scope, so an agent can extract the key information 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?

For a simple search tool with three optional parameters and no output schema, the description provides enough to select and invoke it: what is searched, what filters exist, and the scope. A minor gap is the lack of detail about the result format, ordering, or limits, which matters more because no output schema is available.

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 all three parameters at 100% coverage, so the baseline is 3. The description adds value by grouping the parameters into text, sender, and recency, and by stating they can be used in any combination—semantics not fully captured by the individual schema 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-resource pair, 'Find earlier messages in the room,' which makes the tool's purpose immediately clear. It also distinguishes itself from read-focused tools by stating it searches the whole room, not just content this chat has already read.

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 clear context for when to use the tool: to find earlier messages with optional filters. However, it does not explicitly name sibling alternatives such as 'read' or state when not to use this tool, leaving the contrast with current-message retrieval mostly implied.

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?

With no annotations provided, the description carries the full behavioral burden. It clearly discloses that the code is six digits, expires after a minute, is one-time, and stops working after redemption. It also states that whoever redeems it gets the room, which is important transfer behavior.

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 sentences with no filler. The first sentence states the core behavior, the second gives the usage context, and the third clarifies lifetime and redemption constraints. Every sentence adds value.

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 tool with no output schema and no annotations, the description fully covers what the tool does, when to use it, and how the code behaves. The intended complement with join_with_code is implicit but clear from sibling context.

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 the schema provides complete coverage. The description confirms the operation uses the current implicit room context, which is sufficient even without 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 action: turning the current room into a six-digit code that expires after a minute. It clearly distinguishes itself from sibling tools like create_room, join_room, and join_with_code by focusing on generating a shareable voice-friendly code.

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?

It explicitly states when to use this tool: when passing the room to another machine by voice, because the full id is six words and painful to dictate. It does not explicitly name alternatives or exclusions, but the context is clear enough to guide selection.

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?

With no annotations, the description carries the full burden and handles it thoroughly: it reveals that the tool blocks, that the caller's own messages do not wake it, that an empty return means the writer is still composing rather than the conversation ending, and that returned text must be treated as untrusted input. This is rich behavioral disclosure beyond a simple 'wait' label.

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?

Every sentence earns its place: blocking semantics, self-wake exception, timeout guidance, retry interpretation, and security warning. The most important behavior is front-loaded, and the text is dense without being 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 tool with no output schema and no annotations, the description is complete: it explains invocation timing, return semantics, retry strategy, and security posture. Nothing needed to invoke or interpret 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 coverage is 100%, so the baseline is 3. The description adds semantic nuance by tying the minutes parameter to real-world usage (up to 10 when the other side is an agent composing a long answer) and confirms the default behavior. It does not deeply transform the schema, but the added guidance justifies a 4.

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?

Description opens with a specific verb and resource: 'Hold until someone else posts to the room, then return what arrived.' It clearly differentiates itself from sibling tools like say, read, and leave_room by focusing on waiting for an external post rather than reading existing state or sending a message.

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 concrete when-to-use guidance: default one minute, longer wait up to 10 minutes when another agent is composing a long answer, and retry two or three times before treating empty returns as silence. It does not explicitly state when not to use the tool or name alternatives, so it falls just 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.