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

Annotations are present but minimal (readOnlyHint=false, destructiveHint=false, etc.), and they don't contradict. The description is sparse, but the schema provides substantial behavioral context, such as conditional requirements (end required when isStartOnly=false, eventType affects validation), defaults, and the distinction between isAllDay and ALL_DAY. The description itself doesn't add much, but it doesn't need to since the schema is rich. However, it doesn't mention any side effects like sending notifications to attendees, which might be expected. With annotations covering the basic safety profile, a 4 is justified due to the lack of contradiction and the schema's richness.

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, concise sentence that clearly states the tool's purpose. It is appropriately short and front-loaded. However, it could be slightly more informative without losing conciseness, such as mentioning that it creates a calendar event. But given the tool's name and schema, it is efficient. A 4 is reasonable.

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 (13 parameters, nested objects, conditional logic, output schema) and the rich schema descriptions, the description itself is minimal but the schema carries the context. The output schema is present, so return values are not needed. However, the description does not mention any prerequisites like authentication, required permissions, or how to handle facility usage, which might be important. With the schema being thorough, but the description lacking any high-level guidance, a 3 is appropriate.

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 baseline is 3. The description of the tool does not add any parameter semantics beyond what the schema provides. However, the schema descriptions are quite detailed, explaining nuances like isAllDay vs ALL_DAY and the conditional requirement for end. The tool description itself doesn't go beyond the schema, but the schema does the heavy lifting, so a 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 clearly states it creates a new schedule event in Garoon with a specific verb and resource. However, it does not differentiate from sibling tools like garoon-get-schedule-events, but that is less critical for a create operation. The purpose is specific enough, but could mention that it adds an event to a calendar.

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 no explicit guidance on when to use this tool vs alternatives. However, the context of creating a schedule event is implicit from the name and description, and sibling tools are mostly for reading (get) or searching, so the usage is inferred. However, there is no exclusions or alternatives mentioned, so a 3 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?

With readOnlyHint=true, the agent already knows it's a safe read. The description adds the special parentId values (1, -1, -2) which are not fully explained by the schema, and clarifies browsing behaviorais, but it doesn't disclose pagination details or response structure. Given the annotations cover safety, the description adds useful context.

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, front-loaded with the primary purpose, and each word earns its place. It efficiently communicates the core action and the critical parameter nuance without waste.

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 simplicity (3 optional parameters, output schema exists, readOnly annotation present), the description is sufficiently complete. It covers the purposechers, the special parentId values, and there is nothing critical missing for a list-retrieval 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 schema already has 100% coverage of parameters, including the special values for parentId, so the description adds little beyond what the schema provides. The description reinforces the parentId behavior but offers no new meaning for limit or offset. 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?

The description clearly states the action ('Get bulletin board categories') and the resource ('from Garoon'), and it distinguishes the tool from siblings by focusing on categories rather than topics or facilities. It also introduces the key parameter (parentId) for browsing sub-categories.

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 usage by mentioning 'browse sub-categories' and special parentId values, but it does not explicitly say when to use this tool instead of alternatives or when not to use it. However, the special values provide clear context for when to use those values.

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, covering the safe-read behavior. The description adds useful context about what the response will include (body, attachments, public period, metadata), but it does not disclose behaviors such as error conditions or behavior for invalid topic IDs. This is acceptable but not rich, given the read-only annotations.

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 well-structured sentence that states the action and key detail inclusions with no redundant wording. It earns its place by differentiating the tool and informing the agent of what to expect.

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 single-parameter read-only detail endpoint with an output schema and readOnlyHint annotation, the description is sufficiently complete. It identifies the topic, the target system, and the expected content categories; the output schema handles the rest of the return shape.

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

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

Schema coverage is 100%: the lone parameter topicId has a clear description and pattern in the schema. The tool description only mentions "specific topic" and does not add meaningful semantic information beyond what the schema already provides, so the baseline score of 3 applies.

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

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

