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

Beyond the annotations (destructiveHint/idempotent), it discloses the irreversibility (

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?

Front-loaded with the action and effect, then prerequisites, then provenance of the id, then return fields. Five sentences is dense but each carries a distinct, non-redundant fact.

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 output schema, the description compensates by naming the return fields (id, status, answer), and it also covers the permission requirement (rooms:write) and the irreversibility constraint. An agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the answer is optional and audience-visible, is capped at 1,000 characters, and omitting it preserves an existing written comment rather than clearing 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?

States a specific verb+resource+precondition ('Mark an approved question as answered') and distinguishes itself from siblings by naming moderate_question and get_room_questions. An agent can tell exactly what changes and on which entity without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use context ('as the host answers during or after a session'), names the prerequisite ('Only approved or already-answered questions qualify, so approve a waiting one first with moderate_question'), and routes the agent to get_room_questions for the required id.

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 annotations already declaring destructiveHint=true and idempotentHint=true, the description adds substantial context beyond them: what stops working (join/ask/vote), that live surveys close at the same moment, that questions and results remain readable, the room_not_open failure mode, that no email is sent, and the required rooms:write scope. It resolves the ambiguity that 'destructive' would otherwise imply, 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?

Front-loaded with the effect of the call, then usage, then error/auth/return details. Every clause carries distinct information - no restatement of the title or name.

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 having no output schema, the description states what is returned ('the room and its links'), covers the side effects, the auth requirement, and the failure case. Nothing an agent needs to invoke this 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?

There is exactly one parameter and schema description coverage is 100% - the schema already documents 'code' with a six-character pattern and an example. The description adds no format, case-sensitivity, or sourcing guidance for the room code, so the 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 and resource ('Close an open room') and immediately enumerates the exact consequences: audience can no longer join, ask or vote, and live surveys close simultaneously. This clearly separates it from sibling close_survey, which acts on a single survey, and from list_rooms/get_room_qa which read state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit timing ('when the session ends'), a follow-on action ('read the Q&A with get_room_qa'), the reverse operation ('reopen it later with open_room'), and a hard precondition with its error code ('A prepared room cannot be closed (room_not_open)'). Nothing about when to choose this over close_survey is left to inference.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, and the description usefully refines that by clarifying results remain readable and that re-closing is safe. It also discloses audience-display side effects (phones and the wall show live surveys or the latest closed batch) and the required scope ('Needs rooms:write'). Strong, though it does not describe failure modes if the survey_id is stale or the room code is wrong.

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?

Front-loaded with the core action and the primary alternative, with no filler sentences. It is a single dense paragraph and a few clauses (the screens/wall explanation) run long, which slightly hurts scannability but each sentence carries distinct 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?

Covers the mutation's effect, what is preserved, the alternative sibling, preconditions (not a draft), idempotent behavior, the parameter source, auth scope, and the return contents ('Returns the survey, the room and its links') despite there being no output schema. Nothing an agent needs to call it 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 goes beyond it by telling the agent where survey_id comes from ('Get survey_id from get_survey_results') and by framing show_results in terms of audience visibility and screen behavior. It does not, however, restate or enrich the code 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?

States a specific verb and resource ('Close a live poll, quiz, rating or word cloud so it stops taking answers') and immediately notes the preserved-results scope ('its results stay readable'). It also names the sibling it differs from (close_room), so an agent can distinguish it without opening 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?

Explicitly says when to call it ('once a survey has collected its answers'), how to close several ('calling it once per survey'), and the alternative for ending everything ('use close_room to end every live survey together with the room'). It even defines edge cases: re-closing an already-closed survey is allowed, a draft is not.

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 only cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), so the description carries the rest and does so well: it names the failure mode (room_limit_reached), the required scope (rooms:write), the plan/branding dependency, and the retry semantics via request_id. It also describes the returned payload (code, join_url, projector_url, host_url), which no structured field supplies.

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?

