Skip to main content
Glama
esign-cn-open-source

e签宝 MCP Server

Official
by esign-cn-open-source
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

e签宝 MCP 工具

基于 Model Context Protocol (MCP) 的 e签宝电子签署工具，支持文件上传、签署流程创建、签署状态查询等功能。

功能特点

  • 支持多种文件格式上传和自动转换为 PDF(支持本地文件路径和远程文件下载链接)：

    • PDF 文件（.pdf）

    • Word 文件（.docx, .doc, .rtf）

    • Excel 文件（.xlsx, .xls）

    • PowerPoint 文件（.pptx, .ppt）

    • WPS 文件（.wps, .et, .dps）

    • 图片文件（.jpeg, .jpg, .png, .bmp, .tiff, .tif, .gif）

    • HTML 文件（.html, .htm）

  • 自动文件状态检查，确保文件处理完成

  • 支持创建签署流程

  • 支持查询签署流程详情

  • 完整的日志记录

Related MCP server: digisign-mcp

配置

在 MCP 配置中添加以下环境变量：

{
  "esign-mcp": {
    "command": "npx",
    "args": ["-y", "mcp-server-esign@{version}"],
    "env": {
      "HOST": "选择对应环境：",
      "  - 测试环境：",
      "  - 沙箱环境：",
      "  - 正式环境：https://openapi.esign.cn",
      "APP_ID": "你的应用ID",
      "APP_SECRET": "你的应用密钥"
    }
  }
}

可用工具

1. create_sign_flow

创建签署流程，支持多种文件格式。

参数：

  • filePath: 本地文件路径

  • fileName: 文件名（必须包含正确的文件扩展名）

  • receiverPhone: 签署人手机号

示例：

{
  "filePath": "/path/to/contract.pdf",
  "fileName": "合同.pdf",
  "receiverPhone": "138****8000"
}

2. query_sign_flow

查询签署流程详情。

参数：

  • flowId: 签署流程ID

示例：

{
  "flowId": "12345678"
}

日志

日志文件位置：/tmp/app.log

日志包含以下信息：

  • 文件上传记录

  • 文件状态查询记录

  • 错误信息

注意事项

  1. 文件大小限制：

    • 总大小不超过 50MB

    • 单页内容不超过 20MB

  2. 文件名要求：

    • 不能包含特殊字符：/ \ : * " < > | ？

    • 不能包含 emoji 表情

    • 扩展名必须与实际文件格式一致

  3. 环境说明：

    • 测试/沙箱环境：用于开发测试

    • 正式环境：用于生产部署

错误处理

工具会自动处理常见错误情况：

  • 文件格式不支持

  • 文件上传失败

  • 文件转换失败

  • 签署流程创建失败

所有错误都会记录在日志文件中，并返回详细的错误信息。

License

MIT

相关链接

Available Tools

2 tools
create_sign_flowB

创建签署流程，支持多种文件格式，包括：PDF、Word、Excel、PPT、WPS、图片等。非PDF格式会自动转换为PDF。

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYes文件路径，支持本地文件路径或 HTTP(S) 远程文件下载链接。支持的格式：PDF(.pdf)、Word(.docx/.doc/.rtf)、Excel(.xlsx/.xls)、PPT(.pptx/.ppt)、WPS(.wps/.et/.dps)、图片(.jpg/.png/.bmp等)、HTML(.html/.htm)
fileNameYes文件名，必须包含文件扩展名（例如：合同.pdf、文档.docx），扩展名要与实际文件格式一致
receiverPhoneYes签署人手机号，用于接收签署通知短信
usernameNo签署人姓名,非必填，默认为空字符串，如果对方没有在e签宝注册过, 则必须提供姓名; 如果对应用户已存在个人信息，则不需要添加姓名

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions automatic PDF conversion for non-PDF files, it doesn't cover critical behavioral aspects like authentication requirements, rate limits, error conditions, what happens after creation, or whether this is a destructive/mutative operation. The description is insufficient for a tool that creates resources.

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 with just two sentences that efficiently convey key information about format support and PDF conversion. Every word earns its place, and it's front-loaded with the core purpose.

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

Completeness2/5

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

For a creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, what happens after creation, error handling, or important behavioral constraints. The agent would be missing critical context needed to use this tool effectively.

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 fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema descriptions. It mentions format support generally but doesn't provide parameter-specific insights. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose5/5

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

The description clearly states the specific action ('创建签署流程' - create signing flow) and resource (files with multiple formats), distinguishing it from the sibling tool 'query_sign_flow' which presumably queries rather than creates. It specifies the verb and resource precisely.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor any context about prerequisites or exclusions. It mentions format support but doesn't explain when to choose this over other tools or what scenarios it's designed for.

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

query_sign_flowC

Query sign flow details

ParametersJSON Schema
NameRequiredDescriptionDefault
flowIdYesSign flow ID

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states it queries details, which implies a read operation, but doesn't disclose any behavioral traits such as authentication requirements, rate limits, error conditions, or what format/details are returned. For a tool with zero annotation coverage, this is insufficient.

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 extremely concise with just three words, which is appropriately sized for a simple query tool. It's front-loaded with the core action ('Query'), but could benefit from slightly more detail to improve clarity without sacrificing brevity. There's no wasted language.

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

Completeness2/5

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

Given the tool's simplicity (1 parameter, 100% schema coverage, no output schema), the description is incomplete. It doesn't explain what 'sign flow' refers to, what details are returned, or any behavioral aspects. With no annotations and no output schema, the description should provide more context to be fully helpful to an AI agent.

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 has 100% description coverage (the 'flowId' parameter is documented as 'Sign flow ID'), so the baseline score is 3. The description adds no additional meaning about parameters beyond what the schema already provides—it doesn't explain what a 'sign flow' is, how to obtain the ID, or any constraints on the ID format.

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

Purpose3/5

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

The description 'Query sign flow details' states a general purpose (querying details about sign flows) but lacks specificity about what 'details' means or what resource is being queried. It distinguishes from the sibling 'create_sign_flow' by using 'query' vs 'create', but doesn't clarify what distinguishes it beyond the basic verb difference. The purpose is vague but not tautological or misleading.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or any exclusions. The only implied usage is that it's for querying rather than creating (based on sibling name), but this is not explicitly stated in the description itself.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: create_sign_flow initiates a signing process, while query_sign_flow retrieves details about an existing one. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the task.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with snake_case: create_sign_flow and query_sign_flow. The naming is predictable and aligns well with their respective actions, ensuring clarity and uniformity.

Tool Count2/5

With only two tools, the server feels under-scoped for an e-signature domain, which typically requires operations like updating flows, canceling, downloading documents, or managing templates. This limited set may hinder agents from completing common workflows.

Completeness2/5

The tool surface is severely incomplete for e-signature functionality. It lacks essential operations such as updating or canceling flows, downloading signed documents, and managing templates or signers. Agents will face significant gaps in handling full signing lifecycles.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

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/esign-cn-open-source/mcp-server-esign'

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