gdc-claude-plugin
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Each tool has a clear primary purpose, and potentially overlapping tools like list_my_tasks, list_tasks, and search_tasks are explicitly differentiated in their descriptions. Some pairs (list_my_notifications vs list_my_mentions) are similar but serve distinct use cases.
Naming Consistency3/5Most tool names follow a verb_noun pattern (list_*, get_*, update_*, delete_*), but there are inconsistencies such as 'task_from_doc' (noun-first), 'gdc_login' (prefix + verb), and 'link_task_to_doc' (verb + object + preposition). This breaks a fully predictable naming scheme.
Tool Count2/5With 28 tools, the count exceeds the 'heavy' threshold of 25, making selection more difficult. Although the scope is broad (workspaces, projects, tasks, comments, notifications, docs), several tools are close variants of task listing/filtering and could be consolidated.
Completeness5/5The tool set covers the full task lifecycle (create, read, update, delete, restore, archive), comments (list, add, update, delete), notifications (read-only), and document integration (link, create, sync). No critical operations are missing for the domain.
Average 4.6/5 across 28 of 28 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 54 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the action 'list' and the purpose 'for switching,' but it does not disclose any behavioral traits such as authentication requirements, handling of invalid workspace IDs, whether archived projects are included, or any side effects (including confirming it is read-only). The absence of these details leaves the agent with insufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase of eight words, front-loading the core function and purpose. There is no redundant or filler content; every word contributes. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers the basic function and hints at its purpose. However, it does not explain what '전환용' (switching) means in practice, whether the list includes all projects or only active ones, or any relationship to set_context. While the output schema likely documents the return shape, the description leaves some ambiguity for an agent about the exact context and any special cases. It is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single integer parameter workspace_id with no description (0% schema coverage). The tool description indirectly references '지정 워크스페이스' (specified workspace) which maps to workspace_id, but it does not explain the parameter's meaning, format, or how to obtain a valid workspace ID (e.g., from list_workspaces). The description therefore provides only minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists projects within a specified workspace, using the verb 'list' and resource 'projects.' The parenthetical '(전환용)' adds a distinct purpose (for switching), differentiating it from sibling tools like list_workspaces and list_tasks. This is a specific and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a brief usage hint via '(전환용)' (for switching), implying it should be used to retrieve projects when the user intends to switch context. However, it does not explicitly state when to use it versus alternatives like set_context or list_workspaces, nor does it mention any prerequisites. This is an implied usage scenario rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that no re-authentication is needed and the token is retained, which is useful. However, it does not mention whether prior context is lost, persistence of the new context, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no redundant information. Every word contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is largely complete. It covers action, scope, and the key precondition. A minor gap is that it does not explicitly state that subsequent operations use the new context, but 'switch' implies this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only repeats the property names by saying workspace/project, but does not explain where the IDs come from, any constraints, or the relationship between them beyond the schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: switching the workspace/project of the current repo. It distinguishes itself from sibling tools like gdc_login or get_context by emphasizing context switching without re-authentication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool when already logged in and only changing the working project, which gives clear usage context. It implies not for login/authentication, though it does not name alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone carries the burden of behavioral disclosure. It reveals a non-obvious rule: deletion is restricted to own comments and fails otherwise. This goes beyond what the input schema shows and is critical for the agent to avoid errors. It does not mention other behaviors like permanence, but the ownership rule is the most significant trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the key constraint in bold. Every word earns its place, and there is no redundant information. It is perfectly concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and an output schema (so return values need not be explained), the description covers the essential context: what it does and the critical ownership restriction. It could mention how to obtain the comment_id or what success returns, but those are inferable from siblings and output schema. Overall, it is adequate and not missing major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'comment_id' parameter. The parameter name is self-explanatory (an integer ID), but the description fails to provide any additional meaning or context about where the ID comes from or how it should be used. Since coverage is low, the description should have compensated but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '댓글(멘션)을 삭제한다' (delete a comment/mention). It uses a specific verb and resource, and the sibling tools like add_task_comment and update_task_comment make the distinction clear. The mention of '멘션' adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage constraint: only comments written by the user can be deleted, otherwise an error occurs. This tells the agent when it is appropriate to call the tool, though it does not explicitly name alternatives or when-not-to-use scenarios. Still, the ownership prerequisite is valuable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It transparently notes that it directly executes chrome.exe and falls back to the default browser if Chrome isn't installed, and explains why this is necessary. This adds meaningful context beyond a simple 'open' statement, though it omits error handling or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the primary action and the second provides the rationale. It is concise, front-loaded, and contains no filler, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core purpose and adds contextual rationale about browser behavior. While it does not mention error handling or prerequisites, the presence of an output schema and the straightforward nature of the operation make this reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines task_id as an integer with 0% coverage in the description. The description does not explicitly explain the meaning or format of task_id, relying entirely on the naming convention. Given low schema coverage, the description should have compensated but did not, leaving the parameter's purpose inferred rather than stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Opens the task web screen in a new Chrome tab,' using a specific verb and resource. It distinguishes this tool from sibling tools that manipulate task data (e.g., update_task, delete_task) by focusing on launching the UI rather than modifying data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains why this tool exists—to guarantee opening in Chrome instead of VSCode's built-in browser—which provides clear context for when to use it. However, it does not explicitly name alternative tools or state when not to use this one, making the guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the side effect of writing to document frontmatter (upsert) and that it does not create a task. It also explains the downstream effect on sync_doc_progress. However, it does not mention permissions, reversibility, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences in a compact structure, front-loaded with the core action, followed by mechanism and exclusion. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, side effects, and relationship to sync_doc_progress, and an output schema exists. It does not explicitly state prerequisites like existence of the task/document, but 'existing' implies they must already exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no property descriptions, so the description must compensate. It clarifies that task_id is recorded in frontmatter and that doc_path refers to the target document, but does not detail formats or constraints. The parameter names are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool links an existing task to an existing work request document, explains the mechanism (recording task_id/task_url in frontmatter) and explicitly notes it does not create a new task, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context that after linking, sync_doc_progress/hook will sync progress, implying this tool is a prerequisite. It also explicitly excludes creation of new tasks, but does not name alternative tools or give when-not conditions beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the list is filtered by current user access and implies a read-only operation via the word 'list.' However, it does not elaborate on return format, pagination, or potential errors, though the output schema likely covers the return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short Korean phrase that immediately conveys the tool's purpose and scope. Every word is informative, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, simple listing tool with an output schema, the description is largely sufficient. It provides the core purpose and access scoping, though it is concise to the point of lacking some elaboration on behavioral details, which are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the description correctly adds no parameter information. According to the rubric, 0 parameters earns a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description translates to 'List of workspaces accessible to current user (for switching).' It clearly identifies the tool as a listing operation for workspaces, scoped to the current user's access, and indicates a specific purpose (switching). This distinguishes it from sibling list tools like list_projects and list_customers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '전환용' (for switching) provides clear context that this tool should be used when the user needs to see available workspaces to switch between. It does not explicitly name alternatives or exclusion criteria, but the intended use case is evident, giving clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that a browser window opens, token is shared per user, and workspace/project is repo-specific. This goes beyond a vague 'login' and provides useful behavioral context, though it could mention what happens after authorization (e.g., return to MCP).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight paragraphs, front-loaded with the core purpose, and organized with a line break for the step-by-step instruction. Every sentence contributes meaning: what it does, how to interact, and the persistence semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an authentication tool with no parameters and an output schema present, the description covers the essential aspects: the browser handoff, user-level token sharing, per-repo persistence, and the recommended usage pattern. Minor ambiguity around 'A안' (Option A) is slightly unclear but does not undermine completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% vacuously. The description doesn't need to explain parameters. Per the rubric, a no-parameter tool gets a baseline of 4, and the description correctly focuses on the interaction flow rather than param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: issuing an MCP-only token via browser handoff and saving the selected workspace/project per repository. It distinguishes itself from other sibling tools by focusing on authentication and repo-specific context, rather than task management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage guidance: '레포마다 한 번씩 gdc_login하면' (run gdc_login once per repo) and explains the login flow (Google/local, press 'Allow'). It doesn't explicitly mention alternatives like set_context, but the repo-scoped behavior clearly implies when to use this over a generic context setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses important behavior: returns context applied to the current repo and falls back to a global value in roots-unsupported environments. The return verb implies read-only nature, though explicit permission or error details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact Korean sentences: the first states the primary function, the second adds both a concrete use case and the fallback behavior. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists, the description covers the essential purpose, use case, and fallback scenario. It does not mention possible errors or authentication requirements, but these are less critical for a simple read-only getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. With no parameters to describe, the baseline is 4. The description adds no param-specific detail, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb '반환한다' (returns) and specifies the resource: workspace/project context for the current repo. It clearly distinguishes from sibling tools like set_context (which sets) and list_workspaces (which lists all available workspaces).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description states a clear use case: 'create_task/list 등에서 어떤 프로젝트가 쓰일지 확인하는 용도' (used to check which project will be used in create_task/list). This provides context on when to call the tool. However, it does not explicitly contrast with sibling tools or mention when not to use it, so it stops 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds meaningful behavioral context: statuses include a category (planned/in_progress/done), and done state is defined as category=='done'. This goes beyond a simple 'retrieves enums' statement, though it does not cover auth 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: the first states the core purpose, the second explains the key enum semantics, and the third gives usage timing. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool, the description covers purpose, domain semantics, and usage context. An output schema exists to handle return-value structure, so no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, project_id, is made meaningful by the description's '프로젝트별' (per-project) phrasing. Although schema description coverage is 0%, the single parameter is self-evident from the tool name and description, so the lack of explicit parameter documentation is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '조회한다' (retrieves) with a specific resource: project-specific custom status/priority/task_type enums. This clearly distinguishes it from sibling task-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: before task creation, modification, or filtering to check valid enum values and the 'unfinished set'. It provides clear context but does not mention alternatives 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses important behavioral traits: server-side pagination caps responses at 20 even if limit exceeds 20, the ordering is latest-selected but returned oldest-first, and count represents total comments. It also describes the output fields, including that text is plain HTML-stripped. This is extensive and goes beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every sentence provides necessary information: purpose, pagination cap, sorting behavior, count meaning, and field list. The structure is clear and efficient, with no filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema already covers return types, so the description need not elaborate on that. It adds critical non-obvious context: pagination cap, ordering quirks, count semantics, and HTML stripping. For a simple listing tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description compensates by explaining the limit parameter's meaning (top recent N, but capped at 20). However, task_id's semantics are only implied through the phrase 'task's comments' and not explicitly defined, leaving a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Retrieves the list of comments (mentions) of a task.' It also specifies key behaviors such as sorting and pagination, which distinguishes it from sibling comment manipulation tools (add/update/delete) and other listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as the read-only tool for listing task comments, but it does not explicitly state when to use it instead of alternatives like list_my_mentions or how to decide against other comment-related tools. No exclusions or alternative recommendations are provided, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 so excellently by revealing that filtering is server-side when a project is stored, but client-side with only first-page visibility when not, potentially causing omissions. It also explains filter semantics (not_finished, overdue, undated) which go beyond a simple 'list' operation and disclose the tool's accuracy and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by clear context and a bulleted list of parameter semantics. Every sentence adds value, and the use of bold and bullet points improves readability. It is appropriately sized for the complexity of the tool with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is quite complete: it covers the core function, project context, filtering behavior, fallback scenario, and parameter semantics. An output schema exists, so return values are adequately covered. The only gap is that it does not specify how multiple filters (not_finished, overdue, undated) combine logically (AND vs OR), which could lead to ambiguity. Given the tool's modest complexity, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly explains the meaning of three boolean parameters: not_finished (not done), overdue (past planned end date), and undated (no planned end date). However, the 'limit' parameter is not described in the text; its meaning is only implied by the phrase '첫 페이지만 보므로' (only first page shown). Since the description covers most parameters well but omits limit, a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it retrieves the current user's tasks (assignee/creator/participant). It further distinguishes the scope by fixing the project to the one selected via gdc_login, which separates it from generic list_tasks or search_tasks. The verb '조회한다' and the resource '현재 사용자의 태스크 목록' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need the current user's tasks within the repo-specific project selected by gdc_login. It also describes fallback behavior when no project is saved. However, it does not explicitly name sibling alternatives (e.g., list_tasks or search_tasks) or state when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses assignee resolution (user id or member name, auto-converted to id), project fixation via gdc_login, and filter semantics. It does not describe the return shape, but an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the primary action, followed by short lines with essential operational details. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations and 0% schema coverage, the description covers purpose, the key assignee parameter, filter meanings, project dependency, and sibling differentiation. It omits limit behavior, but the schema provides a default, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial meaning: assignee accepts integer user id or member name (full_name/username) and is auto-interpreted as id. It also explains the boolean filters (not_finished/overdue/undated) with Korean glosses. The limit parameter is self-explanatory with a default, so the gap is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: '특정 담당자의 태스크를 현재 레포 프로젝트에서 조회한다' (retrieves tasks for a specific assignee in the current repo project). It also explicitly contrasts with list_my_tasks, clearly differentiating sibling scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: '내' 태스크는 list_my_tasks를, 특정 담당자는 이 도구를 쓴다 (use list_my_tasks for 'my' tasks, this tool for a specific assignee). It also warns that the project must be set via gdc_login (미설정 시 오류), giving a concrete prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels: it discloses side effects (server re-parses mentions and overwrites), caveats (mentions necessity), and formatting (plaintext→HTML conversion). It also states error conditions (cannot edit others' comments) and duplicate notification avoidance, providing rich insight beyond basic 'update' semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with a clear note (주의) and bullet-like statements. It is dense but appropriately so, covering all critical caveats without wasted words. It is front-loaded with the core purpose and then expands on important behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mention re-parsing, mutation, ownership constraints), the description provides comprehensive context: purpose, preconditions, side effects, parameter semantics, and comparisons to a sibling. Output schema exists, so not explaining return values is fine. It is nearly complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates well. It explains content's auto-conversion behavior and mentions' insertion mechanism, including how it interacts with existing mentions. comment_id is not explicitly described, but its role is implied by the context and default null for mentions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies the body of a comment (mention), using the specific verb '수정한다' (modify). It distinguishes itself from sibling tools by explicitly focusing on editing, not creating/deleting/listening, and includes a constraint about only modifying self-authored comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides strong usage context: only self-written comments can be edited, and it warns about the need to pass mentions to preserve existing mention targets. It references add_task_comment for behavioral consistency, but does not explicitly state when to choose this over alternatives 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses the PATCH mechanism, inline image preservation, mode-specific behaviors (including keep_media handling), and the no-op behavior when the result is unchanged. This is rich, safety-relevant context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than ideal but every sentence adds necessary detail for a complex tool. It is well-structured with clear sections for purpose, usage, and modes, front-loading the key benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters, two distinct modes, and nuanced image preservation behavior, the description is complete. It covers purpose, usage, parameter semantics, and edge cases (no-op), so the agent has sufficient context to invoke the tool correctly. The output schema exists, so return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully. Every parameter is explained: mode with its two values, label default, bullets required for append_work, new_body_html for replace_section, keep_media behavior, and task_id accepting integer or title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'minimally edit the task description' while preserving inline images. It distinguishes from a full overwrite and explains the inline image preservation benefit, which sets it apart from sibling tools like update_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: use in the doc→task sync flow when applying additional work/content changes. It describes when to use each mode (append_work vs replace_section) but does not explicitly name alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: auto-extraction of title from '# ' heading, conversion of description to GDC rich text, status mapping from document metadata, automatic injection of progress=100 and actual end date for done status, and auto-assignment of assignee. It also discloses automatic removal of checklist markers and process meta steps, giving complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though detailed, the description is well-structured with bullet points and clear section headers. Every sentence adds necessary operational detail, and the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input parameters, transformations, default behaviors, and side effects (frontmatter update). An output schema exists, so lack of return-value explanation is acceptable. This is a complete specification for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates substantially for description, status, project, task_type, and assignee behavior. It does not clarify the 'priority' parameter, leaving that one gap, which prevents a perfect 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'create a task from a work request document' and record task_id/task_url in document frontmatter. This distinguishes it from sibling create_task, which lacks the document-writing aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool—when a task must be created from a document with metadata write-back—and references related tools (create_task, get_project_enums) for behavior. However, it stops short of explicit 'use this instead of X' exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It richly discloses that plain text is converted to GDC rich text, mentions are prepended as a highlighted line triggering notifications, mention placement is limited to the beginning, and non-member mentions cause an error listing possible members. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense. Each sentence adds value, and the use of bold for emphasis and bullet-like structure aids scanning. There is no fluff, and the length is appropriate for the complexity of the mention behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (rich text conversion, mention parsing, notifications, error cases) and the presence of an output schema, the description is comprehensive. It covers input requirements, transformation rules, constraints on mention placement, and error behavior, leaving no significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains task_id (implicitly via 'task'), content (plain text vs HTML), and mentions (member names or user IDs, placement, notifications, error handling). This adds significant meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'write a comment (mention) on a task' (태스크에 댓글(멘션)을 작성한다). It identifies the specific resource (task) and differentiates from sibling operations like listing, updating, or deleting comments by using the verb 'add' and explicitly covering mention creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: required fields are listed, content format rules are given, and the mention behavior is explained. It does not explicitly name alternative tools, but it implicitly distinguishes from comment read/update/delete siblings by focusing on creation and mention processing, which is sufficient for an agent to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and excels: it discloses cascading hide to subtasks, automatic unpinning, WBS unsupported, parent-blocked unhide, the confirm gate requiring confirm=True to execute, and idempotent no-op behavior. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
While lengthy, every sentence contributes essential operational detail, and the use of bold headers and paragraphs structures the information effectively. There is no redundancy or fluff, making it as concise as the complexity demands.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all notable behaviors: idempotency, confirmation workflow, side effects on subtasks and pins, project restrictions, and edge cases like parent-blocked unhide. Even with an output schema present, it explains the confirm=False preview workflow, leaving no critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the raw schema by explaining that task_id accepts either an integer ID or a string title resolved via search in the current project, that archived sets the target state, and that confirm controls preview vs. execution. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool hides or unhides a task by setting archived=True or archived=False, and describes itself as an idempotent wrapper around a toggle API. This distinguishes it from sibling tools like delete_task or restore_task, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage context: it mentions that WBS projects do not support hiding, that unhide is blocked if the parent is hidden, and that it works by toggling the archived state. It does not explicitly name alternative tools but effectively communicates when this tool is and isn't applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden and does so richly. It discloses automatic assignee assignment, description HTML conversion, tag synchronization behavior, auto-injection of progress/actual_end_date on completion, and name-to-id resolution, among other behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is well-structured with clear sections, bullet lists, and a template, making it easy to parse. It is front-loaded with the core purpose and required fields, and every section adds necessary value for a complex 16-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for the tool's complexity: all 16 parameters are semantically covered, validation rules are explicit, and the output schema exists so return values need not be described. This provides an agent with sufficient context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates comprehensively. It explains every parameter, including value formats (enum names, YYYY-MM-DD dates, user ids or names), the description template, and special rules for weight, customer, and participant_ids.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '태스크를 생성한다' (creates a task), using a specific verb and resource that clearly distinguishes it from siblings like update_task. It also specifies required fields (project, title) upfront, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool, including a recommended input-collection flow via get_context and get_project_enums, and states validation constraints that should block invocation. It doesn't explicitly mention alternatives like update_task, but the creation-focused purpose and detailed workflow make usage conditions clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully shoulders the transparency burden. It discloses task_id dual-type behavior (integer ID or title string) and title resolution edge cases, sub_tasks exclusion of trash and visibility filters, related_tasks direction preservation, and the single-call/no-round-trip behavior. This is exceptionally rich 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely informative yet organized with a purpose sentence, task_id resolution explanation, and bulleted return-field details. Every sentence contributes value, and the structure aids comprehension despite length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single-parameter but complex output (multiple field groups, parent/subtasks/related tasks, updatable fields, audit fields), the description is remarkably complete. It covers return values, special cases, and integration with update_task, leaving no meaningful gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines task_id as integer or string with no description. The description adds critical semantics: task_id can be an integer ID or a title string, and if a title, it is searched in the current project with exact-match, multiple-candidate, and zero-result behaviors. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core action: '태스크 상세를 조회한다' (retrieve task details), with a specific use case ('작업 요청 문서 생성·연동용'). It distinguishes from sibling list/search tools by emphasizing the detailed single-task nature and including parent, sub_tasks, and related_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use contexts: for work request document creation/linking and for checking current values before/after update_task. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough for an agent to select it over list/search operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that search performs partial matching on name, representative, and manager fields, and that workspaces without permission receive an empty list, interpreting count=0 as either no customers or no viewing permission. This goes beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. Every sentence earns its place: purpose, usage scenario, parameter behavior, and permission edge case. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with one optional parameter and an output schema, the description provides complete context: purpose, usage instructions, parameter semantics, permission implications, and interpretation of the count field. It is self-contained and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'search' with no description, but the description fully explains that providing search performs partial search on name, representative, and manager, while omitting it returns the full list. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the customer list for the current repo context workspace. It also differentiates itself by explicitly mentioning its role as a candidate-checking step before specifying a customer in create_task/update_task, which no sibling tool covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case: 'create_task/update_task의 customer를 이름으로 지정하기 전에 후보를 확인하는 용도' (use to check candidates before specifying the customer in create_task/update_task). It also explains search behavior and how to pass the returned id or name, but it does not explicitly mention alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: it does not mark notifications as read, enforces a limit cap of 99, may include notifications from other workspaces, and includes unread_count. It also suggests follow-up actions using the item URLs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main sentence and bullet points for additional details. It is concise yet informative, with every sentence adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, limitations, and follow-up calls, which is complete for a simple read-only tool with two parameters. The output schema already handles return values, so no further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains both parameters (unread_only and limit) with their effects and the server-side cap on limit. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the user's notification list in read-only mode, with types, ordering, and unread count. It is distinct from sibling tools like list_my_tasks and list_my_mentions by focusing on notifications for the recipient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it (for user's notifications) but does not explicitly name alternatives or state when not to use it. It does mention the lack of workspace/project scope, which helps set expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly discloses auth requirements (admin+), side effects (attachments restored, cascade-deleted subtasks are NOT restored, WBS tasks detached with weight released), and the preview/commit confirmation gate. This goes well beyond basic operational detail and prevents surprising behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Despite its length, every sentence delivers critical operational detail: purpose, permission, input flexibility, side effects, and the confirmation pattern. The use of bold for key terms and a structured flow makes it scannable without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to outline the return format. It covers auth, input resolution, side effects (subtasks, WBS), and the preview/commit destructive pattern. It even describes the preview return content (target and side-effects), making it complete for a risky restore operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides types (integer/string for task_id, boolean default for confirm) with no descriptions. The description completely fills the gap: task_id can be an integer ID or a string title matched in the trash, and confirm controls whether the call is a preview or an actual restoration. This is substantial added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific action: restore ('복구한다') deleted tasks from the trash, which clearly distinguishes it from siblings like delete_task or archive_task. It also adds the permission prerequisite (admin or higher), further clarifying the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: for tasks that are in the trash and excluded from normal search, with task_id accepting either an ID or a title matched against the trash. It also explicitly describes the two-step confirmation flow (confirm=False for preview, confirm=True for actual restore), but does not name alternative tools like list_trashed_tasks or explicitly state 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: the progress formula, phase completion criteria (all sub-checkboxes [x]), auto-transitions to '진행'/'완료' with actual dates, and the optional description PATCH including the label template and HTML conversion. It even states that checkboxes and process meta steps are excluded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately sized for the tool's complexity. It front-loads the core purpose, then each subsequent sentence adds essential details on formula, defaults, transitions, and the description parameter. No sentence is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex sync tool with no annotations and zero schema coverage, the description covers all critical aspects: calculation method, phase completion, task_id resolution, status transitions, description formatting, and exclusion of checkboxes/meta. The existence of an output schema covers return values, so omitting them is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds rich meaning to all parameters: task_id fallback to frontmatter, doc_path as the required document path, and description's role in patching the task body with a precise template and conversion rules. This far exceeds the raw schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb+resource pair: it reads Phase progress from a work request document and synchronizes the linked task's progress rate, status, and actual dates. This clearly differentiates it from siblings like update_task or task_from_doc, which focus on direct task editing or creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to omit task_id (uses document frontmatter) and when to pass description (after document body modification, for regenerating the summary), explicitly contrasting with the automatic hook which is progress-only. However, it does not explicitly name alternative tools or state 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses soft delete/recoverability, permission requirements, polymorphic task_id interpretation, cascading vs promoting subtask behavior, and a two-phase confirm gate. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action. Every sentence adds necessary detail: permissions, task_id semantics, subtask handling, related tools, and the confirm gate. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex delete operation with a polymorphic parameter, subtask edge cases, and a confirmation gate, the description covers all essential behavioral aspects. Given the output schema exists, return values need no explanation. It also integrates with sibling tools via cross-references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates fully: it explains task_id accepts integer or string title (searching current project) and clarifies confirm's default false provides preview without deletion. This goes beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Deletes task' with specific details: soft delete, trash move, recoverable. It distinguishes from siblings like archive_task, restore_task, and list_trashed_tasks by explicitly naming them for recovery and listing, and by explaining the soft delete behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: requires admin permission, explains task_id can be integer ID or title, details WBS vs non-WBS subtask handling, and defines the confirm gate for preview vs actual deletion. Also names restoration and listing tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses read-only nature ('조회 전용'), scope behavior (current workspace/project default, project_id override), date format, search semantics, and preview truncation (server cuts at 100 chars). This goes beyond typical descriptions and covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, a usage-context paragraph, and bullet-point parameter explanations. Every segment adds value: purpose, differentiators, parameter semantics, and preview caveat. No wasted words despite being detailed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and the presence of sibling tools, the description is fully complete for selecting and invoking the tool. It covers purpose, scope, parameter behavior, and output limitations (preview truncation, fallback to list_task_comments). The output schema handles return structure, so no further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It thoroughly explains mention_type (with values 'mentioned'/'authored'/'both'), project_id scope override, date_from/date_to format (YYYY-MM-DD), and search (partial match on comment body). Only 'limit' is not explicitly described but its default and meaning are self-evident, so this is a minor omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of comment mentions related to the user, sorted by latest. It explicitly distinguishes itself from list_my_notifications by noting it scans comment bodies rather than notifications, and also references list_task_comments for full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: '댓글 본문을 훑는 용도다 — 어떤 태스크에서 무슨 이야기가 오갔는지 확인할 때 쓴다' (for scanning comment bodies to see what was discussed). It also contrasts with list_my_notifications and advises using list_task_comments for full content when previews are truncated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden. It discloses admin-only access, project scoping, a max of 100 items per request, ordering by latest deletion, and inclusion of deleted_at/deleted_by fields. It also clarifies the 'count' semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, with three substantive sentences and line breaks that improve readability. Every sentence adds value: purpose, usage context, scope, permissions, and parameter behavior, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description covers all important contextual aspects: what the tool does, when to use it, permission requirements, scoping, pagination/limit behavior, and key response fields. It is self-sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 'limit' with a default and no description (0% coverage). The description compensates by explaining that 'limit' returns the top N items in latest deletion order and that a request can retrieve at most 100, adding meaning well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it retrieves the current project's trash list of deleted tasks, using a specific verb and resource. It clearly distinguishes from sibling tools like list_my_tasks/get_task by noting deleted tasks are excluded from those and that this list is for restore_task targeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: to restore deleted tasks, check id/title in this list because deleted tasks don't appear in normal queries. It references sibling tools (list_my_tasks/get_task, restore_task) to establish context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses critical behavioral traits: server-side reordering by number rather than relevance, the need to check total_matched, the incompatibility of query with root_only, the not_finished default including completed tasks, the 200-item limitation for undated, and precedence rules. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence adds value, organized with clear bullet points per parameter. It is front-loaded with purpose and scope, then dives into parameter details. The structure makes complex information digestible without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, no annotations, and high complexity, the description covers the vast majority of needed context: parameter meanings, limitations, default behaviors, and response shape. The only minor gap is the 'limit' parameter, but its name and default make it self-evident, and the description explicitly mentions increasing limit when needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides detailed semantics for nearly every parameter: query's scope and relevance behavior, status/priority/task_type value sources, assignee/customer accepted formats, date ranges, not_finished/overdue/undated nuances, ordering options, and response fields. Even root_only's behavior is touched through its incompatibility note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('searches tasks'), resource ('tasks in current repo project'), and scope (keyword/filter-based). It distinguishes itself from siblings by explicitly naming list_my_tasks and list_tasks as simpler alternatives for specific cases, which is strong differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it is for keyword or combined filters, while list_my_tasks and list_tasks are simpler for 'my tasks' and 'specific assignee tasks' respectively. It also clarifies when not to use certain parameters (e.g., query and root_only together) and how not_finished default differs from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so thoroughly: it discloses PATCH semantics, full description replacement with HTML conversion, weight auto-reset on parent change, done-status auto-correction, clear_fields conflict errors, and validation constraints (ValueError).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence purpose, then organized into labeled sections (description template, editable fields, clearing fields, constraints). It is long but every sentence adds operational detail, with examples, and no fluff—justified for an 18-param tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with no annotations, this description is remarkably complete: it covers prerequisites, side effects, error behavior, field semantics, and alternatives. The output schema exists, so return values are not required. It leaves no critical operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates extensively: it explains date format (YYYY-MM-DD), enum name requirements, id-or-name resolution for assignee/customer, WBS-only weight, clear_fields usage with examples, and date/member constraints. Almost all 18 parameters are semantically enriched beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '태스크를 부분 수정(PATCH)한다' (partially updates the task with PATCH) and states '전달한 필드만 갱신된다' (only passed fields are updated). This specific verb+resource+semantics clearly distinguishes it from siblings like edit_task_description and create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names edit_task_description as the alternative for partial section edits to avoid inline image loss, and references get_project_enums for enum values and get_task for tag reading. It gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/seonmikii/gdc-claude-plugin'
If you have feedback or need assistance with the MCP directory API, please join our Discord server