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

With no annotations provided, the description carries the full burden and excels by disclosing critical behavioral traits: it warns of potential errors (e.g., 500 error if mandatory tags are not selected), explains default behaviors (priority defaults to 'none'), describes the return format ('Created task with ID and number'), and details workflow constraints like body content requirements. This goes beyond what the input schema alone provides.

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

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

The description is well-structured with sections like workflow, key settings, and examples, but it is overly verbose (over 400 words). While most content is useful, some details (e.g., step-by-step interactive workflow) might be better suited for external documentation, reducing front-loaded clarity. It earns its place but could be more streamlined.

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 (10 parameters, nested objects, no output schema, and no annotations), the description is highly complete. It covers purpose, usage, behavioral details, parameter semantics, and provides examples. It compensates for the lack of annotations and output schema by explaining return values and error conditions, making it sufficient for an agent to use the tool effectively.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds significant value by elaborating on parameter usage: it explains how to derive values (e.g., using sibling tools for assignees/cc, extracting projectId from URLs), provides examples with context, and clarifies critical constraints (e.g., tag selection rules). However, it doesn't cover all parameters equally (e.g., dueDate, milestoneId get less attention), preventing a perfect score.

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

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

The description clearly states the verb 'Create' and the resource 'new task (업무) in a Dooray project', distinguishing it from sibling tools like update-task or get-task-list. It specifies the required fields (projectId and subject), making the purpose specific and actionable.

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

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

The description provides explicit guidance on when and how to use this tool through a detailed 'RECOMMENDED INTERACTIVE WORKFLOW', including step-by-step instructions and references to sibling tools (e.g., get-project-template-list, get-tag-list). It clearly outlines prerequisites and alternatives, such as using templates or handling mandatory tags.

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

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

With no annotations provided, the description carries full burden and delivers substantial behavioral context: it explains the separation from task body editing, provides URL pattern recognition guidance for extracting IDs, details file attachment workflow (upload first then attach), specifies content format options with recommendations, and mentions the return value ('Created comment with ID'). It doesn't cover error conditions or rate limits, but provides comprehensive operational guidance.

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 with clear sections (purpose, use cases, when to use, URL patterns, file attachments, content format, examples, return value). While comprehensive, some sections like the detailed examples could be slightly condensed. Every sentence serves a purpose, but the length approaches the upper bound of appropriate 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?

For a creation tool with no annotations and no output schema, the description provides excellent context: clear purpose, usage guidelines, behavioral details, parameter guidance, and examples. The main gap is the lack of output schema documentation (only mentions 'Created comment with ID' without structure), but given the comprehensive input guidance and sibling tool context, this is largely mitigated.

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. The description adds significant value beyond the schema: it explains how to extract projectId and taskId from URLs, provides detailed file attachment workflow with external reference, gives content format recommendations (markdown preferred), and includes multiple concrete examples showing parameter usage in context. This compensates well for the schema-only documentation.

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

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

The description clearly states the specific action ('creates a comment on a task') and resource ('Dooray task'), distinguishing it from sibling tools like 'update-task' (for modifying task description) and 'update-task-comment' (for editing existing comments). The Korean term '댓글' reinforces the purpose as adding discussion content separate from the main task body.

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?

Explicit 'When to Use' section provides clear alternatives: use this tool for adding comments versus 'update-task' for modifying task description or metadata. It also lists specific use cases (progress updates, responding to questions, logging information, attaching files) that help the agent understand appropriate contexts for invocation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: returns a 'compact response with essential fields only', specifies the return format ('array of milestones with id, name, description, dates, and status'), and provides guidance on how to use the output ('Use milestone IDs when creating or updating tasks'). It doesn't mention rate limits, authentication needs, or pagination, but covers the essential operational behavior well.

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 well-structured with clear sections (purpose, note, URL guidance, examples, return format) and appropriately sized. Most sentences earn their place, though the 'URL Pattern Recognition' section could be slightly more concise. The information is front-loaded with the core purpose stated first.

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 annotations and no output schema, the description provides good completeness: it explains the purpose, provides usage examples, describes the return format and fields, and gives context about how the output relates to other operations. The main gap is the lack of explicit information about authentication requirements or error conditions, but overall it's quite comprehensive for this type of tool.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds minimal value beyond the schema by providing examples of parameter usage in different scenarios (all milestones, open only, closed only), but doesn't explain parameter semantics or constraints that aren't already in the schema descriptions. This meets the baseline expectation when schema coverage is complete.

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

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

