Skip to main content
Glama
daomengKJ
by daomengKJ

check_attachment_requirement

Determines whether an attachment is required for a leave type and duration, returning the next action: upload, submit, or reject with a message.

Instructions

根据请假类型检查附件要求。

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)和提示信息。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
leave_daysYes
leave_typeYes
has_attachmentYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes下一步动作:upload(需上传附件)、submit(直接提交)、reject(拒绝,如丧假超3天)
messageNo执行结果描述
attachment_messageNo附件上传提示信息(需上传时返回)
attachment_requiredYes该请假类型是否需要附件
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Install Server

Other Tools

Latest Blog Posts

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/daomengKJ/leave_mcp'

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