Front-loaded with the create action and its lifecycle constraint, and every sentence carries information (returns, limits, auth, idempotency). It is a dense single paragraph, though — splitting the eligibility/limits and retry guidance would improve scannability.

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 mutating five-parameter tool with no output schema, the description supplies everything an agent needs: side effects, return artifacts, auth scope, quota failure and its remedy, and safe-retry behavior. Nothing material 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, but the description adds workflow meaning: open=false produces a room that admits nobody until open_room, and request_id is tied to safe retry after a lost reply. moderation and description are left entirely to the schema, but the two behaviorally significant params are grounded.

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+resource (create a Q&A room) and explicitly frames it against siblings: open=false defers admission until open_room, and polls are added via create_survey later. An agent can distinguish this from open_room, close_room, and create_survey without reading any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use context ("Use it before a session") and explicit routing rules: use open_room to admit people to a prepared room, and close_room first when room_limit_reached fires. Alternatives and the condition selecting them are spelled out.

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 only supply generic hints (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description adds substantial context beyond them: the open-room prerequisite, draft-vs-launch behavior, default audience visibility vs show_results=false privacy, the rooms:write permission requirement, and the request_id retry mechanism. This is exactly the behavioral disclosure the annotations don't carry.

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?

Front-loaded with the core action and appropriately dense: each sentence carries a distinct rule (launch/draft, type variants, visibility, return value, retry). It is on the long side for a single paragraph, but little of it is waste, so only a minor deduction.

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 12 parameters and no output schema, the description still closes the important gaps: it describes the return value ('the survey with its id and the request_id'), the auth requirement, the open-room prerequisite, and how to relaunch a saved draft. Nothing an agent needs to call this 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 already 92%, so the baseline is 3. The description goes further by documenting type-conditional parameter rules the schema only partially implies: poll takes 2-8 options, quiz takes options plus correct_option (zero-based), rating takes scale 5 or 10, word_cloud takes no options, and allow_multiple applies to polls only. This conditional mapping adds real value.

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+resource ('Add a poll, quiz, rating or word cloud to a room and launch it') with clear scope. It distinguishes itself from siblings by name, pointing to get_survey_results and close_survey as the read/end counterparts. An agent can route correctly without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it ('during a session to ask the audience something'), names the alternatives ('Read answers with get_survey_results and end a live survey with close_survey'), and gives the when-not condition ('launching needs an open room'; launch=false saves a draft). Nothing is left to inference.

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 readOnly/idempotent annotations, it discloses that hidden questions are excluded, the exact ordering, a hard capacity limit (2,000 questions / ~900,000 characters), the truncation notice, and a prompt-injection warning about audience text. That is substantive behavioral context annotations cannot carry.

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 dense paragraph, but it is front-loaded with purpose and ordering before routing and limits, and every clause carries distinct information. Only mild cost from being one long run-on rather than segmented sentences.

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 output schema, the description itself describes the return document's structure, ordering, truncation behavior, and content provenance, plus safety guidance. An agent has everything needed to call and interpret the result 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?

Schema coverage is 100% with a single well-documented 'code' parameter (pattern plus example), so the schema already does the work and no param-level detail is added in the description. Baseline 3 is appropriate when the schema fully documents the only input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (read a room's Q&A) plus the output form (one Markdown document) and the exact ordering logic (answered, then approved by votes, then pending-marked). It explicitly distinguishes itself from get_room_questions, so an agent can separate the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('draft a FAQ or summarize a session') and a named alternative with the selecting condition ('use get_room_questions instead when you need question ids... JSON fields or newest-first order'), tying ids to moderate_question and answer_question. Nothing is left to inference.

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 readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: hidden questions are never returned, cursor-based paging must repeat until next_cursor is null, and question text/answers must be treated as content, never instructions. That injection warning and pagination contract go well beyond the structured fields.

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?

Front-loaded with purpose, then alternatives, then sort semantics, then pagination. Every sentence carries information, though the sort and pagination clauses make it longer than strictly minimal.

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?

No output schema exists, so the description carries the return-value burden and does it: field list, hidden-question exclusion, and the next_cursor contract are all covered. Nothing needed to call the tool repeatedly or interpret results 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, but the description adds real semantics the schema lacks: sort=top prioritizes waiting questions then approved/answered by votes, sort=recent is newest-first. The pagination role of cursor and next_cursor is also clarified beyond the schema's one-line definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('read one page of a room's questions as JSON') and enumerates the returned fields (id, body, status, votes, pinned, host answer). It explicitly distinguishes itself from the sibling get_room_qa, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use conditions: needs question ids for moderate_question or answer_question, or paging through a large room, with an explicit alternative ('use get_room_qa instead for a ready-made FAQ'). It also explains when to pick each sort mode, leaving nothing to inference.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context: quiz answer keys are withheld until a survey closes, and no participant identities are ever returned. These data-visibility rules are not derivable from the annotations or schema.

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 dense sentences, front-loaded with the action and scope, and each clause (result shapes, close_survey linkage, answer-key timing, no identities) carries distinct information. Slightly long but nothing is wasted.

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 output schema, the description carries the burden of explaining return values and does so thoroughly per survey kind, plus caveats about answer-key timing and anonymity. An agent has everything needed to call and interpret the result.

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?

Only one parameter (code) and schema description coverage is 100%, with the pattern and example documented in the schema itself. The description implies 'room' scoping but adds no format or constraint detail beyond the schema, so 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?

States a specific verb (read) and resource (every survey in a room) and enumerates the returned shape per survey kind (choice counts, ratings average, word clouds), which lets an agent distinguish it from siblings like get_room_questions or get_room_qa without opening 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?

Gives explicit usage contexts: reporting results, and obtaining the survey_id that close_survey consumes. It does not state when NOT to use it or name an alternative read tool, so it falls short of a 5, but the downstream linkage is concrete and actionable.

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 cover read-only/idempotent/non-destructive, so the bar is lower; the description goes beyond them by disclosing the auth requirement ('any AskOne API token can call it') and the pagination loop. It stops short of describing response shape beyond the listed fields, but the added auth and paging context is real value.

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?

Front-loads the action and result fields, then adds usage and pagination in separate, purposeful sentences. Every sentence earns its place, though it is somewhat densely packed.

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 output schema, the description carries the return-value burden and does so by enumerating the fields and counts, and it also covers auth, pagination and the sibling contrast. For a low-complexity two-parameter list tool this is complete.

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 parameters and the baseline would be 3. The description adds meaning for cursor by spelling out the loop ('call again with cursor set to the returned next_cursor until next_cursor is null'), which goes slightly beyond the schema's terse cursor description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List your organization's rooms') plus the ordering ('newest first') and enumerates the returned fields. An agent can distinguish it from create_room, open_room, close_room and the get_* siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the use case ('Use it to find the code the room tools take') and contrasts with the alternative ('create_room needs none and returns a new room's code'), and gives the pagination procedure. Nothing is left to inference.

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 cover safety (destructive, idempotent, openWorld) but the description adds substantial behavior beyond them: hide accepts only pending questions, approve accepts waiting and AI-hidden questions, person-hidden questions are unrecoverable, hidden questions are never returned by reads, and it requires rooms:write.

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?