The description clearly states the tool's purpose with specific verb ('Get list of') and resource ('milestones for a project'), and distinguishes it from siblings by focusing on milestones rather than tasks, projects, or other entities. It explains what milestones are used for ('organize and track tasks by release or sprint'), which helps differentiate from task-related tools.

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

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

The description provides clear context about when to use this tool (to retrieve milestones for organizing/tracking tasks) and includes URL pattern recognition guidance for extracting projectId from Dooray URLs. However, it doesn't explicitly state when NOT to use this tool or mention specific alternatives among the sibling tools for different needs.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains that the tool uses the API token automatically, requires no parameters, and returns the complete member profile. However, it doesn't mention potential limitations like rate limits or error conditions.

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 well-structured and front-loaded with the core purpose, followed by usage guidance, examples, and return details. Every sentence adds value without redundancy, and the bulleted list efficiently presents return fields without unnecessary elaboration.

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 0-parameter tool with no annotations and no output schema, the description provides excellent context about what the tool does, when to use it, and what it returns. The only minor gap is the lack of explicit output structure documentation, though the bulleted list partially compensates for 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?

The input schema has 0 parameters with 100% coverage, so the baseline would be 3. The description adds significant value by explicitly stating 'No parameters needed - it automatically uses your authentication token' and providing example usage with empty parameters, which helps the agent understand how to invoke it 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 clearly states the specific action ('Get information about the authenticated user') and resource ('Dooray member profile'), distinguishing it from sibling tools like get-task or get-project-list by focusing on the user's own profile rather than project/task data. It explicitly mentions retrieving the member ID for use in other operations.

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

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

The description provides explicit guidance on when to use this tool ('often the first tool to call to get your member ID for use in other tools like list-tasks') and includes practical examples of use cases. It clearly differentiates this from other tools by emphasizing its role in obtaining authentication context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining URL pattern recognition for parameter extraction, providing concrete examples of input handling, and detailing the return structure (listing specific fields like id, code, name, description, scope, etc.). However, it doesn't mention potential error conditions, rate limits, or authentication 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?

The description is well-structured with clear sections (purpose, URL pattern recognition, important usage note, examples, return details, and usage summary). While comprehensive, it maintains focus with each section serving a clear purpose. Some minor trimming could improve conciseness, but overall it's efficiently organized.

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

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

For a single-parameter read operation with no output schema, the description provides excellent context. It explains the tool's purpose, usage guidelines, parameter handling with examples, and detailed return structure. The only gaps are the lack of error handling information and authentication requirements, but given the tool's simplicity and the comprehensive description, it's mostly 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?

The schema description coverage is 100%, so the baseline would be 3. However, the description adds significant value beyond the schema by explaining how to extract the projectId from Dooray URLs with multiple examples, and providing natural language usage patterns ('Show me details of project 123456'). This enhances understanding of parameter semantics beyond the basic schema description.

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

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

The description clearly states the tool's purpose with specific verbs ('retrieves', 'get detailed information') and resources ('Dooray project', 'complete details including configuration, scope, organization, and category information'). It distinguishes itself from sibling tools like 'get-project-list' by focusing on a single project rather than listing multiple projects.

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It states: 'When a specific project URL is provided, use this tool directly instead of calling get-project-list first.' This directly addresses the sibling tool 'get-project-list' and gives clear conditions for tool selection.

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

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

With no annotations provided, the description carries full burden and does well: it discloses that it returns only active projects (filtering behavior), excludes archived projects, returns compact response with essential fields, is paginated, and has default values. It doesn't mention rate limits or auth needs, but covers key behavioral traits adequately for a read 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?

Well-structured with clear sections (purpose, note, important warning, usage context, examples, return format). Some redundancy exists (e.g., 'Get list' and 'retrieves' in first two sentences), but overall it's appropriately sized and front-loaded with critical 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?

For a read-only list tool with 2 fully documented parameters and no output schema, the description is complete: it explains what the tool does, when to use it, behavioral constraints (active-only, compact response), pagination, and distinguishes from alternatives. No significant gaps given the tool's complexity.

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 fully documents both parameters. The description adds minimal value beyond the schema by providing usage examples with parameters, but doesn't explain semantics or constraints beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the verb ('Get list', 'retrieves') and resource ('active projects that you belong to'), specifying the scope (active projects where user is a member, excluding archived). It distinguishes from sibling 'get-project' by noting this is for listing vs. getting 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 states when to use ('for browsing your active projects when no specific project URL or ID is provided') and when not to use (when user provides a specific Dooray URL, use 'get-project' instead). It names the alternative tool and provides clear context for usage decisions.

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

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

