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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful cross-drive capability note but omits key behavioral facts for a copy operation: whether an existing destination file is overwritten, what the response contains (e.g., the new file ID), and any permission/auth requirements implied by openWorldHint.

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 leading sentence is front-loaded and clear, and the compact example is genuinely useful for a tool with four ID parameters. The 'Required' bullet list largely duplicates the schema, costing some efficiency but not much space.

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 mutation tool with no output schema, the description should say something about the result (e.g., the copied file's new ID) and about overwrite behavior at the destination. The cross-drive note and example help, but these two gaps keep it at minimum-viable.

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 all four parameters; the baseline is 3. The description repeats the schema text nearly verbatim, adding only the clarification that destinationDriveId may equal driveId, which is a marginal but genuine addition.

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 (copy a file) and names the domain (Dooray drive) plus the destination concept. It does not explicitly differentiate itself from sibling 'move-drive-file', which is the closest alternative, but the verb 'copy' is distinct enough that an agent can infer the difference.

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 by the word 'copy' — no explicit statement of when to pick this over move-drive-file, update-drive-file, or upload-drive-file. The note that the destination drive can be the same or different adds a useful scoping hint but is not real when/when-not guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is covered; the description adds genuinely non-obvious behavior: the whole-day endedAt must be the *next* calendar day, the date-plus-offset format for all-day times versus full ISO-8601 for timed events, and that the call returns {id}. It lacks any note on permissions/scopes or rate limits, which is the main remaining gap for a mutation 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?

Headers and labeled examples make it skimmable, and it front-loads the required fields plus the calendarId source before diving into formats. There is some duplication — the whole-day date format appears in the Time Format block, again in the examples, and again in the schema descriptions — but the redundancy is defensible for an error-prone field.

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 13-parameter nested tool with no output schema, the description covers the highest-risk areas an agent would otherwise get wrong: time encoding, all-day end-date semantics, attendee ID sourcing, and the {id} return. It stops short of explaining the optional blocks (cc, alarms with RFC 2445 triggers, visibility, busy), relying entirely on the schema for those.

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, but the description earns above that by explaining the interaction between wholeDayFlag and the two timestamp formats, the {id,type} attendee shape with 'member' vs 'email' resolution paths, and by supplying a concrete recurrenceRule payload. Optional fields like cc, alarms, visibility, busy and body carry no added narrative beyond their schema descriptions.

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

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

States a specific verb and resource ("Create an event in a Dooray calendar") with the localized term 일정 등록, so there's no ambiguity about the operation. The create/update/delete distinction from siblings like update-calendar-event and delete-calendar-event is implied by the verb but never made explicit, which keeps it just below a 5.

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 prerequisite flow — get calendarId from get-calendar-list (with the default=true shortcut) and resolve attendee IDs via get-my-member-info, get-project-member-list, get-member-list. It gives clear context for how to use the tool but never states when to prefer update-calendar-event over creating a new event, so no true exclusions are offered.

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=false, destructiveHint=false, and openWorldHint=true, so the agent knows this is a non-destructive write operation. The description adds that a parent folder is required and that the created folder ID is returned, but it does not mention permissions, naming conflicts, or rate limits.

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 front-loaded with the purpose, then lists required parameters, gives an example, and states the return value. The required-parameter list is somewhat redundant with the schema, but overall it is efficient and easy to scan.

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 three-parameter creation tool with annotations covering safety and no output schema, the description provides enough context: purpose, required inputs, an example, and the return value. It could be slightly more complete with error or permission behavior, but the essentials are present.

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 all three parameters. The description repeats those definitions and adds a concrete example, which is mildly useful, but it does not add semantic detail beyond the schema.

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

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

The description states a specific verb and resource: 'Create a new folder in a Dooray drive.' This clearly distinguishes it from sibling tools like create-task or upload-drive-file, which operate on different resources.

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 lists required parameters and gives an example, but never states when to use this tool versus alternatives or any preconditions. There is no explicit usage context or exclusion guidance.

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

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

Annotations already declare write/non-destructive/open-world behavior. The description adds meaningful behavior beyond that: dueDateFlag state combinations, defaulting semantics, and that the created template ID is returned. It omits permission/auth requirements and uniqueness constraints, so it is strong but not complete.

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 front-loaded with purpose, then organized into required fields, optional fields, due-date flag rules, and examples. Some bullets repeat schema field descriptions, but the structure is appropriate for a 12-parameter tool with nested objects.

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 no output schema, the description usefully states that the created template ID is returned. It covers required and optional fields, due-date edge cases, and examples. It does not cover permission requirements, possible errors, or template-name uniqueness, but is complete enough for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real semantics beyond the schema, especially the dueDateFlag combinations, priority values, body/guide mime types, and usage examples. Nested users object details are left to the schema.

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

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

The description states a specific verb and resource: 'Create a new task template in a Dooray project.' The word 'new' distinguishes it from update/delete/list template siblings, and the template definition adds useful context.

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 explains what templates are and gives examples, implying when the tool is useful. However, it does not explicitly say when to use this versus update-project-template or get-project-template, nor does it state when-not conditions, so usage guidance is only 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=false, destructiveHint=false, and openWorldHint=true, so the bar is lower, yet the description adds real value: the default-color fallback behavior, the hex color format constraint, the fact that identical group prefixes auto-group, and the exact response shape ({id}). That is behavioral context the agent could not get from 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 statement and organized under bold headings, so scanning is cheap. The examples section partially duplicates the JSON already given inline under Tag Types and the schema, which is mild redundancy but not damaging.

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 3-parameter creation tool with no output schema, the description covers purpose, both input modes, color constraints, the default-color behavior, the return value, and the natural next step (update-tag-group). 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 100%, so the baseline is 3, but the description adds semantics beyond the schema: the grouping side effect of the 'groupName:tagName' prefix and the concrete color-format rules with worked examples. Only 'projectId' gets no extra explanation, which keeps it from a 5.

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 ('Create a new tag in a Dooray project') and immediately disambiguates the two modes of the operation (individual vs. group tag). An agent can distinguish this from get-tag, get-tag-list, and update-tag-group 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?

Explains the two usage modes clearly: plain 'tagName' for standalone tags, 'groupName:tagName' when the tag should be grouped, and points to update-tag-group for configuring group behavior afterward. It stops short of stating prerequisites or when *not* to create a tag (e.g., duplicate handling), so it is clear context without explicit exclusions.

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?

Adds real behavioral context beyond the annotations: draft creation returns a URL instead of persisting, mandatory tag groups cause a 500 error if unsatisfied, and selectOne groups require exactly one tag. This is high-value failure-mode disclosure, though permission/auth requirements and whether creation is reversible are not addressed.

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 purpose and required params, then uses bolded sections and numbered steps so structure is easy to scan. It is somewhat long and repeats the assignee/tag guidance that also lives in the schema, but every block is functional.

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 an 11-parameter, nested-object creation tool with no output schema, the description supplies the draft/regular return shapes and the critical tag-prerequisite rule. Remaining gaps (auth, error handling beyond the 500 note) are minor given the rich schema.

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 every parameter including the assignee/CC object shape and enum values. The description adds only a marginal detail (extracting projectId from a Dooray URL) plus priority defaulting, which is already in the schema — 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?

Opens with a specific verb+resource ('Create a new task (업무) in a Dooray project') and immediately names the two required parameters. It is trivially distinguishable from siblings like update-task, create-task-comment, and get-task.

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 tells the agent to ask the user whether to create a draft vs. regular task and gives the conditions for each. It also enumerates a step-by-step interactive workflow with named prerequisite tools (get-project-template, get-tag-list, get-my-member-info), so when-to-use and when-not-to-use are both covered.

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=false, destructiveHint=false, and openWorldHint=true, so the mutation/safety profile is known. The description adds real behavioral context beyond that: the attachment workflow requires uploading files first via the file upload API and then passing returned IDs, and it states the return shape ("Created comment with ID"). It does not cover permission requirements or failure modes, so it stops short of a 5.

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?

Well structured and front-loaded: purpose, then routing decision, then URL parsing, then attachments, then format, then examples. The main cost is length — three example payloads where the first two differ only in content strings, which could be collapsed without losing 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?

Handles the tool's real complexity: a nested body object, a required format enum, an optional file-attachment path with a prerequisite step, and ID extraction from a URL. It also states the return value even though no output schema exists, so an agent has everything needed to invoke it correctly on the first try.

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 100%, so baseline would be 3; the description earns above baseline by explaining how to derive projectId and taskId from a Dooray URL, and by spelling out the body envelope shape with mimeType/content examples. The attachFileIds ordering constraint is also restated with operational meaning rather than just a type.

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?

Opens with a specific verb+resource ("Add a comment to an existing Dooray task") and immediately separates it from the nearest alternative by noting it is "separate from editing the task body itself." An agent can distinguish this from update-task, update-task-body, and update-task-comment 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?

Includes an explicit "When to Use" block contrasting create-task-comment (discussion, updates, notes) against update-task (description, title, metadata). It also enumerates concrete use cases (progress updates, answering questions, logging info, attaching files with context), 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 declare this is a non-read-only, non-destructive, open-world mutation; the description adds the critical failure mode (400 error without parentPageId), the exact error text, the markdown content format, and the returned fields (id, wikiId, parentPageId, version). That is substantial behavioral context 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?

Front-loaded with purpose, then bolded sections for required/optional, the parentPageId pitfall, and the workflow, which makes it scannable. There is mild redundancy: the required/optional lists duplicate the schema, and parentPageId appears in neither list before being discussed separately.

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 6-parameter mutation with no output schema, the description covers prerequisites, ordering, the main failure mode, content format, and return values. Nothing an agent needs to invoke it successfully 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 still adds real meaning by flagging parentPageId as effectively mandatory and by naming the fields of the referrers/attachment inputs. The required/optional lists largely restate the schema, which caps the score below 5.

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 ('Create a new wiki page') and clearly differs from siblings like update-wiki-page, move-wiki-page, and create-wiki-page-comment. An agent can identify it immediately 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?

Provides an explicit three-step workflow naming the prerequisite tools (get-wiki-list, get-wiki-page-list) and the condition under which each is needed. It also warns that parentPageId is 'practically required' despite not being in the required array, which is precisely the kind of when-to-use guidance that prevents failed calls.

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 it is a non-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds that content must be markdown and that an id is returned, but says nothing about permissions, whether the page must be open for comments, or failure modes.

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 waste, front-loaded with the action and resource. The return value is stated inline rather than buried.

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 only three fully-documented required parameters, no output schema, and annotations covering the safety profile, the description supplies what an agent needs to invoke it correctly. It is slightly thin on preconditions for commenting on a page, but no major gap remains.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description's 'Content is in markdown format' restates the schema's own parameter description rather than adding new semantics, 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?

States a specific verb and resource: create a comment on a wiki page, which is clearly distinct from sibling create-wiki-page and update-wiki-page-comment. It omits explicit sibling differentiation but the verb+resource pair 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as create-task-comment or update-wiki-page-comment. Usage is only implied by the verb 'Create'.

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 already declare destructiveHint=true, and the description adds useful context: the deletion is irreversible, the file is permanently removed from the task, and the return is a success message. It does not cover permissions or error behavior, but it adds meaningful destructive-operation context beyond 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 purpose is front-loaded, followed by organized parameter, example, return, and warning sections. Some parameter text duplicates the schema, but the overall length remains appropriate for a destructive 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 no-output-schema destructive tool, the description covers the required inputs, an example call, the return message, and the irreversibility warning. Minor gaps around authorization or failure modes remain, but the core invocation context 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 baseline is 3. The description adds value by identifying where fileId comes from (get-attachment-list) and provides a concrete example payload with all three IDs.

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 and resource: 'Delete a file attachment from a Dooray task.' This clearly distinguishes it from sibling tools such as delete-drive-file, delete-wiki-page-file, and delete-task-comment.

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 a clear prerequisite by telling the agent to get the fileId from get-attachment-list. It does not explicitly compare when to use this versus similar deletion tools, but the task-attachment scope is clear.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so safety is covered. The description adds real behavioral context the annotations don't carry: the three deletion scopes for recurring events and the prerequisite of using the occurrence event ID. It could go further on irreversibility or permission requirements, hence not a 5.

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?

It is front-loaded with purpose, then groups recurring-event semantics under a bolded heading and ends with concrete examples. Every section earns its place; the parenthetical Korean gloss is minor noise but harmless.

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 3-parameter destructive tool with no output schema, the description covers purpose, mode semantics, prerequisite lookup, and even the return value ('success message'). The only remaining gap is the absence of an explicit irreversibility warning, though destructiveHint already signals this.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns extra credit by expanding deleteType far beyond the schema's one-line description, enumerating each enum value and stating the default ('this'), which is exactly the semantics an agent needs to choose correctly.

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

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

The description opens with a specific verb and resource ('Delete a Dooray calendar event') and scopes it against siblings like update-calendar-event and create-calendar-event. The recurring-event subsection further refines what "delete" means in this context, so an agent can identify the tool 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?

It gives concrete conditions for the deleteType modes and explicitly directs the agent to get-calendar-event-list to obtain the correct occurrence event ID for recurring events. It stops short of explicitly stating when not to use it (e.g., to cancel a single instance the agent should use update instead), so it is clear guidance without full exclusions.

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 already declare the operation as destructive and non-read-only. The description adds meaningful behavioral context by emphasizing that deletion is permanent and that the file must already be in the trash, although it does not discuss permissions, error cases, or rate limits.

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 short, front-loaded with the permanent-delete scope, and then immediately gives the critical prerequisite. The required-parameters list and compact example are easy to scan without wasted prose.

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 destructive two-parameter tool with full schema coverage and annotations covering safety traits, the description supplies the essential prerequisite and alternative action. No output schema exists, but the return behavior is not necessary for correct invocation here.

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 both parameters are already documented in the schema. The description repeats the required parameters and gives an example, but adds little semantic detail beyond the schema, which already notes that fileId must be in trash.

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 and resource: permanently delete a file from a Dooray drive trash. It distinguishes this operation from moving a file to trash by explicitly naming move-drive-file as the prerequisite alternative.

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 key precondition that the file must already be in the trash folder, and it names the exact alternative tool and parameter needed to get the file there first. This gives an agent explicit when-to-use and how-to-prepare guidance.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds meaningful behavioral context by emphasizing that the deletion cannot be undone and by stating that it returns a success status.

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 warning is front-loaded and the sections are easy to scan. The Required Fields section largely duplicates the schema and the example is somewhat redundant, but the overall structure remains efficient.

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 destructive template-deletion tool with no output schema, the description covers the irreversible nature of the action, both required IDs, how to obtain the template ID, and the success response. The annotations carry the rest of the safety profile.

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 parameters are already documented. The description adds value by explaining where to obtain templateId via get-project-template-list and includes a concrete example payload, going beyond the schema text.

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: delete an existing task template from a Dooray project. It clearly distinguishes this from sibling operations such as get-project-template, create-project-template, and update-project-template by naming the template resource and deletion action.

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

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

It gives clear usage context by warning that the action is permanent and by directing the agent to get-project-template-list to obtain template IDs. It does not explicitly state when not to use it or contrast it with update-project-template, but the destructive 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 destructiveHint=true and openWorldHint=true, so the irreversibility is known; the description echoes it ('This cannot be undone') rather than adding new behavioral detail. The confirm-first step is the only genuine addition, and it doesn't discuss permissions or what happens to replies/linked data.

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 purpose, then the irreversibility warning and confirmation step, then an example. The format is efficient for a destructive tool, though the 'Returns: success message' line and Korean gloss are minor extras.

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 3-param destructive tool with no output schema, the description covers purpose, irreversibility, a pre-check step, an example call, and the return shape. Missing only permission/authorization requirements and scope of what gets removed.

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 projectId, taskId, and commentId are all documented in the schema. The worked example shows plausible value shapes but adds no semantics beyond the structured fields, 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?

States a specific verb and resource (delete a comment on a Dooray task) and the Korean gloss disambiguates the resource. Siblings like update-task-comment and delete-wiki-page-comment are clearly differentiated by the 'task' qualifier.

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 instructs to confirm the target with get-task-comment before deleting, which gives an agent a concrete prerequisite workflow. It doesn't state when the operation should be avoided entirely or name alternatives beyond the read counterpart, so it stops short of a full 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 destructiveHint=true and readOnlyHint=false, so the risk profile is known. The description adds useful nuance by implying child pages are affected and must be checked first, but it never states whether the delete is permanent, what happens to children/attachments/comments, or whether confirmation is enforced server-side.

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

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

Two short sentences, front-loaded with the action and followed by the safety workflow. Every clause 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 two-parameter destructive tool with full schema coverage and clear safety annotations, this covers the essentials plus a verification workflow. The remaining gap is the consequence model (irreversibility, child-page fate) that an agent would want before committing.

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 only two required parameters (wikiId, pageId), both fully documented in the schema. The description adds no format, sourcing, or scoping guidance for either ID, so the baseline 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?

States a specific verb and resource ('Delete a wiki page'), which cleanly separates it from the many sibling delete tools (delete-wiki-page-comment, delete-wiki-page-file, delete-drive-file). The Korean gloss adds nothing but costs nothing. It does not explicitly name a sibling alternative, so it falls just short of 5.

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 preconditions: confirm the target with get-wiki-page and inspect children with get-wiki-page-tree. That is real, actionable routing advice tied to named sibling tools. It stops short of saying when NOT to delete or what to do if children exist.

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, openWorldHint=true and readOnlyHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that – no note that the operation is irreversible, what permissions are needed, or what happens on failure.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity comes at the cost of omitting any warning an agent would want for a destructive call.

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 destructive, required-3-param tool with no output schema, the description should at minimum flag irreversibility or confirmation expectations. Those are absent, leaving an agent with a mutation that has no behavioral framing.

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 all three IDs documented and required, so the schema does the heavy lifting. The description adds no meaning about the identifiers or their relationships.

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?

Specific verb+resource ('Delete a comment on a wiki page') that clearly distinguishes it from create/update/get-wiki-page-comment siblings. It never names those alternatives, but the operation type alone 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?

No guidance on when to use this versus update-wiki-page-comment or delete-task-comment, and no mention of prerequisites or that the deletion is permanent. The agent must infer all of this from the name.

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 and openWorldHint=true, and the description reinforces this with concrete consequences: the action is irreversible and the file is permanently removed from the page. It also states the response is a success confirmation, adding detail beyond the structured fields, though permission/ownership requirements stay unstated.

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 one-sentence purpose, then organized into required params, example, returns, and note. Slightly padded by a JSON example that merely restates the schema, but no section is misleading or 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?

For a destructive three-param tool with no output schema, the definition covers the operation semantics, how to obtain the key identifier, the irreversibility warning, and the return shape. Nothing an agent needs to invoke 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 all three IDs are documented by the schema itself, establishing a baseline of 3. The description adds real value by explaining where to source fileId ($.result.files.id or $.result.images.id), but says nothing extra about wikiId or pageId.

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: delete a file attached to a Dooray wiki page. The compound scope (wiki page file, not the page or a drive file) is clear enough to separate it from delete-wiki-page, delete-attachment, and delete-drive-file, though it never names those siblings explicitly.

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 implied by the resource boundary rather than stated: an agent can infer this deletes page attachments only. There is no explicit when-to-use/when-not guidance pointing to delete-wiki-page or delete-attachment for adjacent operations, though the note on where to obtain fileId is a practical aid.

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 give readOnlyHint=false, openWorldHint=true, destructiveHint=false, so write-side effects need description coverage. The description supplies real substance: original filenames preserved, non-overwriting default, and partial-failure semantics where successful downloads survive and the result lists both sets. It stops short of stating filesystem permission or auth requirements, which is the main remaining gap.

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

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

Front-loaded with the one-sentence purpose, then behavior, then a compact example, then the return shape. Every sentence adds information; nothing restates the tool name or wastes space.

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?

There is no output schema, and the description compensates by naming the return fields (count, succeeded[fileId, savedTo, size], failed[fileId, name, error]). Combined with the overwrite and partial-failure rules, an agent has enough to invoke and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining the consequence of overwrite=true (existing files are not overwritten unless set) and by giving a concrete example populating projectId, taskId, and saveDir. It also notes saveDir is created if missing, which is behavioral meaning beyond the raw field type.

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+scope: 'Download every file attached to a Dooray task into a local directory.' The word 'every' distinguishes it from the single-file sibling download-attachment, so an agent can route correctly without reading 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?

Bulk-vs-single usage is only implied by 'every file attached to a task' against siblings like download-attachment and get-attachment-list. There is no explicit 'use this when... instead of download-attachment/upload-attachment' statement or exclusion, so selection still requires 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 flag readOnlyHint=false and openWorldHint=true, and the description adds real value on top: it explains the two output modes (base64 in-memory vs on-disk savePath), filename auto-detection for directories, and documents the full response field set. It omits overwrite semantics for savePath and permission/error behavior, which matters for a tool writing to local disk.

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 one-line purpose followed by grouped required/optional/response sections and two tight examples. The response-field block is long but earns its place since no output schema exists; a little redundancy between the parameter list and the examples.

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 supplies the return shape (success, filename, contentType, contentLength, savedTo, base64Data) and the mode-selection logic, which is what an agent needs to call and interpret it. Missing only failure/overwrite behavior and any size limit guidance beyond 'small files' vs 'large files'.

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 semantics are already documented; the description nevertheless adds 'Can be a directory (filename auto-detected) or full file path' for savePath and its large-file recommendation, plus concrete example payloads for both modes. Genuine value beyond the schema, though no format constraints or error cases are given.

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 ('Download a file attachment from a Dooray task'), which cleanly distinguishes it from the drive/wiki download siblings in the tool list. An agent can select it 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?

'fileId: get from get-attachment-list' gives an explicit prerequisite and routes the agent to the sibling that produces the ID, and 'Recommended for large files' clarifies when to use savePath. It stops short of naming when to prefer download-all-attachments or the drive/wiki download variants.

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 destructiveHint=false and openWorldHint=true, and the description adds genuinely new behavioral detail: without savePath the content comes back as base64 suited to small files, while savePath writes to local disk (which explains the readOnlyHint=false despite being a 'download'). It doesn't cover error behavior for invalid IDs 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?

Required/optional split and front-loaded first sentence make it easy to scan, and the examples are illustrative. It is slightly longer than needed since the three examples largely restate the savePath semantics already described in prose.

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 correctly compensates by explaining the two return modes (saved file vs. base64) and their size implications. Combined with the prerequisite lookup tip, 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 100%, so the baseline is 3, but the description goes beyond the schema by clarifying that savePath accepts either a directory (filename auto-detected) or a full file path, and by disclosing the implicit third behavior — base64 return when savePath is omitted — which the schema never 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?

States a specific verb and resource: 'Download a file from a Dooray drive,' which distinguishes it from download-attachment, download-wiki-page-file, and download-wiki-attach-file by the drive resource. It does not explicitly name those siblings, so the differentiation is implicit rather than spelled out.

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 operating context: required IDs, optional savePath, and a concrete routing tip — 'If you only have a file ID, use get-drive-file-meta first to get the driveId' — which points to the prerequisite sibling tool. It lacks explicit when-not-to-use guidance versus the other download tools, keeping it at 4.

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=false, destructiveHint=false, openWorldHint=true, and the description is consistent: it explains that the tool writes to a local savePath when provided, which accounts for the non-read-only hint. It adds useful behavior detail beyond the annotations (auto-detected filename, base64 fallback), though it says nothing about auth or size limits.

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 first sentence carries the core purpose, and the section headers plus examples are scannable. The 'Note' at the end partially restates the attachFileId/fileId point already made up top, which is minor 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?

With no output schema, the description covers the return shape implicitly through the base64 example when savePath is omitted, which is the one return detail an agent needs. Remaining gaps (error behavior on bad IDs, binary vs. text response) are modest for a three-parameter download tool.

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

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

Schema coverage is 100%, so baseline is 3; the description earns above that by documenting where attachFileId originates (the exact JSON paths in the page-detail response) and by explaining savePath's dual semantics (directory with auto-detected filename vs. full file path).

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 ('Download a file from a Dooray wiki using attach file ID') and calls out the key disambiguation between attachFileId and fileId. It does not, however, differentiate itself from the nearby sibling download-wiki-page-file, which is the most likely confusion point.

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 precondition for use ('use this endpoint when you have an attachFileId from the page detail API's $.result.files.attachFileId'), plus a clear rule of thumb: savePath for large files, base64 for small ones. It lacks an explicit alternative branch for when only a fileId is available, but the guidance is otherwise 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 mark this as non-read-only and open-world; the description fills in the missing behavior — that it writes a file to a local path and returns savedTo, or falls back to base64Data when savePath is omitted. That dual-mode behavior is the key thing an agent needs and is not in the annotations. It omits auth requirements and whether an existing file at savePath is overwritten.

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 one-line purpose, then required/optional params, two concrete examples, and response fields — a natural agent-reading order. It runs long, and the response-field list partially duplicates what the examples imply, but nothing is wasted given there is no output schema.

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

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

With no output schema, the explicit Response Fields list is genuinely necessary and well supplied; param sourcing and the savePath/base64 branch are both covered. The remaining gap is contextual routing against the sibling wiki/drive download tools, which a caller must resolve on its own.

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 100%, so the baseline is 3, but the description adds value beyond the schema: it documents the exact JSON paths to obtain fileId from the page detail API and clarifies that savePath can be either a directory (filename auto-detected) or a full file path.

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 ('Download a file attached to a Dooray wiki page') that an agent can act on immediately. It does not, however, distinguish itself from the sibling download-wiki-attach-file (or download-attachment / download-drive-file), so an agent cannot tell from the text which downloader applies to which context.

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 real guidance on when to use savePath (large files) vs. omitting it (base64, small files), and tells the agent where fileId comes from ($.result.files.id / $.result.images.id). But it never states when to prefer this tool over the near-identical sibling download-wiki-attach-file, which is the main ambiguity facing a caller.

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 and open-world, so safety is covered; the description adds real value by disclosing the filter (only 'general' type files come back) and by enumerating the response shape. It does not mention permission requirements or ordering/pagination, which keeps it from a 5.

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?

Purpose is front-loaded and the note about file types is well placed, but the required-parameters block restates the schema verbatim and the JSON example duplicates the same two fields, adding length without information. The return-fields list is long yet arguably justified since no output schema exists.

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 thoroughly (totalCount, data[] with id, name, size, mimeType, createdAt, creator). For a simple two-param read tool this is close to complete; only error/empty behaviors and whether all files are returned in one page are unstated.

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 both required parameters are already documented in the schema with identical wording and identical semantics; the description merely repeats them plus a redundant example. No additional meaning (formats, where to find the IDs) is contributed, 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 list of file attachments for a Dooray task') and scopes it to 'general' type files, which separates it from download-all-attachments and get-attachment-metadata in spirit. It never names a sibling to route against, so it stops short of a 5.

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, and no mention of the alternatives in the sibling set (get-attachment-metadata, download-attachment, download-all-attachments). The 'general type only' note is a scoping caveat, not routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is known. The description adds genuinely non-schema context: the return is metadata only, timestamps are ISO-8601, and the creator shape is described. It does not discuss failure modes (e.g., missing file/task) or permissions, which keeps it from a 5.

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 purpose and required parameters, but the 'Returns' line and the 'Response Fields' list largely duplicate each other, and the example JSON adds little beyond the schema's required-field list. Useful, but roughly a third of the text does not earn 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?

There is no output schema, so the description carries the burden of describing return values, and it does so item by item (id, name, size, mimeType, createdAt, creator). Combined with the input sourcing hints, an agent has everything needed to call it 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%, so baseline is 3, but the description earns extra credit by clarifying that taskId is a post ID and that fileId must be sourced from get-attachment-list, which the schema alone does not convey. The example payload also demonstrates the three required IDs in context.

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 metadata of a specific file attachment) scoped to a Dooray task. It explicitly distinguishes itself from siblings by noting it returns metadata only and pointing to download-attachment for content, so an agent can differentiate it from get-attachment-list 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?

The description tells you where to get fileId (get-attachment-list) and names the explicit alternative for retrieving file content (download-attachment), including the condition that separates the two. Both when-to-use and when-not-to-use are covered.

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/openWorld, so the safety profile is covered; the description adds genuine behavioral context by enumerating what the response contains (body, organizer/attendee mapping, per-attendee status values, recurrenceRule, files). Since no output schema exists, this return-shape disclosure carries real weight; it stops short of 5 for omitting auth or pagination notes.

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 purpose and the required-parameter constraint, then routing, then a minimal example, then return contents. Every element is short and earns its place; the inline example is small enough to justify itself as a format cue.

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 two-required-param read-only getter with no output schema, the description covers ID provenance and the returned fields, which is what an agent needs to call it and interpret results. The only gap is nothing about error behavior for invalid IDs, which is minor.

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 both params are required, so baseline would be 3. The description adds meaning beyond the bare 'Event ID'/'Calendar ID' schema text by specifying that the values come from get-calendar-event-list's calendar.id and id fields, and the example shows the concrete wire shape.

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 details of a Dooray calendar event') and immediately distinguishes it from the sibling get-calendar-event-list by pointing there as the source of the IDs. An agent can tell single-event retrieval apart from listing 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?

Explicitly says both calendarId and eventId are required and where to obtain them ('Take them from get-calendar-event-list (calendar.id and id)'), which is real routing guidance. It lacks explicit when-not-to-use language, but the list-vs-detail split is effectively established.

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/openWorld, so safety is covered. The description adds real behavioral context beyond that: the list excludes event bodies and attendees, and subscription calendars are not included — non-obvious exclusions an agent would otherwise miss.

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 required parameters and the range constraint, then filters, then examples. The bullet structure and inline examples each carry distinct information without 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?

No output schema exists, and the description compensates by listing the returned event fields (id, calendar, subject, startedAt, endedAt, wholeDayFlag, location, category, recurrenceType), so an agent knows the shape of the result and the exclusions.

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 baseline is 3, but the description adds meaning beyond the schema: it glosses the postType enum values in human terms (toMe = I am an attendee, etc.), explains the category enum (general/post/milestone), and clarifies calendars defaults to all.

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 Dooray calendar events (일정 목록) in a time range') and distinguishes itself from the sibling get-calendar-event by noting the list omits body and attendees and pointing to that tool for details.

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 required parameters (timeMin inclusive, timeMax exclusive), the 1-year range constraint, and the exact alternative to use for full event details. Filter semantics and two worked examples remove any ambiguity about how to invoke it.

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 (readOnlyHint, idempotentHint, openWorldHint), so the description's burden is lower, and it does add value: subscription-calendar exclusion, the meaning of default=true, and the fields returned. It doesn't mention ordering, pagination behavior beyond the examples, or any auth/permission requirements, keeping it short of a 5.

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 purpose and scope, then downstream usage, then two concrete examples and a one-line return summary. Every line carries information an agent would otherwise have to infer.

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

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

For a zero-required-parameter read tool with no output schema, the definition covers what is returned (totalCount plus id, name, type, default, role), what is excluded, and how the output feeds sibling tools. Nothing essential is missing.

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

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

Schema coverage is 100%, so page and size are already documented; the description adds the default page size implicitly through the '{} (first 20 calendars)' example and shows a realistic size=100 call. It still says nothing about what 'page' does in combination with size, so the added meaning is useful but partial.

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 Dooray calendars') and immediately bounds the scope: only calendars the user can access, and subscription calendars are excluded. That scope statement, plus the note that default=true marks the user's own calendar, lets an agent distinguish this from get-calendar-event-list 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?

Explicitly routes downstream use: 'Use the returned calendar id for create-calendar-event, or to filter get-calendar-event-list,' naming both siblings and the condition that selects them. It also states what is NOT returned (subscription calendars), which is a real exclusion rather than implied guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful context by summarizing the returned file/folder fields and illustrating pagination and root-folder behavior.

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

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

The description is front-loaded with purpose, then required/optional parameters, examples, and return values. It is compact and every section contributes to correct invocation.

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 read-only list tool with no output schema, the description is complete enough: it covers required inputs, common call patterns, pagination, type filtering, and the main fields returned. No critical caller information 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 all six parameters are already documented in the schema. The description provides examples that clarify parentId and pagination, but these largely duplicate schema information and it omits any mention of subTypes.

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

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

The description states a clear verb and resource: listing files and folders in a Dooray drive. It does not explicitly distinguish this tool from siblings such as get-drive-file-meta or get-drive-list, so an agent must infer the difference.

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 useful required/optional parameter guidance and concrete examples for top-level, subfolder, type-filtered, and paginated calls. However, it does not state when to use this tool rather than sibling tools, or when not to use it.

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, and openWorld, so the safety profile is covered. The description adds value by enumerating the returned fields (driveId, version, creator, parent info) and explaining why driveId matters, though it does not discuss permissions or error behavior.

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

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

Three short, front-loaded blocks (purpose, required param, returns, note) with bold labels and zero filler. Every line conveys actionable 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?

There is no output schema, and the description compensates by listing the return fields and explaining the driveId hand-off for follow-up calls. Input, output, and next-step usage are all covered for this simple single-param 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?

Only one parameter exists and schema description coverage is 100%, so the schema already fully documents 'fileId'. The description merely restates that fileId is required without adding format or sourcing details, which is the baseline case.

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 file metadata by file ID') and adds a differentiating scope note ('without needing drive ID'), which separates it from drive-scoped siblings like get-drive-file-list and download-drive-file.

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 'Note' tells the agent what to do next with the returned driveId for download or other drive-scoped operations, giving clear procedural context. It does not explicitly name when to prefer a sibling (e.g., get-attachment-metadata) or state exclusions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety and repeatability are covered. The description adds useful context by naming the returned fields (drive ID, name, type, project info), which substitutes for the absent output schema, but says nothing about ordering, limits, or result size.

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 purpose, then organized under two short bold headers. The examples are somewhat repetitive with the enum descriptions in the schema, but each line is short and the structure makes scanning easy.

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 listing the returned fields, and annotations cover the read-only/idempotent profile. Remaining gaps are pagination and ordering behavior, which an agent listing drives might reasonably want.

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 value by showing how 'type' and 'scope' combine in practice and by stating that 'private' is the default drive type. The conditional pairing of scope with type=project is reinforced with worked examples rather than only the schema's parenthetical note.

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 list of accessible Dooray drives') and scopes it to drives rather than files, which distinguishes it from the many drive-file siblings. It does not explicitly name an alternative tool, but the resource boundary 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?

The Drive Types section plus three concrete request examples give clear context for when to use each mode (personal vs. private project vs. public project). It stops short of stating when not to use this tool or which sibling to pick instead.

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 this as read-only, idempotent, and open-world, so the safety profile is covered. The description adds useful behavioral context by listing returned fields and indicating valid ID sources, though it does not discuss permissions or failure behavior.

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

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

The description is front-loaded with the core purpose, then usage guidance, an example, and return fields. Every section is useful and compact, with no redundant restatement.

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 one-parameter read tool with annotations covering safety and no output schema, the description supplies the missing pieces: where the ID comes from and what fields are returned. An agent has enough information to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics by explaining that memberId is an organizationMemberId obtained from assignees, comment creators, attendees, or get-member-list. This helps the agent supply the correct identifier rather than just any string.

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 a specific verb and resource: getting details of a Dooray organization member. It distinguishes itself indirectly from get-member-list by requiring an existing member ID, but does not explicitly clarify when to use it instead of the sibling get-my-member-info.

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 guidance for where to obtain the required memberId, including task assignees, comment creators, calendar attendees, and get-member-list results. It lacks an explicit when-not condition or direct comparison with get-my-member-info, so it is strong but not complete.

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, openWorldHint, and idempotentHint, covering the safety profile. The description adds valuable behavioral context: it explains that some parameters are exact-match only (e.g., externalEmailAddresses) while others are like-search, and specifies the return fields (totalCount, members with id/name/userCode/externalEmailAddress). It also points to get-member for full details. This goes beyond annotations, though it could mention rate limits or auth.

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 front-loaded with purpose and sibling differentiation, followed by a clear list of search conditions, examples, and return information. Every sentence serves a purpose: no repetition, no fluff. The structure is logical and easy to parse.

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 (a read-only search across organization members), the description covers purpose, usage guidelines, parameter semantics, and return values. Annotations cover safety, and the description fills in the rest. No output schema is present, but the return shape is described. Nothing essential is missing.

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

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

Schema description coverage is 100%, so baseline is 3. However, the description adds examples that show how to combine parameters for common searches (by name, email, user ID), which is helpful beyond the schema. It also clarifies that externalEmailAddresses uses exact match only (though this is already in the schema), adding marginal value. The examples make it a 4.

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

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

The description states a specific verb (Search) and resource (members across the whole Dooray organization), explicitly distinguishes it from sibling tool get-project-member-list, and provides a concrete use case (finding organizationMemberId for someone outside the project). An agent can immediately tell what the tool does and when it applies.

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

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

The description explicitly says 'Unlike get-project-member-list, this is not limited to one project' and gives the exact scenario: 'Use it to find the organizationMemberId of someone outside the project (e.g. to add them as CC by email or member ID).' This clearly routes the agent between this and related 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 readOnly/idempotent/openWorld, so the safety profile is covered; the description adds the non-obvious trait that the response is 'compact' with essential fields only, plus the field list returned. It omits pagination/size limits, which matters for a 'retrieves all milestones' operation.

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

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

Purpose and return shape are front-loaded, and sections are short and scannable. The three examples partially restate the schema's status enum and cost a few lines, so it is slightly longer than strictly necessary.

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 only two simple parameters and no output schema, the description covers purpose, parameter derivation, filter behavior, and return fields. An agent has everything needed to invoke it correctly without opening anything else.

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 parameters are already documented, but the description adds real value with the URL-pattern extraction rule for projectId and worked examples showing the status enum in use. This goes beyond what the schema conveys.

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

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

States a specific verb and resource ('Get list of milestones for a project') and even defines what milestones are for, so the agent knows exactly what it returns. It does not explicitly contrast with sibling list tools like get-task-list or get-tag-list, though the milestone resource is unique among them.

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

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

Gives concrete usage scenarios via examples (all milestones, open only, closed only) and explains how to derive projectId from a Dooray URL, which is genuinely actionable context. It also notes that returned milestone IDs are consumed by create/update-task, but gives no explicit 'do not use this when...' exclusions.

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/openWorld, so safety is covered; the description adds the non-obvious behavioral fact that it derives identity from the auth token rather than input, and enumerates the profile fields returned. Not a 5 because it doesn't say what happens on an invalid/expired token or whether any profile fields can be absent.

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 front-loaded purpose sentence is good, but the member-ID point is made three separate times (intro, the returns bullet, and the closing line), and the examples block adds little for a zero-param tool. It's readable but noticeably padded for what is essentially one fact plus a return-field list.

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?

There is no output schema, no parameters, and simple annotations, yet the description fully compensates by describing the returned profile fields and the auth-derived behavior. An agent has everything needed to call it correctly and reuse the returned ID.

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?

Zero-parameter tool, so the baseline is 4. The description still earns that baseline by explicitly stating 'No parameters needed - it automatically uses your authentication token', preempting an agent from inventing an ID argument.

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 information about the authenticated user') and immediately scopes it to the caller's own profile via API token, which separates it from the sibling get-member / get-member-list tools that target arbitrary members. It also names the key payload (the member ID), so an agent understands the tool's real purpose, not just its surface action.

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 guidance ('This is often the first tool to call to get your member ID for use in other tools like list-tasks') plus concrete example utterances. It stops short of naming the sibling alternatives (get-member, get-member-list) that an agent might otherwise pick, so it lacks the explicit exclusion that would earn a 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 readOnly, idempotent, and openWorld, so the safety profile is covered. The description adds genuinely new behavioral content by enumerating the returned fields (scope, projectType, state, organizationId), which matters because there is no output schema. It stops short of describing failure behavior for an invalid or archived project ID, so a 4 rather than 5.

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 response-field list and the URL guidance both earn their place given the absence of an output schema. However, the two URL examples (with and without task ID) and the separate 'From URL with task' line restate the same extraction rule, and the final 'Use this to get full details...' sentence duplicates the opening.

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

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

For a one-parameter read tool with no output schema, the description supplies both the input-derivation rule and the shape of the return value. Nothing an agent needs in order to call it correctly and interpret the result 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% and the single parameter is documented, but the description goes well beyond it by specifying exactly how to extract projectId from Dooray URLs, including the case with a trailing TASK_ID. That extraction rule is real semantic value the schema cannot express.

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

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

The first line states a specific verb and resource ('Get detailed information about a specific Dooray project'), and the closing line reinforces scope. The explicit contrast with get-project-list ('use this tool directly instead of calling get-project-list') lets an agent separate it from the closest sibling 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?

It explicitly states when to use this tool (a specific project URL or ID is known) and when not to (do not call get-project-list first). The URL examples convert that rule into concrete invocation guidance rather than leaving it 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, openWorld, so safety is covered; the description adds genuinely new behavior: archived projects are excluded, and the response is a compact field set rather than full project detail. Only minor gaps remain, such as default ordering or what happens past the last page.

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 purpose, then scope, then routing rule, then examples — a sensible order. It is somewhat longer than strictly needed for two optional params, with bold markers and a redundant return-shape sentence, but no sentence is pure filler.

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

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

For a two-optional-param read tool with no output schema, the description covers scope, exclusions, response shape, pagination examples, and sibling disambiguation. An agent has everything needed to choose and call 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 100% and both parameters are already documented with defaults and bounds. The examples add real meaning the schema does not: page 1 returning 'second page' confirms zero-based paging, and the empty-object example shows both params are optional.

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 list of active projects') and immediately scopes it to projects the caller belongs to. It is clearly distinguishable from the sibling get-project, which is named as the detail-oriented counterpart.

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 routes between two sibling tools: use get-project when a Dooray URL or PROJECT_ID is present, use this tool for browsing when no specific project is identified. The exclusion rule is stated with a concrete URL example, leaving little 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 and openWorld, so the safety profile is covered. The description adds behavior the annotations cannot: default page size 20, max 100, the totalCount > size paging trigger, and a warning that the response is compact (id and code only) — that last point is genuinely useful because it signals a truncated payload.

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 purpose is front-loaded in the first sentence and the blocks are scannable, but the member-groups explanation and the closing usage sentence restate each other, and the two examples add little for a 3-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 no output schema, the description carries the return-value burden and does so by listing id and code plus totalCount. Pagination, URL parsing and intended use are all covered; only error/no-results behavior is left unstated.

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 baseline is 3, but the description earns extra by explaining how to obtain the projectId from a URL and by pairing pagination parameters with worked examples. It adds extraction and default-value context beyond the schema text.

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 list of member groups in a project') and defines what a member group is, which implicitly separates it from get-project-member-list and get-member. It never names those siblings directly, so the differentiation is inferred rather than explicit.

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 closing line gives a concrete use case ('to find member groups for assigning tasks to groups of members'), and the URL Pattern Recognition block tells the agent how to derive projectId from a Dooray task URL. No explicit when-not-to-use or named alternatives, so short of a 5.

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

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

Annotations already declare readOnly, idempotent and openWorld, so safety is covered; the description adds real behavioral context beyond that — optional role filtering semantics, default page size 20 with a hard max of 100, and a deliberately compact response shape. It doesn't say what happens on invalid projectId or whether members are deduplicated.

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 clearly headed sections for URL recognition, role filtering, pagination and return shape, with examples at the end. Slightly redundant: the 'compact response' note and the 'Returns a paginated response' list restate the same field set twice.

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, yet the description documents the returned fields (id, name, externalEmailAddress) and that the payload is paginated with totalCount. Combined with the paging and filtering guidance, an agent has everything needed to call it 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?

Schema coverage is 100%, so baseline is 3, but the description earns above that by explaining the non-obvious projectId derivation rule from a Dooray task URL and by spelling out role filter combinations and pagination limits in prose. This meaning is not present in the schema's terse parameter descriptions.

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

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

States a specific verb and resource: 'Get list of members in a project with their details', plus an enrichment note (name, email). It never distinguishes itself from the closely-named siblings get-member-list, get-member, get-my-member-info, or get-project-member-group-list, so an agent must infer the project-scoped difference.

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 a concrete use case ('find project members for assigning tasks or understanding team composition') and three worked examples covering the main invocation variants. It stops short of explicit when-not-to-use guidance or naming the sibling to use for org-wide member lookups.

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 read-only and idempotent behavior, the description adds critical context: it returns ALL template fields (not filtered) and that macros are returned as-is (not interpolated). For a read-only detail tool with no output schema, these details help the agent understand the response shape and limitations.

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 front-loaded with the purpose and uses clear headings for behavioral notes, URL handling, and return fields. While it is somewhat verbose (listing every return field and including examples), the structure makes it scannable; minor trimming could improve conciseness.

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 lack of an output schema and the need to understand return fields and macro handling, the description provides comprehensive coverage: it lists all returned fields, explains the rationale for returning all fields, and gives URL guidance. Nothing essential for correct invocation 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% with both parameters documented, so the baseline is 3. The description adds meaningful guidance by explaining how to extract the projectId from a Dooray URL and directing users to `get-project-template-list` for template IDs, which goes beyond the schema's brief parameter descriptions.

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

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

The first sentence states a specific verb ('Get') and resource ('detailed information about a specific project template'), and later explicitly distinguishes it from the list view ('This is a detail view, not a list view'). An agent can identify the tool's scope 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?

The description explicitly says to use this tool 'to get full template details before creating a new task' and names the alternative `get-project-template-list` for obtaining template IDs. This provides clear when-to-use guidance and directs to the correct sibling for a different step.

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/openWorld, so the description focuses on adding value: it discloses the compact response shape (id and templateName only) and the pagination contract including totalCount. This is useful beyond what the annotations convey, though it doesn't mention rate limits or ordering.

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 purpose, then structured sections for URL recognition and pagination. The pagination rules are restated in the closing paragraph and the final sentence about template usefulness is mild filler, but overall it remains scannable.

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, and the description fully describes the return payload (totalCount plus array of id/templateName). For a simple three-parameter read tool, an agent has everything needed to call 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 100%, so the baseline is 3; the description earns an extra point by explaining how to extract projectId from a Dooray URL and by clarifying page/size behavior with worked examples beyond the schema text.

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 list of project task templates', and clarifies it retrieves all templates in a project. It does not explicitly distinguish itself from the singular sibling get-project-template, leaving the list-vs-single choice to inference.

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?

Explains what templates are and gives a clear URL-pattern recipe for deriving projectId, plus concrete pagination guidance. It stops short of naming when to use the sibling get-project-template instead, so no explicit exclusion is provided.

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 readOnly, idempotent, and openWorld, so the safety profile is known. The description adds real context beyond that: the four workflow classes with bilingual labels, the fact that projects may have custom workflows, and the return shape (id, name, order, class). Missing only notes on pagination or error behavior.

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

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

Front-loaded with the core purpose, then the class taxonomy, then actionable URL guidance and return shape. The taxonomy list is long but earns its place because class semantics matter for interpreting results; no filler 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?

There is no output schema, so the description's 'Returns: Array of workflows with id, name, order, and class' is necessary and present. The tool is simple (one parameter), and the description covers purpose, input derivation, and output shape adequately.

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?

With 100% schema coverage the single projectId parameter is documented, giving a baseline of 3. The description goes further by explaining how to extract projectId from a Dooray URL ('/task/PROJECT_ID') and giving a concrete example value, which the schema does not convey.

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 list of workflow statuses for a project') plus the domain meaning of workflows. No sibling tool retrieves workflows, so the agent can select it unambiguously.

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 to use the returned workflow IDs when calling create-task or update-task, naming the alternative tools and the downstream context. The URL pattern section additionally tells the agent how to obtain the required projectId from a Dooray URL.

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 and openWorld, so the safety profile is covered; the description goes further by disclosing the exact return shape and the meaning of tagGroup.mandatory/selectOne, which an agent cannot infer elsewhere since there is no output schema. It omits what happens when the tag or project is not found.

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?

Purpose is front-loaded in the first sentence, then structured into response format, field semantics, example and use cases. The JSON sample and the field list partially duplicate each other, but each block contributes (structure vs. semantic meaning of mandatory/selectOne).

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 read-only two-parameter lookup with no output schema, the description supplies the response shape and interprets the non-obvious group flags, which is what an agent needs to act on the result. Missing only error/not-found behavior and permission prerequisites.

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?

Both parameters are already 100% described in the schema, and the description only adds a bare example ({"projectId": "123", "tagId": "456"}) without explaining ID formats or sourcing (e.g., where tagId comes from, whether the project prefix is needed). Baseline 3 applies since the schema carries the parameter burden.

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 details of a specific tag in a Dooray project"), which clearly separates it from the plural sibling get-tag-list. It never explicitly names get-tag-list as the alternative for listing, so distinguishability is implied by 'specific' rather than stated.

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 Use Cases block gives concrete situations (checking details before assigning to a task, verifying group settings, reading color/group info), which is real guidance beyond restating the purpose. It lacks any when-not-to-use or explicit routing to get-tag-list, so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the bar is lower, and the description still adds real behavior: the mandatory/selectOne semantics of tag groups and the concrete consequence of ignoring them ('will result in a 500 error'). Pagination defaults (100 max) are also disclosed. It stops short of saying whether the list is scoped to the caller's permissions or how it behaves for a project with no tag groups.

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 and well-sectioned under bold headers, so an agent can skim to the mandatory-group rules or pagination notes. It is on the long side, and the JSON response sample plus the CRITICAL block spend more words than strictly necessary, but none of it is 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?

There is no output schema, and the description compensates by showing the exact return envelope (tagGroups with id/name/mandatory/selectOne/tags). Combined with URL derivation, pagination and the write-path warning, everything needed to call this correctly and use the result is present.

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, and the description earns above that by giving the projectId format derivation from a URL pattern and by pairing page/size with a worked second-page example. It does not clarify whether page is 0- or 1-indexed beyond the schema default of 0.

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 opening line states a specific verb and resource ('Get list of tags for a project') plus the organizing structure ('grouped by tag groups'), and the sibling set contains get-tag (singular), so the plural/list distinction is implied by scope. The response-format snippet makes the shape of what is returned 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?

Explicitly routes the agent forward: 'Use tag IDs when creating or updating tasks with create-task or update-task tools,' naming the exact siblings. It also explains when the returned data matters (mandatory groups must be satisfied on writes) and how to derive projectId from a Dooray URL, so both the call and its downstream use are covered.

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, and openWorld, so the safety profile is covered; the description adds substantial behavioral value by detailing the full returned payload (workflow status, dates, body mimeType, hierarchy, people, tags, files). It does not describe failure behavior for an invalid or missing taskId, which keeps it from a 5.

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 and sectioned with headers, but it is long and repetitive: the taskId-required and projectId-optional facts appear three times, and the trailing 'Just taskId' / 'With both IDs' examples duplicate the URL examples already given. Several sentences could be cut without losing 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?

With no output schema, the description carries the burden of describing the return value and does so thoroughly. The remaining gap is error/edge behavior (what happens when the taskId does not exist or the caller lacks access), which is minor for a read-only tool.

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

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

Schema coverage is 100%, but the description adds critical meaning beyond it: taskId is the URL's unique identifier, NOT the sequential task number shown in the UI, and it gives concrete URL-to-parameter extraction rules for both URL formats. This prevents a very likely misuse of passing the visible task number.

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 detailed information about a specific task') and then enumerates exactly what is retrieved. It also distinguishes itself from siblings by name, telling the agent to use get-task-list to find task IDs and to skip get-project-list when a task URL is available.

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 selection condition ('When a specific task URL is provided, use this tool directly instead of calling get-project-list first') and routes the alternative case to get-task-list. It also clarifies that taskId alone is sufficient and projectId is optional, so there is no ambiguity about prerequisites.

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, idempotentHint and openWorldHint, so safety is covered. The description adds value that annotations can't provide: the exact return shape (id, type, subtype, createdAt, creator, body with mimeType/content, files), which matters because no output schema exists. It stops short of stating error behavior, e.g. what happens for an invalid or deleted comment ID.

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 one-sentence purpose, then workflow guidance, then a compact example and a return summary. Every section earns its place, though the bolded 'Examples' and 'Returns' blocks are slightly verbose for a three-parameter read.

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 tool with no output schema, the description supplies the purpose, the source of the ID, the read-before-update workflow, and the return fields. Nothing an agent needs in order 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 description coverage is 100%, so all three IDs are already documented in the schema, and the baseline is 3. The example object shows the three parameters used together, but adds no format or constraint detail beyond what the schema provides.

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: 'Get a single comment on a Dooray task with its full body.' The word 'single' and 'full body' explicitly distinguish it from get-task-comment-list, which is also named in the text.

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 where the comment ID comes from ('from get-task-comment-list') and gives a concrete workflow instruction: 'Call this before update-task-comment to get the current body.' This names the alternative and the precondition that selects it.

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 readOnly/idempotent/openWorld, so the safety profile is free; the description adds real value by disclosing that the response is filtered to essential fields only and by spelling out default page size and the 100-item cap. It omits rate limits, auth requirements, and whether all comments or only visible ones are returned.

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?

Purpose is front-loaded and the sectioned layout is scannable, but the Pagination and Sorting blocks duplicate the schema's enum and default/max values almost verbatim, and the three examples largely repeat the same shape. For a simple paginated list call this is longer than it needs to be.

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 contract itself: totalCount plus id, creator (member vs emailUser shapes), and body with mimeType/content. Combined with pagination, sorting, URL parsing, and required-param emphasis, an agent has everything needed to call 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 100%, so baseline is 3; however the description adds genuine meaning by explaining how to derive projectId and taskId from Dooray URLs and by reinforcing that both are REQUIRED. Pagination and order details merely restate schema descriptions, so it doesn't reach 5.

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 ("Get list of comments (댓글) on a specific Dooray task") with scope ("all comments that have been added to a task"). The plural 'list/all comments' framing plainly separates it from the singular get-task-comment sibling.

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?

Closes with "Use this tool to view discussion history, progress updates, or notes on a task," giving clear situational context. It never states when NOT to use it or points to get-task-comment / create-task-comment as alternatives, so it stops short of explicit routing.

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

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

Annotations already cover safety with readOnlyHint, idempotentHint, and openWorldHint. The description adds useful behavioral context: a compact response with essential fields, pagination, default sort order, and the fact that full details require get-task. It does not discuss auth or rate limits, so it falls short of a 5.

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