Dense and front-loaded, with the core action stated first and constraints following. It is on the long side, but nearly every clause carries a distinct state-transition or precondition fact rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still names the return value ('the question's id and new status'), and it covers permissions, id sourcing, and state-transition edge cases. An agent has everything needed 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?

Schema coverage is 67% (code and question_id documented; action is not). The description compensates by defining the action enum values and their exact effects, plus the constraint that hide only works on pending questions - 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 opens with a specific verb+resource ('Approve a waiting question... or hide it') and immediately disambiguates the two action modes. It is clearly distinguishable from siblings like get_room_questions or answer_question.

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 states the exact context ('rooms with human or AI moderation, where new questions wait for review'), rules for when hide vs approve applies, and routes the agent to get_room_questions for ids. Alternatives and preconditions are 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 cover the safety profile (idempotentHint=true, readOnlyHint=false), and the description adds genuinely new behavior: the already-open room is returned unchanged, the exact failure code room_limit_reached, and the required rooms:write scope. This is richer than the annotations alone.

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?

Front-loaded with the core action and idempotent behavior, then usage, then failure/auth notes. It is dense and semicolon-heavy in the first clause, but 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?

With no output schema, the description states the return value ('the room and its links'), the error path, and the required permission scope. Nothing an agent needs to invoke this 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?

Only one parameter, and schema coverage is 100% with a pattern and example already documented, so the schema carries the load. The description adds no syntax or format detail for 'code', making the baseline 3 correct.

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 precise verb+resource pair ('Open a prepared room, or reopen a closed one') and clarifies the state distinction between prepared/closed/already-open. An agent can distinguish this from close_room and create_room without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the preceding call ('after create_room with open=false') and the alternate use case ('to resume a session'). It also names close_room as the remedy when room_limit_reached occurs, giving a complete when-to-use and what-to-do-next path.

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