With no annotations provided, the description carries full burden and delivers well. It discloses pagination behavior (default page size 20, max 100, page parameter usage), URL pattern recognition for extracting projectId, and response format details (compact response with id and code only). No contradictions exist since annotations are 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?

Well-structured with clear sections (description, URL pattern, pagination, note, examples, returns, usage). While comprehensive, some sections like the detailed examples and returns explanation could be slightly condensed. Every sentence adds value, but it's moderately verbose rather than maximally concise.

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

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

For a read-only list tool with no annotations and no output schema, the description provides excellent completeness. It covers purpose, usage context, behavioral details (pagination, URL parsing, response format), parameter guidance, and examples. The agent has all necessary information to use this tool effectively.

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%, providing solid baseline documentation for all three parameters. The description adds some value with URL pattern recognition guidance for extracting projectId and pagination context, but doesn't significantly enhance parameter meaning beyond what the schema already 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?

The description clearly states the verb 'Get list' and resource 'member groups in a project', with additional context about what member groups are ('collections of members that can be assigned to tasks as a group'). It distinguishes from siblings like 'get-project-member-list' by focusing specifically on groups rather than individual members.

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?

Explicit guidance is provided: 'Use this tool to find member groups for assigning tasks to groups of members.' This gives clear context for when to use this tool versus alternatives like 'get-project-member-list' for individual members or other sibling tools for different resources.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explains pagination behavior (default page size, maximum, how to get additional pages), URL pattern recognition for extracting project IDs, role filtering options and defaults, and the compact response format. The only minor gap is lack of explicit mention about authentication requirements 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 well-structured with clear sections (URL Pattern Recognition, Role Filtering, Pagination, Note, Examples, Returns) and front-loads the core purpose. While comprehensive, some sections could be slightly more concise, but every sentence adds meaningful information that helps the agent understand how to use the tool effectively.

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 tool with 4 parameters, no annotations, and no output schema, the description provides excellent context. It explains the response format in detail, includes multiple usage examples, covers behavioral aspects like pagination and filtering, and gives practical guidance. The only minor gap is the lack of explicit error handling or edge case information, but overall it's highly 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?

Despite 100% schema description coverage, the description adds significant value beyond the schema. It provides concrete examples of parameter usage, explains the URL pattern recognition for obtaining projectId, clarifies role filtering behavior ('If not specified, returns all members regardless of role'), and gives practical guidance on pagination usage. This goes well beyond the basic parameter descriptions in 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 clearly states the tool's purpose with specific verbs ('Get list of members', 'fetches project members and enriches each member') and identifies the resource ('project members'). It distinguishes from siblings like 'get-project' or 'get-project-list' by focusing specifically on members rather than projects themselves.

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

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

The description provides explicit guidance on when to use this tool ('Use this tool to find project members for assigning tasks or understanding team composition') and includes practical examples. It also distinguishes from potential alternatives by specifying the tool's specific scope (members with details) rather than other project-related information.

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

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

With no annotations provided, the description carries full burden and does so effectively. It discloses important behavioral traits: 'returns ALL template fields (not filtered)', explains why ('Template data will be used for creating new tasks'), describes template macro handling ('returned as-is, not interpolated'), and explains URL pattern recognition for parameter extraction. It doesn't mention error conditions or rate limits, but provides substantial behavioral context.

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

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

The description is well-structured with clear sections (purpose, important details, macros, URL patterns, how to get IDs, examples, return fields, usage guidance). While somewhat lengthy, each section adds value. The front-loaded purpose statement is clear, and the information is organized for easy scanning.

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 (retrieving detailed template data for task creation), no annotations, and no output schema, the description provides excellent completeness. It explains the purpose, usage context, behavioral details, parameter guidance, relationship to sibling tools, and comprehensively lists all return fields with explanations of their significance for task creation.

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

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

The input schema has 100% description coverage, so baseline is 3. The description adds significant value beyond the schema by explaining 'URL Pattern Recognition' - how to extract projectId from Dooray URLs, and providing concrete examples of parameter usage. It also clarifies the relationship between parameters and template identification.

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

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