Description starts with "Get full details of a specific bulletin board topic from Garoon"—a specific verb, resource, and scope that clearly identifies the action. It distinguishes itself from sibling list tools like get-bulletin-topics by emphasizing "specific" and enumerating the detail fields (body, attachments, public period, metadata).

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

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

The description implies this is the tool to call when a single topic's full detail is needed, especially in contrast to the list sibling. However, it does not explicitly state when to prefer get-bulletin-topics or any exclusion criteria, so guidance is only implicit rather than clearly articulated.

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 mentions that it returns topic summaries with specific fields, and the readOnlyHint annotation already indicates no side effects. It does not describe pagination behavior, but the schema includes limit/offset, so that is partially covered. The description adds clarity on the return content.

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, front-loaded with the main action and followed by the return type. It is concise and free of extraneous 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?

The description covers the essential function and return data. It does not mention potential edge cases or sorting, but for a simple retrieval tool, this is sufficient. The schema provides parameter details, so the context is adequate.

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 provides detailed descriptions for each parameter (categoryId, limit, offset), so the description does not need to add parameter semantics. The coverage is 100%, so a 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 clearly states the action (get bulletin topics), the resource (bulletin board topics in a category), and the context (from Garoon). It also specifies the returned data, making the purpose unambiguous.

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 does not explicitly mention when to use this tool over alternatives, such as when needing schedule events or facilities. However, it is clear that it is for bulletin topics, which is a distinct resource. It could benefit from stating that it is for retrieving data, but it is 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?

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context by specifying RFC 3339 format and the Garoon scope. It does not contradict annotations and no side-effect disclosure is needed for a read-only clock tool.

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?

Single sentence, front-loaded with the verb and resource, no redundant words. Every element 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 one optional parameter, a full schema description, output schema, and read-only annotation, the description is nearly complete. It could mention the default timezone behavior when the parameter is omitted, but this is a minor gap for a low-complexity 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 description coverage is 100% and the timezone parameter is fully described in the schema. The tool description adds no additional parameter semantics, such as default timezone behavior when omitted, so baseline 3 applies.

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

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

Description uses specific verb 'Get' with resource 'current datetime' and specifies output format 'RFC 3339 format' and scope 'in Garoon'. This clearly distinguishes it from sibling tools, none of which concern current time.

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

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

The description establishes clear context: use when you need the current datetime in RFC3339 from Garoon. It does not explicitly name alternatives, but no sibling tool provides this capability, so exclusions are unnecessary.

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, so the read-only nature is covered. The description only adds the search-by-name and limit/offset behavior, which is already present in the schema, so no meaningful extra behavioral context is disclosed.

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 contains the essential information: the action, resource, search criterion, and pagination parameters. No filler or redundancy.

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 simple tool shape, full schema coverage, readOnly annotation, and presence of an output schema, the description is largely sufficient. It only lacks explicit guidance on search matching semantics (exact vs. partial) and differentiation from sibling tools.

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 input schema fully documents name, limit, and offset. The description's mention of 'optional limit and offset parameters' adds no semantics beyond what the schema already states.

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 uses a specific verb ('Get') and resource ('facilities data from Garoon') with clear scoping ('by searching facility names'). It does not explicitly distinguish from the sibling 'garoon-get-facilities-in-group', but the search-by-name scope is reasonably clear.

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 when to use it—when you need facilities matched by name—but provides no explicit guidance about when to prefer alternatives like garoon-get-facilities-in-group or how to choose between similar get tools.

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 annotations declare readOnlyHint=true and openWorldHint=false, which already cover safety (read-only) and closed-world expectations. The description adds the optional limit/offset behavior, which is a mild behavioral detail. It doesn't elaborate on pagination semantics or error cases, but given annotations are present, the bar is met.

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 sentence, efficient and front-loaded with the main purpose. It conveys the essential action without waste.

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 is a simple read operation with a clear output schema, the description plus annotations and schema provide sufficient context. The only minor gap is lack of explicit pagination details, but that is covered by the parameter descriptions. The output schema exists, so return value details are not needed in the description.

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 parameters (facilityGroupId, limit, offset) are well-documented in the schema with types, defaults, and patterns. The description simply mentions 'optional limit and offset' without adding new meaning. Baseline 3 is appropriate since schema carries the load.

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 tool retrieves facilities belonging to a specific facility group, which is specific enough to differentiate from sibling tools like get-facilities (all facilities) and get-facility-groups (groups only). The verb 'get' and resource are identified, though the title already implies this.

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 provides a basic context of what it does (list facilities in a group) but does not explicitly state when to use this over siblings. The sibling list includes get-facilities and get-facility-groups, but the description does not mention alternatives or exclusions. Usage is implied 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?

