Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Leave MCP Server Apply for annual leave from June 10 to 12"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
将 Dify 请假流程封装为 Model Context Protocol (MCP) 服务，让 LLM 客户端（Claude Desktop、Trae 等）通过标准 MCP 协议调用工具完成请假申请。
6 个业务流程层工具：覆盖请假全流程（初始化、选岗、计算天数、附件检查、上传、提交）
环境切换：通过 API_ENV 环境变量一键切换 UAT/PRD 环境，所有接口统一域名
业务校验内置：年假/调休假余额校验、丧假 ≤3 天限制、7 类附件要求
附件上传：支持 base64 编码和本地文件路径两种方式
无状态设计：MCP 服务无状态，状态由 LLM 上下文保存，确认后再执行
流程引导 Prompt：内置 leave_flow_guide 提示词，指导 LLM 按序调用工具
Related MCP server: HR Leave Management MCP Server
# 克隆项目后安装（包含开发依赖）
pip install -e ".[dev]"复制 .env.example 为 .env 并按需修改：
copy .env.example .env变量 | 说明 | 默认值 |
| 环境切换： |
|
| UAT 域名 |
|
| PRD 域名 |
|
切换生产环境只需设置 API_ENV=prd，所有接口自动指向 PRD 域名。
mcp dev src/leave_mcp/server.py浏览器打开 Inspector 界面，可手动触发每个工具并查看返回结构。
在 Claude Desktop 配置文件（claude_desktop_config.json）中添加：
{
"mcpServers": {
"leave-service": {
"command": "python",
"args": ["-m", "leave_mcp.server"],
"cwd": "D:\\子公司AI大赛PPT\\003",
"env": {
"PYTHONPATH": "D:\\子公司AI大赛PPT\\003\\src",
"API_ENV": "uat"
}
}
}
}
API_ENV设为uat或prd，不设置默认uat。切换到生产环境改为"prd"即可。
python -m leave_mcp.server# | 工具名 | 功能 | 封装接口 |
1 |
| 初始化流程：获取用户信息、检查未销假、获取请假类型和余额 | 接口 1+4+2+3 |
2 |
| 从岗位列表中选择指定岗位（边界校验） | 无 |
3 |
| 计算实际休假天数 + 年假/调休假余额校验 | 接口 5 |
4 |
| 根据请假类型检查附件要求（7 类规则 + 丧假 ≤3 天） | 无 |
5 |
| 批量上传附件（支持 base64 编码或文件路径） | 接口 7 |
6 |
| 提交请假申请，返回申请单号 | 接口 8 |
leave_flow_guide：请假流程引导，指导 LLM 按 init → select → calculate → check_attachment → (upload) → submit 顺序调用工具。
用户发起请假请求
│
▼
init_leave_flow(user_token)
│
├── has_pending_leave=true → 提示用户先销假，结束
│
▼
select_organization(user_orgs, selected_index) [多岗位时]
│
▼
calculate_leave_days(...)
│
├── balance_sufficient=false → 提示余额不足
│
▼
check_attachment_requirement(leave_type, leave_days, has_attachment)
│
├── action=reject → 提示拒绝原因（如丧假超3天）
├── action=upload → upload_attachment(...) → submit_leave_application(...)
└── action=submit → submit_leave_application(...)请假类型 | 所需附件 |
病假 | 诊断证明或病假条（二选一） |
产假 | 产检证明 |
工伤假 | 工伤情况证明 |
婚假 | 结婚证 |
丧假 | 死亡证明（且时长 ≤ 3 天） |
流产假 | 诊断证明或病假条（二选一） |
年休假 | 无需附件（但需校验余额） |
调休假 | 无需附件（但需校验余额） |
# 运行所有测试
pytest tests/ -v
# 运行特定测试类
pytest tests/test_tools.py::TestCalculateLeaveDays -v测试覆盖：
test_client.py：8 个 REST 接口封装（respx mock httpx）
test_tools.py：6 个工具的正常/异常分支（未销假拦截、余额不足、丧假超限、7 类附件规则、base64 解码）
├── pyproject.toml # 项目配置 + 依赖
├── .env.example # 环境变量示例
├── src/leave_mcp/
│ ├── server.py # FastMCP 实例 + 6 个工具 + prompt
│ ├── config.py # 环境切换配置（API_ENV 控制 uat/prd）
│ ├── models.py # Pydantic 输入输出模型
│ ├── client.py # httpx 异步客户端，8 接口封装
│ ├── exceptions.py # 自定义异常
│ └── prompts.py # 流程引导提示词
└── tests/
├── conftest.py # pytest fixtures
├── test_client.py # 接口封装测试
└── test_tools.py # 工具逻辑测试环境切换：通过 API_ENV 变量控制（uat/prd），所有 8 个接口统一域名，UAT 用 zhgr-mp-uat.huanhuigroup.cn，PRD 用 zhgr-mp.huanhuigroup.cn。
错误分层：业务可恢复结果（余额不足等）返回 {success: false, message} 不中断对话；系统异常抛错。
无状态：MCP 服务不保存会话状态，所需状态（如 selected_org、leave_types）由 LLM 在上下文中保存并作为参数传入。
Token 传参：user_token 通过工具参数传入，不在服务端存储。
Prompts 替代编排：Dify 的 22 节点状态机靠 leave_flow_guide prompt 指导 LLM 按序调用。
附件双模式上传：支持 file_base64（跨客户端通用）和 file_path（本地直读），优先 file_path。
Python ≥ 3.10
MCP Python SDK v1.0+
httpx（异步 HTTP 客户端）
Pydantic v2.0+（数据验证）
计算实际休假天数并校验假期余额。
调用接口 5 计算实际休假天数，然后根据请假类型校验余额：
年休假：校验年假余额是否充足
调休假：校验调休假余额是否充足
其他类型：不校验余额
Args: user_token: 用户认证 Token。 leave_type_code: 请假类型编码（来自 init_leave_flow 的 leave_types）。 start_date: 开始日期，格式 yyyy-MM-dd。 end_date: 结束日期，格式 yyyy-MM-dd。 user_code: 用户编码。 leave_type: 请假类型名称（如 "年休假"、"调休假"），用于余额校验。 avlb_annl_leave: 年假剩余天数（来自 init_leave_flow）。 avlb_ot_leave: 调休假剩余天数（来自 init_leave_flow）。 start_time_code: 开始时间编码，AM 或 PM，默认 AM。 end_time_code: 结束时间编码，AM 或 PM，默认 AM。
Returns: CalcDaysResult: 包含休假天数和余额校验结果。
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | ||
| user_code | Yes | ||
| leave_type | Yes | ||
| start_date | Yes | ||
| user_token | Yes | ||
| avlb_ot_leave | Yes | ||
| end_time_code | No | PM | |
| avlb_annl_leave | Yes | ||
| leave_type_code | Yes | ||
| start_time_code | No | AM |
| Name | Required | Description |
|---|---|---|
| message | Yes | 执行结果描述 |
| success | Yes | 是否执行成功 |
| leave_days | No | 实际休假天数 |
| balance_sufficient | No | 假期余额是否充足（年假/调休假时校验） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes calling an internal API, performing balance checks per leave type, and returning a result. However, it does not disclose potential destructive effects, side effects, or error handling (e.g., insufficient balance).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, front-loading the purpose. It is clear and informative, though slightly verbose with internal API references. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count and lack of schema descriptions, the description covers each parameter adequately. It mentions the return type CalcDaysResult and its contents. Missing details like error conditions or constraints (e.g., date format) but still sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed explanations for all 10 parameters, including their purpose (e.g., leave_type for balance check, avlb_annl_leave from init_leave_flow) and defaults (start_time_code default AM). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates actual leave days and validates leave balance, using specific verbs ('计算', '校验') and resources ('休假天数', '假期余额'). It distinguishes from siblings like init_leave_flow and submit_leave_application by focusing on the calculation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (after init_leave_flow, which provides balances) and for which leave types balance checks are performed. It does not explicitly state when not to use or direct to alternatives, but the flow is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据请假类型检查附件要求。
7 类请假类型的附件规则：
病假：诊断证明或病假条
产假：产检证明
工伤假：工伤证明
婚假：结婚证
丧假：死亡证明，且时长 ≤ 3 天（超出则拒绝）
流产假：诊断证明或病假条
年休假/调休假：无需附件
如果用户已上传附件（has_attachment=true），则 action=submit； 否则需上传时 action=upload。
Args: leave_type: 请假类型名称（如 "病假"、"婚假"）。 leave_days: 实际休假天数（字符串，来自 calculate_leave_days）。 has_attachment: 用户是否已上传附件。
Returns: AttachmentCheckResult: 包含 action（upload/submit/reject）和提示信息。
| Name | Required | Description | Default |
|---|---|---|---|
| leave_days | Yes | ||
| leave_type | Yes | ||
| has_attachment | Yes |
| Name | Required | Description |
|---|---|---|
| action | Yes | 下一步动作：upload（需上传附件）、submit（直接提交）、reject（拒绝，如丧假超3天） |
| message | No | 执行结果描述 |
| attachment_message | No | 附件上传提示信息（需上传时返回） |
| attachment_required | Yes | 该请假类型是否需要附件 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It discloses the logic for each leave type, including rejection conditions for 丧假>3 days, and the output action structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections. It is slightly verbose but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 7 leave type rules and the presence of an output schema, the description covers all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains each parameter in detail: leave_type (leave type name), leave_days (from calculate_leave_days), has_attachment (user upload status). Adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks attachment requirements based on leave type. It lists 7 leave types with specific rules, distinguishing it from sibling tools like upload_attachment and submit_leave_application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use the tool to determine the next action (upload or submit) based on has_attachment. It lacks explicit when-not-to-use or exclusions but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
初始化请假流程。
依次执行：获取用户信息（接口1）→ 检查未销假（接口4）→ 获取请假类型（接口2）→ 查询剩余假期（接口3）。 如果存在未销假记录，返回 has_pending_leave=true，LLM 应提示用户先销假。
两种调用方式：
提供 user_token：直接使用 Token 调用接口。
提供 user_code：自动通过 /auth/sso/getZhhhToken/{userCode} 获取 Token。 如果 Token 为空，返回提示"用户未登录，请先登录"。
Args: user_token: 用户认证 Token（可选，优先使用）。 user_code: 用户编码（可选，user_token 为空时通过此编码自动获取 Token）。
Returns: InitFlowResult: 包含用户信息、岗位列表、请假类型、剩余假期、Token。
| Name | Required | Description | Default |
|---|---|---|---|
| user_code | No | ||
| user_token | No |
| Name | Required | Description |
|---|---|---|
| message | Yes | 执行结果描述 |
| success | Yes | 是否执行成功 |
| user_code | No | 用户编码 |
| user_name | No | 用户名称 |
| user_orgs | No | 用户岗位列表 |
| user_token | No | 用户认证 Token，供后续工具使用 |
| leave_types | No | 可选请假类型列表 |
| avlb_ot_leave | No | 调休假剩余天数 |
| avlb_annl_leave | No | 年假剩余天数 |
| has_pending_leave | No | 是否存在未销假记录（true 表示需先销假） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description discloses key behaviors: the sequential API calls, automatic token retrieval, and the has_pending_leave flag. It does not mention any side effects, but the tool is read-heavy and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs and bullets, providing thorough information without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to detail return values but still summarizes them (user info, positions, leave types, etc.). It covers edge cases like token fetching and pending leave.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains both parameters: user_token as optional but preferred, and user_code as fallback with automatic token fetch. It adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initializes a leave flow and distinguishes it from siblings like submit_leave_application. It mentions the specific sequence of backend steps, making its unique purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines for two calling modes (user_token vs user_code) and mentions a special case for pending leave. However, it does not explicitly state when not to use this tool compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据用户选择的序号返回岗位信息。
用于用户有多个岗位时，从 init_leave_flow 返回的 user_orgs 中选择一个。 索引从 0 开始（与 Python 列表一致）。如果用户输入的是从 1 开始的序号， LLM 应在调用前转换为从 0 开始的索引。
Args: user_orgs: 岗位列表，来自 init_leave_flow 的返回值。 selected_index: 选中的岗位索引（从 0 开始）。
Returns: SelectOrgResult: 包含选中的岗位信息。
| Name | Required | Description | Default |
|---|---|---|---|
| user_orgs | Yes | ||
| selected_index | Yes |
| Name | Required | Description |
|---|---|---|
| message | Yes | 执行结果描述 |
| success | Yes | 是否执行成功 |
| selected_org | No | 选中的岗位信息 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes input and output but does not explicitly state if it is read-only or has side effects. Indexing detail is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is fairly concise with Args/Returns sections. Could be slightly more compact, but structure aids clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. Missing error handling (e.g., out-of-bounds index), but overall complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning: user_orgs is from init_leave_flow, selected_index is 0-based. This compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it selects organization info by index from a list, specifically from init_leave_flow's result, distinguishing it from sibling tools like init_leave_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (multiple orgs from init_leave_flow) and provides indexing conversion guidance. Does not mention when not to use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
提交请假申请。
调用接口 8 提交请假流程，返回申请单号。需要汇总所有信息： 用户信息、岗位信息、请假类型、日期、天数、原因、附件等。
Args: user_token: 用户认证 Token。 user_name: 申请人姓名（来自 init_leave_flow）。 user_code: 申请人编码（来自 init_leave_flow）。 selected_org: 选中的岗位信息（来自 select_organization）。 avlb_annl_leave: 年假剩余天数（来自 init_leave_flow）。 avlb_ot_leave: 调休假剩余天数（来自 init_leave_flow）。 leave_type_code: 请假类型编码。 leave_type_value: 请假类型名称。 start_date: 开始日期，格式 yyyy-MM-dd。 end_date: 结束日期，格式 yyyy-MM-dd。 leave_days: 实际休假天数（来自 calculate_leave_days）。 lv_reason: 请假原因。 start_time_code: 开始时间编码，AM 或 PM，默认 AM。 end_time_code: 结束时间编码，AM 或 PM，默认 AM。 file_ids: 附件 ID 列表（来自 upload_attachment，无附件时为 None）。 file_names: 附件名列表（来自 upload_attachment，无附件时为 None）。
Returns: SubmitResult: 包含申请单号。
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | ||
| file_ids | No | ||
| lv_reason | Yes | ||
| user_code | Yes | ||
| user_name | Yes | ||
| file_names | No | ||
| leave_days | Yes | ||
| start_date | Yes | ||
| user_token | Yes | ||
| selected_org | Yes | ||
| avlb_ot_leave | Yes | ||
| end_time_code | No | PM | |
| avlb_annl_leave | Yes | ||
| leave_type_code | Yes | ||
| start_time_code | No | AM | |
| leave_type_value | Yes |
| Name | Required | Description |
|---|---|---|
| message | Yes | 执行结果描述 |
| success | Yes | 是否执行成功 |
| apply_id | No | 请假申请单号 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool submits a leave process and returns an application number, indicating mutation. However, it does not detail side effects, authentication requirements, error handling, or data validation behaviors beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, a workflow note, and a detailed parameter list. While it is somewhat lengthy, the structured format compensates for the complexity of 16 parameters. Every sentence adds value, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and lack of output schema in the provided data, the description includes a Returns section specifying 'SubmitResult: 包含申请单号'. It also references all necessary prerequisite tools, making it a complete guide for using this tool in the leave application workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section provides clear, tool-specific context for each parameter, including source tool (e.g., 'from init_leave_flow') and allowed values (e.g., 'file_ids: 附件 ID 列表...无附件时为 None'). This adds significant meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '提交请假申请' (submit leave application) and '返回申请单号' (returns application number). It distinguishes itself from sibling tools like init_leave_flow and calculate_leave_days by being the final submission step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that all information must be gathered from other tools (user info from init_leave_flow, organization from select_organization, etc.), providing implicit workflow guidance. It lacks explicit when-not-to-use or alternative tool mentions but effectively communicates the prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
批量上传附件文件。
将 base64 编码的文件内容解码后调用接口 7 上传。支持同时上传多个附件。 单文件大小上限由 MAX_ATTACHMENT_SIZE_MB 控制（默认 10MB）。
Args: user_token: 用户认证 Token。 files: 附件列表，每个元素包含 file_name、mime_type、file_base64。
Returns: UploadResult: 包含上传后的文件 ID 和文件名列表。
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | ||
| user_token | Yes |
| Name | Required | Description |
|---|---|---|
| message | Yes | 执行结果描述 |
| success | Yes | 是否执行成功 |
| file_ids | No | 上传后的文件 ID 列表 |
| file_names | No | 上传后的文件名列表 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that it decodes base64 and calls an internal API, and mentions a file size limit (10MB default). However, with no annotations, it does not disclose potential side effects, authentication requirements beyond user_token, or error handling behavior, which limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief introductory sentence followed by sections for details, args, and returns. It is clear but could be more concise; the front-loaded purpose sentence is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (UploadResult) and no annotations, the description adequately covers purpose, parameters, size limits, and multiple file support. Missing details like error handling and output format description are partially compensated by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides detailed descriptions for each parameter (e.g., file_name, file_base64). The tool description adds value by explaining the decoding process and the size limit, which are not in the schema. This extra context justifies a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '批量上传附件文件' (batch upload attachment files) with a specific verb and resource. The name and context distinguish it from siblings like check_attachment_requirement and calculate_leave_days, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or comparison to other tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clear, distinct purpose: initialization, leave calculation, attachment check, organization selection, upload, and submission. No overlapping functionality.
All tools follow a consistent verb_noun pattern in snake_case, e.g., calculate_leave_days, upload_attachment. No deviations.
With 6 tools, the server covers the essential steps of a leave application process without unnecessary bloat or missing critical operations.
The tool set covers the full leave application workflow: init, calculate, check, select, upload, submit. Minor gaps like viewing or canceling existing leave are absent but not critical for the core flow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Carbon Voice MCP serves as a bridge that connects AI assistants like ChatGPT, Claude, and Cursor to a user's Carbon Voice account, turning voice messages and conversations into a private, on-demand knowledge base. It provides 28 specialized tools for comprehensive voice messaging management, including creating and sending messages, accessing conversation history with instant transcription, running AI actions (summarization, TLDR generation, meeting notes), and managing workspace collaboration through folders, contacts, and team communications.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/daomengKJ/leave_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