The description clearly states the tool's purpose: 'Get detailed information about a specific project template' and 'retrieves complete template details'. It distinguishes from its sibling 'get-project-template-list' by specifying this is a detail view, not a list view, and explicitly mentions the sibling tool for obtaining template IDs.

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

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

The description provides explicit usage guidance: 'Use this tool to get full template details before creating a new task from the template' and 'Use the `get-project-template-list` tool to list all templates in a project and get their IDs'. It clearly states when to use this tool versus the sibling list tool and connects it to task creation workflows.

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

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

With no annotations provided, the description carries full burden and excels. It discloses key behavioral traits: URL pattern recognition for parameter extraction, compact response format (id and templateName only), detailed pagination behavior (defaults, maximums, usage examples), and the purpose/benefit of templates. This goes well beyond basic functionality.

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 well-structured with clear sections (URL Pattern Recognition, Note, Pagination, Examples) and front-loaded core purpose. While somewhat lengthy, every sentence adds value—no waste. It could be slightly more concise in the final explanatory paragraph.

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 3 parameters with 100% schema coverage but no annotations or output schema, the description provides excellent completeness. It covers purpose, usage context, behavioral details, parameter semantics with examples, and response format. For a read-only list tool, this is comprehensive and leaves no significant gaps.

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. The description adds significant value beyond the schema: it explains how to derive projectId from URLs, provides concrete examples of parameter combinations, and clarifies pagination logic (e.g., 'if totalCount > size'). This enhances understanding but doesn't fully explain all edge cases.

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

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

The description clearly states the verb 'retrieves' and resource 'all available templates in a project', specifying it's about 'project task templates' with 'predefined title and body content'. It distinguishes from siblings like get-project-template (singular) by emphasizing it retrieves a list of all templates, not a specific one.

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

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

The description provides clear context for when to use this tool: to get templates for a project, with URL pattern recognition guidance for extracting projectId. It doesn't explicitly state when not to use it or name alternatives among siblings, but the context is sufficiently clear for typical usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains what the tool returns (array of workflows with specific fields), the structure of workflow classes, and how workflows relate to task operations, though it doesn't mention potential rate limits or authentication 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?

The description is well-structured with clear sections (purpose, workflow classes, usage guidance, URL pattern, examples, return format), front-loads key information, and every sentence contributes meaningfully 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?

Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is complete: it explains purpose, parameter semantics, usage context, return format, and practical examples, leaving no significant gaps for an AI agent to understand 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 description coverage is 100%, so the baseline is 3. The description adds value by explaining how to obtain the projectId parameter through URL pattern recognition with concrete examples, which enhances understanding beyond the schema's basic description.

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

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

The description clearly states the specific action ('Get list of workflow statuses') and resource ('for a project'), distinguishing it from sibling tools like get-project or get-task-list by focusing specifically on workflow statuses rather than general project or task information.

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

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

The description provides explicit guidance on when to use this tool ('Use workflow IDs when creating or updating tasks') and includes practical examples like URL pattern recognition for extracting project IDs from Dooray URLs, which helps differentiate usage from other 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?

With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains the response format with a detailed JSON example, documents critical constraints (mandatory tag groups and 500 error consequences), provides URL pattern recognition guidance for parameter extraction, and details pagination behavior including defaults and maximums. This goes well beyond basic functionality description.

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 well-structured with clear sections (Response Format, CRITICAL, URL Pattern Recognition, Pagination, Examples) that make information easy to find. While longer than minimal, every section adds value: the JSON example clarifies output, critical warnings prevent errors, and examples demonstrate usage. The information is front-loaded with the core purpose first, though some redundancy exists in explaining tag purposes.

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 tool with 3 parameters, no annotations, and no output schema, the description provides exceptional completeness. It covers the tool's purpose, detailed output format, critical constraints for downstream usage, parameter extraction patterns, pagination behavior, and practical examples. The description compensates fully for the lack of structured metadata, making the tool's behavior and integration context completely understandable.

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?

While the schema has 100% description coverage for all 3 parameters, the description adds significant practical context beyond the schema. It explains how to extract projectId from Dooray URLs, provides concrete examples of parameter usage, clarifies that page defaults to 0 (not just 'default: 0'), and emphasizes that size defaults to maximum 100 'to retrieve all tags.' This operational guidance enhances understanding beyond the schema's basic definitions.

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

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

