nworks

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.3.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Tools are organized by functional area (board, calendar, drive, mail, message, task, etc.) with clear CRUD operations, and even diagnostic/setup tools like nworks_doctor and nworks_whoami serve unique roles. The descriptions explicitly reference related tools for parameter lookup, preventing confusion.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with the 'nworks_' prefix, such as nworks_board_create, nworks_calendar_list, nworks_drive_upload. The naming is uniform across all 26 tools, using snake_case throughout without any deviations or mixed conventions.
Tool Count3/5
With 26 tools, the count feels heavy for a single server, bordering on excessive. While the tools cover multiple domains (board, calendar, drive, mail, messages, tasks, setup, diagnostics), a typical well-scoped server might have 3-15 tools. However, given the broad scope of NAVER WORKS integration, it's not unreasonable, but it approaches the upper limit of manageability.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage across all major domains (board, calendar, drive, mail, tasks), including setup (nworks_setup), authentication (nworks_login_user, nworks_logout), and diagnostics (nworks_doctor, nworks_whoami). There are no obvious gaps; agents can perform full workflows from authentication to data manipulation and cleanup.
Average 4.1/5 across 26 of 26 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 18 commits in the last 12 weeks
- Last stable release on August 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the OAuth requirement (mail.read scope) and the dependency on nworks_mail_list for the ID, which is useful. Beyond that, it says '본문, 첨부파일 등' but doesn't clarify whether attachments are returned as content or just metadata – a meaningful behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The purpose is front-loaded with the verb and object, and the ID sourcing hint is useful. Slight redundancy with the auth note that could have been more compact, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, ID source, and authentication, but omits a few practical details: whether attachments are included as metadata or content, any size/pagination limits, and the explicit boundary with nworks_mail_download_attachment. For a read-only tool, this is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parametersjší. The description adds the cross-reference that mailId comes from nworks_mail_list, which is helpful but not deeply explanatory. It doesn't add format details, so it stays at the baseline for a fully-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '조회' (query) on a specific mail resource and lists the contents (body, attachments). It distinguishes from list and attachment-download siblings by focusing on detailed content. However, it doesn't explicitly name the sibling alternatives, so slightly less crisp than a direct contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a usage scenario ('이 메일 내용 보여줘') and says mailId comes from nworks_mail_list, which helps. But it doesn't warn that attachment content itself is handled by nworks_mail_download_attachment – this could mislead an agent into expecting binary data here. That omission weakens the 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?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds value by disclosing the OAuth scope ('contact') needed for invocation. This complements the annotations, but the description itself doesn't clarify idempotency behavior or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, efficient sentences clearly prioritized—stating the action first and important lookup context and auth requirement after. No fluff, yet includes essential information in a scannable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive operation with strong annotations, this tool is nearly complete: the annotation set and the description together cover actions, source data, and security. The only minor gap is the lack of clarity on idempotent behavior (e.g., what happens if the contact is already deleted), which some agents might need to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description in the input schema. The tool description adds the OAuth scope context, and the parameter description restates the source of contactId as nworks_contact_list. There's no added detail on ID format, example values, or behavior in edge cases beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb+resource ('Deletes a contact') and explains how to obtain contactId via nworks_contact_list. The auth scope adds helpful context. It doesn't explicitly name sibling alternatives (e.g., nworks_contact_get or nworks_contact_update) to distinguish when to choose this over them, but the intent is entirely unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives useful context on where to source the contactId and notes the OAuth scope requirement, which is a usage prerequisite. However, it doesn't specify exclusions (e.g., when the user should use a different tool instead) or what happens for non-existent IDs, though the parameter comment reinforces the source.
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?
Annotations already indicate mutation (readOnlyHint=false) and non-idempotency. The description adds meaningful context beyond annotations by specifying the authentication mechanism, required environmental setup, and that the bot sends to users or channels. It does not describe failure modes or rate limits, but the added auth details are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the primary action and then adding prerequisite details. It avoids fluff and includes necessary context (auth requirements) without being overly verbose. Slightly more could be trimmed, but it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key contextual aspects: prerequisite setup, environment variable requirement, and target types. With full schema coverage for inputs and no output schema, the description does not need to explain return values. It might benefit from noting error behavior, but it is sufficiently complete for a sending tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already well-documented in the schema. The description does not add any parameter-specific details beyond what the schema provides; it only gives authentication context. With high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends NAVER WORKS messages via bot, specifying recipients as users or channels. The verb '전송' (send) and resource '메시지' are concrete, and it is implicitly distinct from sibling tools like nworks_message_members, but it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important context about prerequisites (Service Account, nworks_setup, environment variables) and notes that User OAuth is unnecessary. However, it does not explicitly state when to use this tool versus alternatives or include exclusion conditions, so guidance is incomplete.
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?
Annotations already mark the tool as read-only and idempotent; the description adds useful behavioral context by naming the OAuth scope requirement and the shared-drive ID prerequisite. There is no contradiction between the description and the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main purpose, and then moves to shared-drive ID lookup and auth requirements in a clear order. The sharedriveId sentence partly repeats the schema description, which keeps it from being best-in-class, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with 4 well-documented parameters and no output schema, this description gives enough context for an agent to invoke it: the purpose, the required id source, and the auth scope. It does not explain return formatting or pagination behavior, but such details are essentially covered by schema descriptions and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 4 parameters with descriptions (100% coverage), so the description is not required to repeat parameter details. The only parameter-related note, that sharedriveId can be retrieved via nworks_sharedrive_list, duplicates the schema's own text and does not add meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the action as listing the file/folder list of a shared drive ('공유 드라이브의 파일/폴더 목록을 조회합니다'), which conveys a specific verb and resource. It separates itself from shared-drive listing by prefixing 'files/folders', but it does not explicitly disambiguate from siblings such as nworks_sharedrive_download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives valuable prerequisite guidance: sharedriveId can be obtained from nworks_sharedrive_list, and User OAuth with file.read scope is required. However, it does not explicitly describe when to use this tool over alternatives like nworks_sharedrive_download or nworks_sharedrive_list, leaving the choice to inference.
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?
Since annotations already carry readOnlyHint=true and idempotentHint=true, the remaining behavioral risk is auth — and the description addresses precisely this with 'User OAuth 인증 필요 (contact.read scope)', which is exactly the kind of auth-context the rubric credits beyond annotations. It doesn't contradict any annotation. Minor deductions for not noting rate limits or response-shape details, though those are low-stakes for a read-only list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight fragments — operation, trigger example, auth requirement — with zero redundancy, and the most critical information (what the tool retrieves) comes first. Every sentence earns its place; most importantly, the description doesn't hoover up schema-visible facts (docs quote param details for example), which is exactly what good tool definitions should do.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0 required params, a small 3-param optional surface, no output schema, and full schema coverage, the combination of description + annotations covers all the essential calling context an agent needs: what it does, when to use it, what auth it needs, and how to paginate. The only nit is that the per-user vs. system-wide scope of tags is implied rather than stated — the schema's 'me' default implies it, but an explicit statement would make it bulletproof.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — each param (count with default/max, cursor, userId with the 'me' default) is already well-documented in the schema with concise Korean descriptions. The description adds zero parameter-specific semantics beyond the schema, which lands exactly at the baseline of 3 for high schema coverage; there is no deficit and no bonus.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (조회합니다/retrieves) and resource (연락처 태그(그룹) 목록 — contact tag list) and adds a concrete NLU trigger example ('연락처 태그 목록 보여줘'). What holds it back from a 5 is the lack of any explicit disambiguation from the sibling nworks_contact_list / nworks_contact_get tools, relying on the agent to infer 'tags' vs 'contacts' — the names are similar enough that a clarifying clause would help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one clear intent-based trigger ('requests like contact tag list') which gives an agent a pattern to match against user queries. However, it never addresses exclusions or names an alternative tool — notably high-value here because nworks_contact_list and nworks_contact_get are semantically adjacent siblings that an agent could easily fire instead. This is 'implied usage' categorized under the rubric, not the explicit when-to/when-not-to guidance that would earn a 4.
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?
Annotations already declare readOnlyHint and idempotentHint, so the safe read-only nature is covered. The description adds the OAuth task.read requirement, which is useful context, but it doesn't disclose pagination behavior or what the returned task list looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences: purpose, trigger examples, and auth requirement. There is no filler, no repetition, and the core verb and resource are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with fully documented optional parameters and safety annotations, the description supplies the auth precondition and realistic usage scenarios. It doesn't describe the response shape, but nothing critical for selecting and invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are fully described in the schema, including defaults and enum values, so schema coverage is 100%. The description adds no parameter-specific detail, which is acceptable at baseline but not more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (조회/query) and resource (할 일/TODO 목록), and includes example user requests that map directly to the tool. It doesn't explicitly contrast with nworks_task_create/update/delete, but the verb and resource boundary are evident from the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists concrete natural-language triggers such as '할 일 확인해줘' and 'TODO 목록 보여줘', making when-to-use fairly explicit. It also states the required OAuth scope. It doesn't mention when not to use it or when to prefer a sibling, but the intended usage is clear.
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?
Annotations already indicate readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description's mention of OAuth and board.read scope adds value regarding auth requirements. However, it does not elaborate on pagination specifics like cursor format, which is beyond annotations but important for behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action and example queries. It efficiently states auth requirements and boardId resolution in one sentence. Could be slightly more structured, but it is mostly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with full schema coverage and no output schema, the description covers purpose, usage, and auth. It lacks explicit note on cursor pagination, but the schema covers it. Overall sufficient for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters (100% coverage). The description adds minimal extra value, just reiterating boardId is from nworks_board_list. Since schema coverage is full, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists board posts, with specific example queries and a mention of the related boardId lookup. It is distinguished from siblings like nworks_board_read by focusing on list retrieval, and the boardId reference to nworks_board_list 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use it (e.g., '게시판 글 보여줘', '공지사항 확인') and notes boardId can be obtained via nworks_board_list. It lacks explicit 'when not to use' guidance, but the usage context is clear enough for an agent to select it among many list tools.
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?
CDESCRIPTION has readOnlyHint=false and destructiveHint=true, and the description adds the OAuth scope requirement and eventId lookup path. However, it doesn't disclose what exactly gets overwritten (e.g., partial vs. full update semantics), which matters for an update tool flagged as destructive. With annotations covering the safety profile, the description could have elaborated on overwrite behavior, but doesn't — it's adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
세 문장으로 목적, 예시, 인증 요구사항을 각각 요점만 전달한다. 문장마다 가치가 있으며 불필요한 내용이 없다. 예시가 실제 사용자 의도와 정확히 대응되어 의미를 더한다.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
9개의 파라미터와 destructive한 업데이트 특성을 가진 도구임에도, 부분 업데이트(patch)인지 전체 교체(replace)인지, sendNotification 기본값(false)이 의미하는 바가 무엇인지 등 핵심 행동이 명시되지 않았다. 출력 스키마가 없다는 점을 감안하면, 업데이트 의미론에 대한 설명이 조금 더 있으면 좋았을 것이다.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has a Korean description in the schema. The description doesn't add meaning beyond what's in the schema, which is acceptable given high coverage, but it also doesn't clarify interaction between parameters (e.g., start/end relationships, timezone inheritance). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
한 문장으로 명확한 동사(수정)와 대상을 제시하며, '일정 시간 변경해줘' 식의 예시로 의도를 구체화한다. 형제 도구(create/delete/list)와 이름상으로 명확히 구분되며, eventId 조회를 위해 nworks_calendar_list로 연결시킨다.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
도구를 호출할 사용자 발화 예시를 제시해 LLM이 트리거 조건을 명확히 인식할 수 있다. 다만 create/delete와의 명시적 대안 비교나 '~한 경우에는 사용하지 말 것'과 같은 제외 조건은 빠져 있으나, OAuth scope 안내와 eventId 조회 가이드가 실용적 도움을 준다.
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?
The annotations declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds details about what is checked (authentication info, token, private key, API connection) which provides useful context beyond annotations. For a zero-parameter diagnostic tool, this is good disclosure. No contradictions. Score 4 because it adds meaningful context about the checks performed while the annotations already cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose and then lists the specific checks, making it easy to scan. No fluff, perfectly sized for a diagnostic tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with readOnly and idempotent annotations, the description covers the essential scope. However, it doesn't describe what the output will be (e.g., whether it returns a detailed report or just a status). Without an output schema, this is a slight gap, but given the simplicity and the annotations, the description is largely adequate. Score 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema coverage is effectively 100%, but the description takes on the burden of explaining what the tool does with no inputs. The description clearly states the scope of checks (auth, token, private key, API connection). Since there are no parameters, the baseline for trivial parameter semantics is 4, and the description compensates well by explaining the tool's purpose. Score 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: diagnosing NAVER WORKS connection status by checking authentication info, tokens, Private Key, and API connection. It uses a specific verb ('진단합니다' - diagnose) and lists the specific resources checked. It doesn't explicitly distinguish from siblings, but given the siblings are all functional operations (send, list, create), the diagnostic role is evident. Score 4 rather than 5 because it doesn't explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: run diagnostics when connection issues are suspected. However, it does not explicitly state when to use this tool vs alternatives, nor any prerequisites (e.g., must be logged in first). The openWorldHint and idempotentHint annotations suggest it's safe to call anytime, but the description doesn't provide explicit guidance. Score 3 for implied usage without explicit alternatives.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds a critical behavioral detail: User OAuth authentication with board.read scope, which is beyond the annotations. It also clarifies it's a retrieve operation with example use cases. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: purpose, example usage, auth requirement. No filler, front-loaded with the main verb. Excellent information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, it covers purpose, usage context, and authentication. The input schema details parameters (count, cursor). Missing return format details, but given the simplicity and lack of output schema defined, this is acceptable. Could mention pagination explicitly, but schema hints at it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (count: '페이지당 항목 수', cursor: '페이지네이션 커서'). The description does not add any additional semantics about parameters, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'NAVER WORKS 게시판을 조회합니다' (retrieve NAVER WORKS boards). It provides concrete example queries ('게시판 뭐 있어?', '공지사항 게시판 찾아줘') that indicate when to use it. Though it doesn't explicitly contrast with sibling tools like board_posts, the intent is unambiguous given the name and examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes example user queries that trigger this tool, plus an authentication scope note (board.read). It does not explicitly say when NOT to use it or compare to alternatives, but the examples give good guidance on when it applies.
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?
Annotations already declare readOnlyHint and idempotentHint, confirming safe read-only behavior. The description adds the requirement for User OAuth authentication and contact.read scope, which is useful behavioral context not present in the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose, then adds the ID source and authentication requirement. No redundancy or filler; every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter get operation with annotations covering safety traits and no output schema, the description provides enough contextual information: purpose, ID retrieval, and auth requirement. It lacks explicit return value description, but the get semantics imply returning contact details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for contactId already covers the parameter entirely (100% coverage), stating it's the contact ID obtainable from nworks_contact_list. The description repeats this exact information without adding new format, constraints, or examples, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (조회/query) and resource (특정 연락처/specific contact), and explicitly ties the contactId to the nworks_contact_list lookup, distinguishing it from list or create/update/delete siblings. The verb and object 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the source of the contactId (nworks_contact_list) but does not explicitly state when to use this tool versus alternatives like nworks_contact_list for bulk retrieval. Guidance is implied rather than explicit, leaving some inference to the agent.
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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Beyond that, the description discloses a critical prerequisite: 'User OAuth 인증 필요 (file.read scope)'. This adds value by informing the agent about authentication requirements, which is not captured in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences: the first states the core function, the second provides usage triggers and auth requirements. No filler, front-loaded purpose, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with four optional parameters fully described in the schema, the description covers the essential behavioral and usage context. The lack of an output schema is not a major gap for a list-fetching tool, and the auth note completes the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters (count, cursor, userId, folderId) documented in the schema itself. The tool description adds no parameter-specific meaning, so it correctly rests at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('목록을 조회합니다' - retrieves list) and the resource ('NAVER WORKS 드라이브의 파일/폴더'). It provides example user requests that clarify intent. However, it does not explicitly distinguish from sibling tools like nworks_sharedrive_list or nworks_sharedrive_files, though '내 파일 목록' implies the personal drive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete natural-language triggers ('드라이브 파일 보여줘', '내 파일 목록') that tell an agent when to invoke this tool. It lacks explicit exclusions or mention of alternative sibling tools, but the usage context is clear and direct.
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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description only needs to add context. It usefully discloses the User OAuth authentication requirement and mail.read scope, which goes beyond the annotations. It does not describe return shape or sorting/pagination behavior, but the safety profile is already covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant content: the main purpose is front-loaded, followed by concrete usage examples and an authentication note. Every clause contributes something an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description covers purpose, typical user intents, and auth requirements, while the schema covers all parameters. There is no output schema, so a note on return format or pagination behavior would make it more complete, but nothing critical is missing for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters clearly. The description adds a small amount of intent mapping via the example '안 읽은 메일 있어?' for isUnread, but otherwise does not materially enhance the parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of received mail ('받은 메일 목록을 조회합니다') and gives concrete example user requests. It does not explicitly name sibling tools like nworks_mail_read or nworks_mail_send, so it lacks explicit sibling differentiation, but the resource and action are 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear trigger phrases ('메일 확인해줘', '받은편지함 보여줘', '안 읽은 메일 있어?') and mentions required OAuth scope. It does not state when to use alternatives such as nworks_mail_read for individual message content, so there are no exclusions or alternative 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?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=true) and the description does not contradict them — '조회' aligns with read-only semantics. The description adds genuine value beyond annotations by disclosing the User OAuth requirement and the file.read scope, which an agent must know before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: purpose, trigger examples, and auth requirement. The verb and resource are front-loaded, and there is zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter paginated list tool, the package is nearly complete: annotations carry the read-only/idempotent profile, the schema documents both params, and the description adds auth context. Minor gap: with no output schema, the result format is unstated, but for a shared-drive listing this is highly inferable and not a practical blocker.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: count has min/max/default and cursor is documented as a pagination cursor. The description adds no parameter detail beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('조회합니다' / retrieves) and resource ('공유 드라이브 목록' / shared drive list), and reinforces purpose with concrete example queries. It does not explicitly differentiate from the closely related sibling nworks_drive_list, though the tool name itself carries much of that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger conditions with example natural-language requests ('공유 드라이브 뭐 있어?', '팀 공유 드라이브 찾아줘'), which is clear when-to-use context. However, it provides no exclusions or routing to alternatives — it never says when NOT to use this tool or points to nworks_drive_list for personal drives.
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?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds important behavioral details: it requires user OAuth authentication with a specific scope and instructs to use nworks_login_user if not logged in. This informs the agent of prerequisites and potential side effects (none expected, but auth needed).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that immediately state the purpose, provide usage examples, and mention authentication. It is well-structured with the core function first, followed by context. No redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is straightforward and parameters are well-documented, the description does not mention the expected return value or structure (e.g., a list of events, fields included). Since there is no output schema provided, this gap mildly reduces completeness. The authentication guidance is present, but response format is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for all three parameters (userId, fromDateTime, untilDateTime) with formats and examples, covering 100% of parameters. The description does not add any extra semantic meaning beyond what the schema already offers, so a baseline score of 3 applies per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the user's calendar schedule/events, and provides concrete example requests ('오늘 일정 알려줘', '이번 주 스케줄 확인'). This makes the tool's purpose unmistakable and distinct from calendar creation, update, or deletion 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit example use cases for listing schedules and notes the authentication requirement (OAuth, calendar.read scope) with a pointer to the login tool if not authenticated. However, it does not explicitly contrast with create/update/delete tools, though the verb '조회' (retrieve) implies a read-only operation.
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?
While annotations already declare readOnlyHint, openWorldHint, and idempotentHint, the description adds valuable behavioral context: it specifies Service Account authentication and the nworks_setup requirement, and it explains pagination via nextCursor. No contradictions with annotations found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with multiple sentences, each adding value: purpose, use cases, auth requirement, and pagination. It is front-loaded with the primary function and remains concise, without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with simple parameters and no output schema, the description covers the essential aspects: purpose, use cases, auth prerequisite, and pagination behavior. It implies that the response contains userId, which is critical for downstream message sending. While it doesn't enumerate all response fields, the provided context is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of both parameters (count and cursor), including descriptions. The description only reiterates that cursor is used for pagination, which is already in the schema. It adds no new meaning beyond what the schema documents, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does 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 list of NAVER WORKS organization members. It provides concrete example use cases like 'show me the member list', 'find a teammate', and 'find the userId to send a message to', which makes its purpose unmistakable and differentiates it from sibling tools such as nworks_message_send or nworks_contact_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives specific scenarios when the tool is used, such as looking up userId for messaging, and notes the prerequisite of nworks_setup. It does not explicitly list when not to use it or mention alternative tools, but the examples and context provide sufficient guidance for an agent to select it appropriately.
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?
The description reveals critical runtime behavior: asynchronous transmission with an HTTP 202 on success, and the need for User OAuth authentication with a mail scope. These facts go far beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), which say nothing about async behavior or auth rules. This is exactly the kind of extra context that prevents mis-invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a direct purpose statement, example trigger phrases, async behavior/auth scope. Each sentence introduces a distinct, useful fact without redundancy. It is efficiently structured for quick agent scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 100% documented schema and no output schema, the description covers purpose, use triggers, async semantics, and authentication. It omits detail about possible failure responses or output variables, but those are part of schema or dynamic runtime rather than static description needs. The coverage is strong for an invocation decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented (semicolon-separated recipients, body, userId defaulting to me, contentType enum). The description adds no parameter-specific meaning on top of the schema. A baseline score of 3 is appropriate because structured data carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'NAVER WORKS 메일을 전송합니다' — a specific verb (send) and resource (mail). Trigger phrases like '메일 보내줘' make it easy for an agent to match user intent. It does not explicitly contrast with siblings like nworks_message_send, but the Korean term '메일' unambiguously differentiates it from messaging 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage guidance with example requests ('메일 보내줘', '이메일 작성해줘'), helping the agent know when to select this tool. It does not state when not to use it or mention an alternative, but the email-sending context is clear enough for routing. The auth requirement also informs feasibility of use.
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?
Annotations already flag this as a non-read-only, destructive operation. The description additionally discloses an OAuth requirement with the exact scope ('task + user.read'), which is valuable behavioral context not present in the annotations or schema. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: it states the operation, gives usage examples, notes the ID source, and lists the auth requirement. Every clause contributes necessary information, and the primary purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema coverage, annotations, and usage examples, the agent has enough to invoke the tool correctly: what it does, when to use it, how to get taskId, and what auth is required. The only notable omission is return-value behavior after an update, but no output schema exists and the core calling requirements are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds semantic mapping between user intents and parameters, such as '완료 처리' implying status=done and '마감일 변경' implying dueDate. It also reinforces that taskId comes from nworks_task_list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: '할 일을 수정하거나 완료 처리합니다' (modify or complete a task), with concrete example requests. It does not explicitly contrast with sibling tools like nworks_task_create or nworks_task_delete, but the 'update' verb and examples make the intended scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context by mapping natural-language requests ('할 일 완료 처리해줘', '마감일 변경해줘') to this tool and tells the agent where to find taskId (nworks_task_list). It lacks explicit exclusions or alternative routing, 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?
Annotations already carry the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), lowering the bar. The description adds a practically important disclosure — 'User OAuth 인증 필요 (board scope)' — which is real operational context given the login/logout/setup sibling tools. It does not describe the response shape, but the annotation coverage plus the auth note justify a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact clauses with zero waste: the action, the triggering intents, and the prerequisite/auth requirements. The core purpose is front-loaded before auxiliary details, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter create tool with no output schema, the description covers the essential operational needs: core purpose, example intents, how to resolve boardId, and the auth requirement, while annotations cover the safety profile. The only meaningful gap is the unspecified return value (e.g., whether the created post's ID is returned), which matters precisely because no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies: all five parameters (body, title, boardId, enableComment, sendNotifications) are already documented with descriptions and defaults in the schema. The description's only parameter-related note — the boardId lookup route — duplicates the schema's own boardId description, so it adds no net semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — '게시판에 글을 작성합니다' ('writes a post on the board') — which unmistakably identifies a create operation and sets it apart from the board-read siblings (nworks_board_list, nworks_board_posts, nworks_board_read). The example user intents ('게시판에 글 올려줘', '공지 작성해줘') further pin down call intent for an agent matching natural-language requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context via example trigger phrases and an explicit prerequisite route: 'boardId는 nworks_board_list로 조회 가능' directs the agent to nworks_board_list when an ID is missing. It stops short of a 5 because it never explicitly says when not to use this tool versus the board read/list siblings.
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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description doesn't need to repeat that it's a read-only operation. The description adds value by noting the OAuth requirement and the board.read scope, which is additional context beyond annotations. It also mentions a subtle dependencies (posts and boards exist via specific tools). The only gap is not describing the return format or error behavior, but the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste. The purpose is front-loaded, the parameter source is stated, and the auth requirement is mentioned. Every sentence adds value; there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and auth requirements. Though there is no output schema, for a simple read operation with a clear purpose, the description is sufficiently complete. The only minor gap is lack of explicit mention of what happens if the post doesn't exist, but that's an error-handling detail not essential for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description does repeat the postId dependency on nworks_board_posts, which adds a slight contextual hint beyond the schema. All parameters are already clear from the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('조회'), resource ('게시판 글의 상세 내용'), and identifies relation to related tools (postId via nworks_board_posts). The description unambiguously differentiates it from siblings like nworks_board_list (list of boards) and nworks_board_posts (list of posts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states the required parameters (postId, boardId) and references the sibling tools that provide these IDs, which gives the agent context on how to obtain inputs. It doesn't explicitly contrast with alternatives, but the relation to reference-gathering tools is a form of usage guidance. It could be improved by noting when to use this vs. other board tools, though the reference to nworks_board_posts is helpful.
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?
The description explicitly states that User OAuth authentication is required and specifies the scopes (calendar + calendar.read), which is critical behavioral context beyond the annotations. Annotations indicate readOnlyHint=false (mutation) and destructiveHint=false, and the description's 'create' aligns with readOnlyHint=false. It also mentions '새로' (new) suggesting idempotency is not implied, matching idempotentHint=false. However, it does not detail what happens on success or failure, or whether attendees are notified by default, which is covered partially by the parameter default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the core function with trigger examples, and the second states the authentication requirement. It is front-loaded with the primary purpose and includes only essential usage context, no filler. Every word contributes to agent decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters including attendees, location, timezone) and the absence of an output schema, the description provides the essential trigger and auth context. The schema already covers all parameter descriptions, so the description does not need to elaborate on parameters. It could benefit from noting that userId defaults to 'me' or that sendNotification may cause side effects, but these are already in the schema. Overall, it is sufficient for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so each parameter is already described in the schema. The tool description adds no new parameter information beyond what the schema provides, such as format or defaults. Thus, baseline of 3 is appropriate because the schema carries the semantic load, and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('만듭니다') and resource ('캘린더 일정'), and gives example user requests that trigger it. It is distinct from siblings like nworks_calendar_update and nworks_calendar_delete, which are clearly for different actions, and from nworks_task_create which creates a different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear trigger phrases ('회의 잡아줘', '일정 등록해줘') and the required authentication scope, giving the agent a strong sense of when to use it. It does not explicitly state when not to use it or mention alternatives (like nworks_calendar_update for modifications), but the context is sufficient for typical routing.
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?
Annotations already declare destructiveHint=true and idempotentHint=true, so the destructive nature is covered. The description adds useful behavioral context beyond annotations by specifying the required OAuth scopes (calendar + calendar.read) and the retrieval method for eventId. This complements the structured data without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, with each sentence serving a clear purpose: stating the action, providing a usage trigger, and detailing OAuth and eventId lookup. It is front-loaded with the core purpose and has no unnecessary words, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with three parameters (one required) and no output schema, the description covers the essential context: purpose, usage trigger, authentication, and eventId acquisition. It does not describe the effect of sendNotification or error behavior, but given the simplicity and annotation coverage, the description is adequately complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (userId, eventId, sendNotification) are already documented in the input schema. The description only reinforces the eventId lookup tip, which also appears in the schema, so it adds minimal semantic value beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes calendar events ('캘린더 일정을 삭제합니다') and provides a concrete usage example ('일정 취소해줘'). This makes the purpose unambiguous and distinguishes it from sibling tools like nworks_calendar_create or nworks_calendar_update, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use guidance by citing the trigger phrase '일정 취소해줘' and explicitly mentions that eventId can be obtained via nworks_calendar_list, which helps the agent call it correctly. It does not explicitly state when not to use it (e.g., for rescheduling use update), but the context is sufficient for a simple delete operation.
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?
The description discloses the authentication requirement and scope (contact.read), adding detail beyond the readOnlyHint annotation. It does not describe return format or pagination behavior, but the parameters hint at pagination. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence that states the purpose, gives example requests, and notes authentication. It is well-structured and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not need to explain return values. However, it does not mention pagination or filtering capabilities, though parameters like count and cursor imply them. Overall, it is adequate for basic usage, but could explicitly mention pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides thorough descriptions for all parameters (count, email, cursor, etc.), covering 100% of them. The tool description does not add extra meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of NAVER WORKS personal contacts, provides example natural-language requests, and distinguishes itself from other contact tools by focusing on the list operation. The verb '조회합니다' (retrieves) and resource '개인 연락처 목록' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives example user requests ('show contact list', 'check my contacts') and mentions the required OAuth scope, which helps with usage context. However, it does not explicitly contrast with nworks_contact_get or other alternative tools, though the list vs. single distinction is implied.
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?
The annotations already declare readOnlyHint=false and destructiveHint=false, and the description does not contradict them. It adds valuable context beyond annotations: OAuth scope requirement (task + user.read) and default self-assignment. It does not detail response format or side effects, but for a create operation with no output schema, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the action and example requests, the second covers default assignment and auth. Action is front-loaded, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema, the description covers trigger phrases, default behavior, and auth requirements. It does not explicitly state the return value (e.g., created task object or ID), but that is a minor gap for a creation operation where the agent often only needs to confirm success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 6 parameters with descriptions, including inline defaults for userId and assigneeIds. The description restates the self-assignment default but does not add new parameter-level semantics beyond what the schema already provides. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new TODO and gives concrete natural-language trigger phrases ('할 일 추가해줘', 'TODO 등록해줘'). It also clarifies the default self-assignment, distinguishing it from sibling update/delete operations by explicitly naming the 'create' action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage triggers and the default assignment context. However, it does not mention alternatives like nworks_task_update for modifying existing tasks, leaving the agent to infer when not to use this tool. A brief 'use task_update to modify' would elevate it.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, correctly indicating a non-read write operation. The description adds critical behavioral details: the payload must conform to the NAVER WORKS API spec, that permission.accessibleMembers requires at least one member (usually oneself), and that User OAuth with contact scope is required. This supplements the annotations well, though it doesn't explain side effects or whether the tool is idempotent (though the annotation already covers idempotency).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the purpose and example, all in two sentences plus an example JSON. It is dense but not bloated; every piece adds value. The only slight inefficiency is the repeated mention of the mandatory fields in both prose and example, but this is acceptable for emphasis.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has a nested object schema, no output schema, and explicit annotations, the description covers the essential usage: purpose, required auth scope, payload structure, and constraints. It is complete enough for an agent to construct a valid request, though it does not mention possible error cases or how the created contact is returned (since no output schema is provided, the description could have stated that it returns the contact object, but this is a minor gap).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the description goes far beyond the schema: it provides a full example payload with nested objects (contactName, emails, permission) and explicit required fields. Since the schema only describes 'payload' as an object, the description compensates by detailing the internal structure, which is highly valuable for constructing a valid payload. The only minor gap is not spelling out optional field semantics, but the example covers the essentials.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Create contact') in a Korean sentence for requests like 'add contact'. It lists the mandatory fields (contactName, permission) and gives a full JSON example, which unambiguously differentiates it from sibling contact tools like nworks_contact_update/delete/list. The example clarifies the exact structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case ('연락처 추가해줘' requests) and mentions the requirement for User OAuth authentication with contact scope. While it does not explicitly compare against alternatives (e.g., nworks_contact_update for editing), the context is clear enough that an agent can infer when to use this tool, but it lacks an explicit 'when not to use' statement.
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?
The description adds meaningful behavior beyond the annotations: it discloses the required OAuth scope (file.read), the conditional output behavior (save to outputDir vs. return content), the text/base64 distinction, and the 5MB size limit. This is rich, actionable behavioral information. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. The opening sentence states the core purpose, followed by auth requirements, output behavior, and a critical size constraint. Every sentence earns its place with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a download tool with no output schema, the description adequately covers authentication, return behavior, and file-size restrictions. Minor gaps remain, such as the exact result when saving to outputDir and behavior on errors, but the essential invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the outputDir-dependent behavior, the text/base64 return format, and the 5MB constraint. This adds real semantic value for invoking the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: '드라이브 파일을 다운로드합니다' (downloads drive file). It is specific and understandable, but it does not explicitly differentiate from the sibling nworks_sharedrive_download, so the agent must rely on tool naming to distinguish them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool and how its behavior changes based on outputDir. However, it does not mention when NOT to use it or name sibling alternatives, so the guidance is clear but not fully comparative.
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?
Annotations already cover read-only, idempotent, and open-world behavior. The description adds only a minor behavioral detail: it checks token validity. It does not describe unauthenticated behavior or what exactly is returned, but for a safe read-only status check this is not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundant content: the first states the purpose, the second states the recommended invocation context. The core functional information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only diagnostic tool, the description is complete. It tells the agent what account and token state it verifies and when to call it first. No output schema exists, but the stated output concept is sufficient for a whoami-style operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no input ambiguity. The schema already fully addresses parameter semantics because there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (checks) and a clear resource: the currently authenticated NAVER WORKS account and token validity. This distinguishes it from sibling auth-related tools like logout and setup of actual credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call this first when diagnosing authentication issues, which is clear situational guidance. It does not explicitly list when not to use it, but the intent and placement among auth-related siblings make the intended use unambiguous.
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?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds practical context by stating the OAuth requirement and clarifying that payload contains only fields to modify (partial update). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, focused sentences. The first states the primary function, the second explains the payload and authentication. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with no output schema, the description covers the essential operational details: purpose, ID resolution, payload semantics, and auth. It omits explicit handling of the replace parameter or error cases, but those are partially covered by the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful value by explaining that the payload should contain only the fields to modify and that contactId can be resolved via contact_list. It does not detail the replace parameter, but the schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '기존 연락처를 수정합니다' (modifies an existing contact), which clearly states a specific verb and resource. It also references nworks_contact_list for ID lookup, distinguishing it from contact_create and contact_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for existing contacts) and explicitly mentions how to obtain the contactId via nworks_contact_list. It does not explicitly name alternatives or exclusion conditions, but the context is clear.
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?
The description adds behavioral details beyond annotations: it specifies the required User OAuth file scope and the local-only constraint for filePath. It also implies the tool is a write operation (consistent with readOnlyHint=false) but does not disclose side effects like size limits or conflict handling beyond the overwrite parameter (already in schema). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no redundant wording. It front-loads the core purpose and OAuth requirement, then explains the two input methods, and concludes with a practical recommendation. Every sentence earns its place, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description covers the essential invocation details: authentication scope, content delivery options, and parameter composition. It does not explain the return value or error behavior, but for an upload operation that is typically not critical. The schema covers folderId and overwrite defaults, so the description is sufficiently complete for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description enhances parameter semantics by emphasizing the recommended combination (content+fileName) over filePath, and clarifies that filePath is local-only. This adds value beyond the schema's descriptions, which are already detailed but do not convey usage preference or environment constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Uploads file to drive' with a clear verb and resource. It distinguishes from siblings like nworks_drive_list and nworks_drive_download by focusing on the upload action and specifying two content delivery methods. The OAuth scope requirement adds operational context, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance for the two input methods: it recommends content+fileName for MCP clients and notes that filePath works only in local environments. This helps the agent decide which parameters to use. However, it does not explicitly compare this tool to other drive operations (e.g., when to upload vs. list), though the name makes that obvious.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds that it uses Service Account authentication and requires prior setup (nworks_setup), which is behavioral context beyond the annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, and front-loads the core purpose. The usage example and auth note are both valuable and non-redundant. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only one parameter, annotations cover safety (read-only, idempotent), and there is no output schema, the description is adequate. It does not mention the return format or padding details, but for a simple list operation, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter 'channel' is already described as '채널 channelId'. The description does not add further detail about the parameter format or expected values, so baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists members of a specific channel, with a concrete example query. The verb '조회' (query) and resource '채널의 구성원' are specific, and the tool name directly matches the purpose. It is distinguishable from sibling tools like nworks_directory_members, which likely lists directory members, and nworks_message_send, which sends messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a usage example ('이 채널에 누가 있어?' 라는 요청에 사용) and specifies the authentication prerequisite (Service Account 인증 사용, nworks_setup 필요). This tells the agent when to use it and what setup is required, although it does not explicitly mention alternatives, the sibling context makes it clear that nworks_directory_members is the alternative for directory members.
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?
Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true. The description adds crucial context by specifying exactly what is destroyed: stored authentication info and tokens. This goes beyond the annotations' generic 'destructive' flag. The idempotent nature is implied (logout can be called repeatedly), and the description aligns with annotations. No contradiction. A 4 is warranted because it adds behavioral detail without redundancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One succinct sentence that states the action and its consequences with no filler. It is front-loaded with the verb and resource. Perfectly concise for a simple logout operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with annotations covering safety (destructive, idempotent, readOnly) and no output schema, the description is complete. An agent needs only to know what this does and that it deletes stored credentials, both of which are provided. There's no missing information that would impede a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter semantics. The description appropriately refrains from adding parameter info, as there are none. The baseline for zero parameters is 4, and no deduction is needed. The description's focus on the action and its effect on stored state is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool logs out by deleting stored NAVER WORKS authentication info and tokens. The verb 'delete' (삭제) and resource (auth info/tokens) are specific and unambiguous. This distinguishes it from all siblings, especially nworks_login_user and nworks_whoami, which are about authentication state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this should be used when the agent needs to log out of NAVER WORKS, clearing stored credentials. It doesn't explicitly state when not to use it or mention alternatives, but given the tool's unique function (no sibling does logout), the context is clear enough. A 4 is appropriate because there is no ambiguity about its purpose, though explicit conditions could improve it.
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?
Description exceeds annotations by specifying OAuth requirements, output modes (file vs. direct content), and the 5MB limitation. Annotations indicate non-destructive and idempotent, but description adds meaningful behavioral context not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is succinct, front-loaded with the core purpose and key conditions (outputDir, file size limit). Every sentence adds critical information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description provides enough detail on return modes and constraints. The complexity is moderate and fully addressed with parameter semantics and usage guidance. Missing details like empty states or error handling are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions, and the tool description further clarifies the roles of mailId, attachmentId, outputDir, and outputName. Even though coverage is 100%, the description adds value by explaining when to use outputDir for large files and specifying content type handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool downloads mail attachments, identifies required parameters (mailId, attachmentId), and explains the output behavior (file save or direct return). It distinguishes itself from siblings by focusing on attachment download specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions that mailId and attachmentId can be obtained via nworks_mail_read, and that OAuth scope mail.read is needed舋clearly setting the context. It doesn't explicitly state when NOT to use this tool versus alternatives, but the focused purpose and sibling names (e.g., mail_send, mail_read) make the intent clear.
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?
The description discloses that it requires OAuth with task and user.read scope, which is useful behavioral information. It does not mention side effects like permanent deletion or irreversibility, but the destructiveHint annotation already covers that. The idempotentHint is also in annotations. The description adds authentication context, earning a 4 rather than a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. It conveys the essential information without redundancy. Every word adds value, and it is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description does not specify return values, which is acceptable. It covers the action, parameter usage, and authentication. However, it does not mention possible errors or exceptions, which is a minor gap. Overall, it provides sufficient context 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter taskId is described as '삭제할 할 일 ID' (todo ID to delete) and explicitly states it can be retrieved via nworks_task_list. This fully explains the parameter's purpose and how to obtain it, making the schema self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly that it deletes a todo. The description directly says '할 일을 삭제합니다' (deletes a todo), which is unambiguous. It also specifies how to obtain the taskId, making the purpose fully clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the task ID can be retrieved via nworks_task_list, implying a workflow. While it doesn't explicitly contrast with create or update, the action (delete) is self-evident. It also mentions required authentication scopes, which aids usage. Slight gap: no explicit 'use this when' statement, but the intent is clear enough.
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?
Beyond what annotations offer (idempotent, non-destructive mutation), it discloses a hard failure mode — the tool fails without NWORKS_CLIENT_SECRET — plus the NWORKS_PRIVATE_KEY_PATH dependency for Service Account flows and the OAuth redirect URI. It warns that an agent should walk users through prerequisites on failure, turning a simple config call into a predictable, recoverable operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place — prerequisites, tool role, workflow routing, and failure handling are scannable via headers, block bullets, and numbered lists. The one blemish is the OAuth redirect URI appearing as an orphaned final line after the error-handling note, which slightly undercuts the otherwise clean structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool (4 flat params, 1 required, no output schema, no enums, no nested objects), the description is over-complete: it covers prerequisites, environment dependencies, post-conditions, and failure recovery. Nothing an agent needs to invoke it correctly is missing, and the absence of return-value docs is immaterial for a credential-storage tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage with Korean descriptions, setting a baseline of 3, and the prose adds value on top: it reveals clientId is the required anchor, explains Client Secret is deliberately absent as a param for security, and surfaces pairwise semantics like serviceAccount+botId for message features. That relational context isn't in the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Immediately states its purpose: 'NAVER WORKS API 인증 정보를 설정합니다' (configures NAVER WORKS API authentication), then the '이 tool의 역할' section explicitly clarifies it stores clientId plus optional serviceAccount, botId, domainId. This setup-verb-plus-resource purpose distinguishes it cleanly from the 35+ operation-oriented siblings (send, list, create, etc.) without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '설정 후 다음 단계' section explicitly routes the agent conditionally: calendar/mail/drive/task/board features require calling nworks_login_user next, while message/member features require Service Account auth. It lacks an explicit 'do NOT use this when' exclusion, but the workflow context and the failure-remediation note ('실패 시 사용자에게...안내하세요') provide strong, practical invocation guidance.
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?
Beyond the annotations, the description reveals important behavior: authentication requirement with file.read scope, conditional return format (text vs base64), and the 5MB outputDir restriction. No annotation contradicts these, so the description adds significant 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, densely packed with essential operational details. No redundancy or filler. The most important scoping and size constraints are clearly surfaced early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of an output schema, the description explains return value formats, file-saving behavior, and a critical size limit. With full schema documentation for all parameters, an agent has the necessary information to make a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra semantics for outputDir by explaining the save-vs-return decision and the 5MB constraint, which goes beyond the schema's simple property description. It slightly enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (download), resource (shared drive file), and the scope (shared drive, not general drive). The mention of '공유 드라이브' distinguishes it from sibling tools like nworks_drive_download and nworks_sharedrive_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains the two usage modes: with or without outputDir, and places the 5MB constraint on that decision. It does not explicitly name sibling tools as alternatives for this behavior, but the usage context is clear and actionable.
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?
Beyond the minimal annotations (readOnlyHint=false, openWorldHint=true), the description discloses the full side-effect profile: it returns a URL to open externally, tokens are saved automatically, and the choice of preset affects which future tools can be used without re-login. It also warns that a read-only preset will require re-login for mutation tools. This is comprehensive transparency that the annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the primary action, then gives step-by-step behavior and an important parameter warning. No redundancy or filler, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple OAuth login tool, the description covers the return value (URL to open), the automatic token storage, and the implications of preset selection. Since there is no output schema, the description fully explains what the agent needs to know to correctly invoke and handle the result. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already documents both parameters (100% coverage), the description enriches them with practical meaning: it explains that the default preset (=all) covers all API categories, warns against specifying a preset unnecessarily, and clarifies the scope parameter as a raw override for advanced use. This goes well beyond the schema's enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool initiates a user OAuth login for NAVER WORKS, instructs the agent to open the returned URL in a browser, and notes that tokens are automatically saved upon completion. This distinguishes it from siblings like nworks_logout and nworks_setup, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it tells the agent to avoid specifying a preset to get all API scopes, and explains the read-only preset for limited access. It also implies that login is a prerequisite for other tools, though it does not explicitly contrast with alternatives like logout or setup. The guidance on preset selection is clear and actionable.
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:

[![nworks MCP server](https://glama.ai/mcp/servers/yjcho9317/nworks/badges/card.svg)](https://glama.ai/mcp/servers/yjcho9317/nworks)

Score Badge

Copy to your README.md:

[![nworks MCP server](https://glama.ai/mcp/servers/yjcho9317/nworks/badges/score.svg)](https://glama.ai/mcp/servers/yjcho9317/nworks)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/yjcho9317/nworks'

If you have feedback or need assistance with the MCP directory API, please join our Discord server