The description is consistent with the readOnlyHint=true annotation, and no contradiction exists. Beyond the annotations, the description adds that limit and offset are optional, but this information is already present in the input schema, so no additional behavioral context (e.g., default pagination behavior, ordering) is disclosed.

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 one concise sentence that communicates the action, resource, source, and key optional parameters without unnecessary words. It is appropriately front-loaded and every word 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 simple read-only list tool with two optional parameters, a present output schema, and readOnlyHint annotation, the description is mostly complete. It adequately indicates what data is returned and the pagination knobs, though it could have noted that it returns all facility groups when no filters are applied, which would have made it more 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%, with both limit and offset already fully described including ranges and defaults. The description merely mentions 'optional limit and offset parameters' without adding any semantic value beyond the schema, so the baseline score 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 clearly states the verb ('Get') and resource ('facility groups data from Garoon'), making the tool's function unambiguous. It does not explicitly name sibling tools like get-facilities or get-facilities-in-group, but the resource name itself differentiates it from those alternatives.

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?

No guidance is provided about when to use this tool versus sibling tools. The description only states what it does, without mentioning related tools (e.g., get-facilities, get-facilities-in-group) or any exclusions, leaving the agent to infer the appropriate use case.

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, so no contradiction. The description adds useful context about search behavior and pagination support, but it does not disclose edge behavior such as no-results handling or response format details beyond what the output schema presumably provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that conveys the tool's purpose, search behavior, returned fields, and pagination support. Every phrase earns its place with no padding or unnecessary 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?

Given the low complexity, full schema coverage, read-only annotations, and presence of an output schema, the description provides sufficient context. It covers the core purpose, search input, returned fields, and pagination without requiring elaboration on return values.

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 name, limit, and offset with clear semantics. The description's mention of 'name, ID, and code data' and pagination adds some alignment but little new 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?

Clearly states the verb (get), resource (Garoon organizations), scope (search by organization names), and returned fields (name, ID, code). This distinguishes it from sibling tools like garoon-get-users and garoon-get-users-in-organization.

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 when to use it: when you need to look up organizations by name. However, it does not explicitly distinguish when to use this tool over related sibling tools, nor does it mention exclusions or alternative tools.

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 openWorldHint=false, establishing the read-only safety profile. The description adds the period-based search scope but does not mention pagination, private-event handling, or target-type implications, though it does not contradict the annotations.

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 sentence that immediately states the action and scope with no filler or redundant detail. It is concise and 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 schema and output schema provide strong parameter and result context, and annotations cover safety. However, the description lacks sibling differentiation and does not highlight relevant behavioral nuances, leaving some contextual gaps for an agent choosing among schedule-related tools.

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%, with rich detail for all 7 parameters including defaults, enum values, and the GAROON_PUBLIC_ONLY override behavior. The description itself adds no parameter semantics, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Search') and resource ('schedule events') with a specified period, clearly indicating the tool's core function. It does not explicitly differentiate this from the sibling tool 'garoon-search-available-times', which is also schedule-related.

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?

No guidance is provided on when to use this tool versus alternatives such as 'garoon-search-available-times' or 'garoon-create-schedule-event'. The description only states the basic action, leaving the agent to infer usage context from the sibling list.

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 openWorldHint=false, so the description does not need to restate that it is read-only. It adds value by disclosing the special self-referential behavior and supports pagination, which are not covered by annotations. No contradictions exist.

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 concise and front-loaded. It states the core purpose in the first sentence, follows with a critical usage note, and ends with pagination support. No redundant or extraneous wording exists; every sentence contributes 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?