The description clearly states the tool's purpose: 'Get list of tags for a project, grouped by tag groups.' It specifies the verb ('Get'), resource ('tags'), and organizational aspect ('grouped by tag groups'), distinguishing it from sibling tools like get-task-list or get-project-list which handle different resources. The description immediately clarifies what the tool retrieves and how it's structured.

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

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

The description provides explicit guidance on when to use this tool: 'Use tag IDs when creating or updating tasks with create-task or update-task tools.' It also explains the critical relationship between this tool's output and other operations by detailing mandatory tag group requirements for task creation/updates, preventing errors. This creates clear context for when this tool is necessary versus when to use alternatives.

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

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

With no annotations provided, the description carries full burden and does well: it explains URL pattern recognition, clarifies that taskId is the unique identifier (not UI number), states projectId is optional, and details what information is returned. It doesn't mention rate limits, auth needs, or error handling, but provides substantial operational context.

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

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

The description is well-structured with clear sections (purpose, URL patterns, important notes, examples, return details). It's appropriately sized for a tool with complex parameter extraction logic, though some sentences could be tightened (e.g., the examples section is quite detailed).

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 operation with 2 parameters (100% schema coverage) and no output schema, the description is quite complete: it explains purpose, usage guidelines, parameter extraction from URLs, important clarifications, and detailed return structure. The main gap is lack of explicit behavioral notes like rate limits or error cases, but it covers most operational needs.

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. The description adds significant value: it explains two URL formats for extracting parameters, provides concrete examples, clarifies that taskId is required and projectId optional, and warns that taskId is the unique identifier (not UI number). This goes well beyond the schema's basic descriptions.

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

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

