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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=false, so the write/non-destructive profile is covered. The description adds nothing beyond that: it does not say whether creating an event notifies attendees, whether it can fail on facility conflicts, or what the event type / isStartOnly interplay means for callers.

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 with no filler or repetition of the title. It is appropriately short, though its brevity contributes to the broader under-specification of the tool.

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 high-complexity creation tool with 13 parameters, nested objects, and event-type validation rules, a one-line description is inadequate. An output schema exists so return values need no explanation, but nothing is said about side effects on attendees/watchers, permission requirements, or the REGULAR/ALL_DAY and isStartOnly interaction.

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 13 richly documented parameters including nested objects and enum semantics, so the schema does the heavy lifting. The description adds zero parameter meaning, which is the baseline 3 for high-coverage schemas.

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 new schedule event in Garoon'), which is clear enough that an agent can distinguish it from the get-* siblings by verb alone. No explicit sibling differentiation is offered, but the resource and operation are 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?

No when-to-use guidance, no prerequisites (e.g., required permissions, event menu resolution, attendee/watcher lookup workflow), and no mention of any alternative tool. The agent gets no routing help beyond the face-value verb.

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 safe-read profile is covered by structured data. The description adds the parentId special-value semantics but says nothing about pagination, total counts, or return behavior beyond what annotations and the output schema 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?

Three short sentences with zero filler; the core action is front-loaded and the parentId guidance follows immediately. 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 an output schema present, return values need not be described, and the read-only annotations cover the safety profile. The description is complete for invocation, missing only cross-tool routing context that a sibling-heavy toolset would benefit from.

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 limit, offset, and parentId, including the same 1/-1/-2 special values. The description merely repeats the parentId values rather than adding format or interpretation beyond the schema, making 3 the correct baseline.

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

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

States a specific verb (Get) and resource (bulletin board categories) tied to Garoon, which is enough to tell it apart from siblings like garoon-get-bulletin-topics. It stops short of explicitly naming the closest sibling, so it is clear but not maximally differentiated.

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 one concrete usage instruction ('Use parentId to browse sub-categories'), which implies how to traverse the hierarchy, but offers no guidance on when to reach for this tool versus garoon-get-bulletin-topics or garoon-get-bulletin-topic. Usage is implied rather than stated.

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

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

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds essentially nothing beyond that, merely alluding to pagination, and omits auth requirements or behavior on invalid group IDs, so a baseline 3 is warranted.

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

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

One front-loaded sentence with the resource and scope stated first. The trailing clause about limit/offset is redundant with the schema, a minor waste, but the whole thing is short and readable.

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?

An output schema exists, so return values need no explanation, and all three parameters are fully schema-documented. The only gap is how to obtain a valid facilityGroupId, which is left implicit.

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 each parameter is documented with defaults and bounds, so the schema carries the meaning. The description only restates that limit/offset exist as optional, adding no new semantics 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?

States a specific verb ('Get') and resource ('facilities') scoped to 'a specific facility group', which distinguishes it from the sibling garoon-get-facilities (all facilities) by narrowing to a group. It never names the alternatives explicitly, but the scope is 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?

Usage is only implied: the required facilityGroupId suggests the caller must first know a group ID (e.g., from garoon-get-facility-groups), but the description states no when-to-use condition or contrast with garoon-get-facilities/get-facility-groups.

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, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the exact field set returned and, more importantly, the configuration-dependent failure mode where private-event comments are withheld. It stops short of describing error shape or permission requirements.

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 work: purpose and payload first, pagination second, failure caveat last. No filler, no repetition of the schema, and the most important information is front-loaded.

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

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

An output schema exists, so return-value documentation is not required, and the description still previews the fields. Combined with the pagination note and the environment-dependent error caveat, an agent has what it needs to call this correctly; only the precise error surface is left unspecified.

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 limit, offset, and eventId are already fully documented in the schema with ranges and defaults. The description only restates that limit/offset exist 'for pagination' without adding format or interaction detail, so the 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?

States a specific verb and resource ('Get the list of comments on a Garoon schedule event') and enumerates the returned fields (author, creation datetime, body, mentions). It is unambiguously distinct from siblings like garoon-get-schedule-events, which operate on events rather than their comments.

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 clear usage context: pagination via limit/offset, and an explicit condition under which the call fails (GAROON_PUBLIC_ONLY='true' hides private-event comments). It does not name a sibling alternative, but no sibling returns event comments, so there is no real alternative to route against.

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 safety profile is covered by structured data. The description adds nothing beyond that: it omits return format, pagination behavior, the public-only override, or any auth/permission context, leaving the description with no incremental behavioral 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?

A single, front-loaded sentence with no filler. It is efficient, though terse enough that it under-specifies rather than deliberately condensing.

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

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

With an output schema present and annotations covering the read-only profile, the description does not need to explain return values or safety. It is still missing usage context and pagination/override awareness for a 7-parameter tool, so it is adequate but not 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 description coverage is 100%, including detailed notes on target, rangeStart/rangeEnd RFC 3339 format, limit/offset defaults, and the showPrivate GAROON_PUBLIC_ONLY override. The description adds no parameter meaning beyond the schema, so the 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?

The description states a specific verb ('Search') and resource ('schedule events') scoped to a period, so an agent knows the core operation. However, it does not differentiate from sibling tools like garoon-search-available-times or garoon-get-schedule-event-comments, which also operate on schedule events.

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?

There is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives. 'In a specified period' implies a time-bounded lookup, but routing among the schedule/comment/available-times siblings is left entirely 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 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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered, but the description adds no further behavioral context such as rate limits, permission needs, or how attendee/facility combinations resolve. It essentially restates the purpose without behavioral detail.

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 with no filler, clearly placing the verb and resource first. It is efficient, though its brevity borders on under-specification for a 5-parameter tool.

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

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

With an output schema present and full schema coverage, the description need not explain return values. However, it omits meaningful context about how attendee versus facility searches behave and how timeInterval shapes results, leaving it adequate but not complete for a moderately complex query 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%, so the schema fully documents attendees, facilities, timeRanges, timeInterval, and facilitySearchCondition. The description names the concepts but adds no meaning beyond what the schema already provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource ('Search for available time slots') with scope ('for specified attendee or facility within given time ranges'), so an agent understands exactly what the tool returns. It does not, however, distinguish itself from scheduling siblings like garoon-get-schedule-events, which also concern calendars.

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 offers no when-to-use guidance, no prerequisites, and no mention of alternatives. There is no indication of when to prefer this availability search over fetching existing schedule events, so the agent must infer the scenario entirely.

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