The tool is relatively simple, has an output schema, and sufficient annotations. The description covers the returned fields (name, ID, code), the searchable criteria (name/code), pagination, and the self-referential edge case. It does not mention prerequisites like authentication, but given the read-only nature and existing schema, it is adequately 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?

Input schema coverage is 100% with detailed parameter descriptions, including the IMPORTANT note about omitting the name parameter for self-referential queries. The tool description repeats this note and mentions pagination, but does not add significant meaning beyond what the schema already provides, so a baseline score 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 clearly states the tool retrieves user data (name, ID, code) from Garoon by searching name/code. It uses a specific verb (Get), names the resource (user data), and mentions the search method, which distinguishes it from sibling tools dealing with schedules, facilities, or bulletins.

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 provides clear context by specifying how to use the tool for standard name/code searches and highlights a critical usage note for self-referential queries (omitting the name parameter). It does not explicitly mention alternatives or when not to use it, but given the sibling list, its purpose 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?

Annotations already declare readOnlyHint=true, so the safe read-only nature is clear. The description adds mention of pagination, but that is also visible in the schema. No additional behavioral details (e.g., rate limits, ordering) are provided, so the description adds minimal value beyond the annotations.

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, focused sentence that gets straight to the point. It includes the core purpose and relevant parameters without any filler or redundant wording, making it highly concise.

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 3 parameters fully documented in the schema, a readOnly annotation, and an output schema present, the description is adequate. It could slightly elaborate on pagination defaults or edge cases, but these are already in the schema, so the overall completeness is high.

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 covers 100% of parameters with descriptive text, so the baseline is 3. The description only restates the organization scope ('specific organization') which is already implied by the organizationId parameter name and description, adding no 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?

The description clearly states the action (get users) and the specific scope (a specific organization), which distinguishes it from sibling tool garoon-get-users that likely returns all users. It also mentions pagination support, making the purpose precise.

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 fetching users within a single organization, which provides clear context. However, it does not explicitly mention when not to use it or contrast with alternatives like garoon-get-users for all users, so it falls short of an explicit 5.

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 declare readOnlyHint=true, confirming this is a safe read operation. The description adds that it searches within given time ranges but does not describe what the output contains (e.g., the format of available time slots) or any constraints like maximum time range duration. Since annotations cover safety, a moderate score reflects minimal additional behavioral context.

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, clear sentence that conveys the tool's purpose without redundant information. It is appropriately front-loaded, stating the action and key targets. Slight improvement could be made by separating the purpose from non-essential details, but overall it is concise and structured well.

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

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

With a 100% schema coverage, detailed parameter descriptions, and an output schema present, the description does not need to explain return values. The tool is complex due to multiple parameter types and combinations, but the schema and annotations cover the essentials. The description is complete enough for an agent to understand when and how to invoke it, though it could benefit from noting that both attendees and facilities can be specified simultaneously, which the schema implies but the description does not highlight.

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%, with detailed descriptions for each parameter (e.g., attendees identified by type and id/code, timeRanges in RFC 3339 format). The description adds minimal nuance beyond the schema, such as the logical operator for facilities, but does not explain the relationship between attendees and facilities (e.g., whether both must be free simultaneously). Thus, it provides adequate but not extensive semantic enhancement.

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 tool searches for available time slots for specified attendees or facilities within given time ranges in Garoon. It distinguishes itself from sibling tools like `garoon-get-schedule-events` (which retrieves events) and `garoon-get-facilities` (which lists facilities), making its unique purpose evident.

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 usage for checking availability before scheduling, with clear required parameters (timeRanges, timeInterval). However, it does not explicitly state when not to use this tool or mention alternative tools for other scheduling operations, such as `garoon-create-schedule-event` which would be used after finding availability.

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