The description clearly states the verb 'retrieves' and resource 'complete details of a task', specifying it includes body content, attachments, workflow status, assignees, and metadata. It distinguishes from sibling tools like get-task-list (which searches/lists) and get-project (which gets project 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?

Explicit guidance is provided: 'When a specific task URL is provided, use this tool directly instead of calling get-project-list first' and 'To find taskId from task descriptions, use get-task-list to search and get task IDs.' It clearly differentiates when to use this tool versus alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains URL pattern recognition for extracting IDs, emphasizes that both IDs are REQUIRED, details pagination behavior (default page size, maximum, how to get additional pages), describes sorting options with defaults, and notes the filtered response format. This goes well beyond basic functionality disclosure.

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 well-structured with clear sections (URL Pattern Recognition, IMPORTANT, Pagination, Sorting, Note, Examples, Returns, Use case) and front-loads the core purpose. While comprehensive, some sections could be more concise - for example, the URL pattern explanation is quite detailed. Overall, most sentences earn their place by adding valuable 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?

Given the tool's complexity (5 parameters, pagination, sorting, URL parsing) and the absence of both annotations and output schema, the description provides complete context. It explains behavioral aspects, provides practical examples, documents the return structure in detail, and gives clear usage guidance. This fully compensates for the lack of structured metadata.

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 5 parameters thoroughly. The description adds some value by emphasizing that both projectId and taskId are REQUIRED (though the schema's required array already indicates this) and provides practical examples with all parameters. However, it doesn't add significant meaning beyond what the schema provides, meeting the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose with specific verb ('Get list of comments') and resource ('on a specific Dooray task'), distinguishing it from siblings like 'get-task' (which fetches task details) and 'create-task-comment' (which creates new comments). It explains what comments are ('discussions, updates, or notes added by team members'), providing context beyond just the name.

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

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

The description provides clear context for when to use this tool ('to view discussion history, progress updates, or notes on a task'), but doesn't explicitly mention when NOT to use it or name specific alternatives. While it distinguishes from siblings by function, it lacks explicit guidance like 'use get-task for task details instead of comments'.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool returns a paginated list with compact response fields, explains default sorting (-postUpdatedAt), and details filtering capabilities (member IDs, workflows, dates). It could improve by mentioning rate limits or authentication needs, but covers most operational aspects well.

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 well-structured with clear sections (IMPORTANT, Note, URL Pattern Recognition, filters, examples, sorting) and uses bold for emphasis. While lengthy, every section adds practical value—no wasted sentences. It could be slightly more concise in the examples section, but overall efficiently conveys complex 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?

Given the tool's complexity (18 parameters, no annotations, no output schema), the description is highly complete. It covers purpose, usage guidelines, parameter semantics with examples, and behavioral details like pagination and response format. The main gap is lack of explicit output schema details, but it describes the returned fields adequately for a list tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining parameter semantics in context: it clarifies how to use member ID filters (linking to get-my-member-info), enumerates workflow classes, provides flexible date patterns with examples, and explains sorting options with prefixes. This compensates for the schema's technical descriptions.

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

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

The description clearly states the tool's purpose: 'Get list of tasks in a Dooray project with powerful filtering and sorting.' It specifies the resource (tasks), the scope (Dooray project), and distinguishes it from sibling tools like get-task (for complete details) and get-project (for project info from URLs).

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

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

The description provides explicit guidance on when to use this tool vs alternatives: it directs users to get-task for complete task details, get-project for project info from URLs, and get-my-member-info for organizationMemberId. It also clarifies that projectId is REQUIRED and explains URL pattern recognition for extracting IDs.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains critical behavioral traits: that assignees, cc, and tagIds completely replace existing values (not merged), that unprovided fields remain unchanged, that mandatory tag groups must be included or updates fail with 500 errors, and that Korean terms have specific meanings. It also provides URL pattern recognition guidance and multiple concrete examples of usage.

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 well-structured with clear sections (Recommended Workflow, Important Notes, URL Pattern Recognition, Examples) and uses bold formatting for emphasis. While lengthy, every section serves a clear purpose - the workflow steps are essential guidance, the notes cover critical behaviors, and the examples provide concrete usage patterns. The information is front-loaded with the core purpose first.

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 complexity of this update tool with 11 parameters, nested objects, and no annotations or output schema, the description provides exceptional completeness. It covers the full update workflow, explains behavioral constraints, provides error prevention guidance (mandatory tag groups), includes localization notes (Korean terms), offers URL parsing help, and gives multiple examples. For a mutation tool with this complexity and no structured metadata, the description leaves no significant gaps.

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?

While the input schema has 100% description coverage, the description adds significant semantic value beyond the schema. It explains the complete replacement behavior for assignees, cc, and tagIds (which the schema mentions but the description elaborates), provides workflow context for using other tools to get parameter values, explains Korean terminology, and gives concrete examples showing how parameters work together in practice. The description compensates for the lack of output schema by explaining what gets returned.

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

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

The description clearly states the specific action ('Update an existing task') and resource ('in a Dooray project'), distinguishing it from sibling tools like create-task (for new tasks) and get-task (for reading). The opening sentence provides immediate clarity about the tool's function.

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

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

The description provides explicit guidance on when and how to use this tool versus alternatives, including a detailed 4-step workflow that references sibling tools like get-task, get-my-member-info, get-project-member-list, get-project-member-group-list, get-tag-list, and get-project-workflow-list. It clearly explains prerequisites and dependencies for successful updates.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It reveals critical behavioral traits: the 'IMPORTANT LIMITATION' about email comments, the immediate modification effect ('The comment will be modified immediately'), URL pattern recognition capabilities, authentication requirements (implied through file upload API reference), and the success message return. These go well beyond what the input schema provides.

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

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

The description is well-structured with clear sections (limitation, URL pattern, parameters, workflow, format, examples) and front-loads the core purpose. While comprehensive, some sections like the detailed examples and external link could be slightly condensed. Every sentence adds value, but the length approaches the upper bound of appropriate 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 complexity of a mutation tool with 5 parameters (including nested objects), no annotations, and no output schema, the description provides exceptional completeness. It covers purpose, limitations, prerequisites, parameter semantics, workflow, format details, examples, and return information. The only minor gap is not explicitly stating this is a write operation, but that's strongly implied by 'update' and 'modifies.'

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema: it clarifies that projectId, taskId, and commentId are all 'REQUIRED' (reinforcing schema), explains the optional nature of body vs attachFileIds ('you can provide either... or both'), provides detailed content format guidance with mimeType enum context, and includes concrete examples showing parameter usage. This elevates the score above baseline.

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

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

The description clearly states the specific action ('modifies the content or attachments'), resource ('existing task comment'), and distinguishes it from siblings like 'create-task-comment' (for creating new comments) and 'get-task-comment-list' (for listing comments). The opening sentence directly answers 'what does this tool do?'

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?

Explicit guidance is provided on when to use this tool vs alternatives: 'Use get-task-comment-list to find the comment ID you want to update' (prerequisite), 'Comments created from incoming emails CANNOT be modified' (exclusion), and the workflow section outlines the complete usage sequence. The description clearly distinguishes this from creation and listing operations.

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