Skip to main content
Glama
yop-platform

yeepay-mcp

by yop-platform
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Yeepay MCP Service Integration

The Yeepay MCP service provides integration with Yeepay services via the Model Context Protocol (MCP).

npm version npm downloads

阅读中文文档

Features

  • create_webpage_yeepay_payment: Create Yeepay webpage payment order

    • Required parameters: orderId (string), amount (number), goodsName (string), userIp (string)

  • query_yeepay_payment_status: Query Yeepay payment order status

    • Required parameters: orderId (string)

Related MCP server: yapi-mcp

Prerequisites

  • Node.js (LTS version recommended)

  • pnpm (or npm)

Installation and Configuration

1. Installation

# Clone the repository
git clone https://github.com/yop-platform/yeepay-mcp.git
cd yeepay-mcp

# Install dependencies
npm install
# or
pnpm install

2. Configuration

Copy .env.example to .env and configure the following environment variables:

YOP_PARENT_MERCHANT_NO=Your parent merchant number
YOP_MERCHANT_NO=Your merchant number
YOP_APP_PRIVATE_KEY=Your private key
YOP_APP_KEY=Your application AppKey
YOP_NOTIFY_URL=https://your-domain.com/yeepay/notify

Usage

There are several ways to run and use this MCP service:

1. Run Locally

Development Mode (with hot-reloading)

npm run dev
# or
pnpm run dev

Production Mode

# Build the project
npm run build
# or
pnpm run build

# Start the service
npm start
# or
pnpm start

2. Run with Docker

# Build the image
docker build -t yeepay-mcp .

# Run the container (ensure the .env file exists)
docker run -p 3000:3000 --env-file .env yeepay-mcp

3. Call via npx

This project supports direct invocation via npx.

Local Project Invocation (Before Publishing)

Run in the project directory:

# First, build the project
npm run build

# Use npx to call the local package
npx . [arguments]

Or use the full path:

npx /absolute/path/to/yeepay-mcp [arguments]

Passing Arguments

You can pass arguments to the npx command:

npx . --port 3001 --host 0.0.0.0

Invocation After Publishing

Once the project is published to the npm registry, you can use it directly:

npx yeepay-mcp [arguments]

And you can specify a version:

npx yeepay-mcp@0.1.0 [arguments]

4. Integrate as an MCP Service

This service can be integrated into tools that support MCP (like Cline).

Startup Methods

Method 1: Package Runner (Recommended)

pnpm dlx yeepay-mcp
# or
npx yeepay-mcp

(Note: This method is available after the package is published to npm)

Method 2: Node (Local Development/Direct Path)

node /path/to/yeepay-mcp/dist/index.js

Important Note: Regardless of the startup method, the service needs access to the .env file in the working directory at runtime to obtain configuration.

Configure in Cline

Configure this service in Cline's MCP settings file (cline_mcp_settings.json).

Configure using Node (Local Development or Specific Path):

"yeepay-mcp": {
  "command": "node",
  "args": [
    "/path/to/yeepay-mcp/dist/index.js" // Replace with the actual absolute path
  ],
  "env": { // Alternatively, place the configuration in the .env file and ensure the service can read it
    "YOP_PARENT_MERCHANT_NO": "Your parent merchant number",
    "YOP_MERCHANT_NO": "Your merchant number",
    "YOP_APP_PRIVATE_KEY": "Your private key",
    "YOP_APP_KEY": "Your application AppKey",
    "YOP_NOTIFY_URL": "https://your-domain.com/yeepay/notify"
  },
  "disabled": false,
  "alwaysAllow": []
}

Configure using npx (After Publishing):

"yeepay-mcp": {
  "command": "npx",
  "args": [
    "yeepay-mcp" // Package name
    // You can add a version number, e.g., "yeepay-mcp@0.1.0"
    // You can also add arguments, e.g., "--port", "3001"
  ],
  "env": { // Same as above, env or .env file
    "YOP_PARENT_MERCHANT_NO": "Your parent merchant number",
    "YOP_MERCHANT_NO": "Your merchant number",
    "YOP_APP_PRIVATE_KEY": "Your private key",
    "YOP_APP_KEY": "Your application AppKey",
    "YOP_NOTIFY_URL": "https://your-domain.com/yeepay/notify"
  },
  "disabled": false,
  "alwaysAllow": []
}

Development Guide

Development Mode

Develop with hot-reloading:

pnpm run dev
# or
npm run dev

Commit Message Convention

This project uses the Conventional Commits specification to format commit messages. Each commit message should follow this format:

<type>(<scope>): <subject>

<body>

<footer>

Where:

  • type: Indicates the type of commit, e.g., feat, fix, docs, style, refactor, test, chore, etc.

  • scope: (Optional) Indicates the scope affected by the commit, e.g., core, server, payment, config, etc.

  • subject: Briefly describe the content of the commit, use imperative, present tense.

  • body: (Optional) Describe the content of the commit in detail, explaining the reason and method of modification.

  • footer: (Optional) Contains information about breaking changes (BREAKING CHANGE:) or closing issues (Closes #123).

Example:

feat(server): add health check endpoint

Add a new endpoint `/health` to check the health status of the server and its dependencies. This helps with monitoring and deployment verification.

Closes #123
BREAKING CHANGE: The configuration format for database connection has changed.

The project has configured commitlint and husky to automatically check if commit messages conform to the specification before committing. You can use .github/commit-template.txt as a template for commit messages.

Git Hooks

This project uses Husky to manage Git hooks:

  • pre-commit: Runs lint-staged to automatically format and lint staged files

  • commit-msg: Validates commit messages using commitlint to ensure they follow the Conventional Commits specification

The hooks are automatically installed when you run npm install and do not require any global installation of Husky.

Code Style

This project uses ESLint and Prettier to enforce and maintain code style consistency. Before committing code, lint-staged will automatically run to check and format staged files. Please ensure your editor is configured with the corresponding plugins for real-time feedback.

Release Process

Preparation

  • Ensure the version in package.json is up-to-date.

  • Ensure the bin field in package.json correctly points to dist/index.js so that npx can execute it.

  • Ensure all changes are committed and the build is successful (npm run build).

Manual Publishing to npm

  1. Log in to npm:

    npm login

  2. Publish:

    npm publish
# or if using pnpm
pnpm publish

Automatic Publishing with GitHub Actions

This project is configured with GitHub Actions to automatically publish to npm when a GitHub Release is created.

  1. Create GitHub Release:

    • On the GitHub repository page, click "Releases".

    • Click "Draft a new release" or "Create a new release".

    • Enter a Tag version matching the version number in package.json (e.g., v0.1.0).

    • Select the target branch (usually main or master).

    • Enter the Release title (e.g., Version 0.1.0).

    • Add release notes (describe the changes in this version).

    • Click "Publish release".

GitHub Actions will automatically trigger the .github/workflows/release.yml workflow to build and publish the package to npm.

Version Updates

Manual Version Update

Use the npm version command to update the version number in package.json and create a git tag:

# Patch version update (1.0.0 -> 1.0.1)
npm version patch

# Minor version update (1.0.0 -> 1.1.0)
npm version minor

# Major version update (1.0.0 -> 2.0.0)
npm version major

Then push to GitHub and publish manually:

git push --follow-tags
npm publish

Automatic Version Update with semantic-release (If Configured)

If the project is configured with semantic-release, version updates and publishing are usually automated based on Conventional Commits:

  • fix: commits trigger a patch version update.

  • feat: commits trigger a minor version update.

  • Commits containing BREAKING CHANGE: trigger a major version update.

After merging into the main branch, the CI/CD process automatically calculates the version, creates tags, generates release notes, and publishes to npm.

Post-Publish Verification

After successful publishing, you can verify in the following ways:

  1. Search for your package name (yeepay-mcp) on the npm website.

  2. In a new empty directory, try installing and running your package using npx:

    npx yeepay-mcp --help # or other arguments

Contributing Guide

Contributions, bug reports, and improvement suggestions are welcome. Please follow these steps:

  1. Fork this repository to your GitHub account.

  2. Clone your forked repository locally: git clone https://github.com/YOUR_USERNAME/yeepay-mcp.git

  3. Create a new feature branch: git checkout -b feature/your-amazing-feature

  4. Make your code changes.

  5. Ensure you follow the commit message convention when committing changes: git commit -m 'feat: add some amazing feature'

  6. Push your branch to your fork: git push origin feature/your-amazing-feature

  7. Create a Pull Request in the original repository describing your changes.

License

This project is licensed under the Apache License. See the LICENSE file for details.

Contact

For questions or suggestions, please contact us via:

Tip

Before the package is published to the npm registry, ensure you use the correct local path or absolute path when configuring or calling it, instead of the package name, to avoid errors like "package was not found".

Available Tools

2 tools
create_webpage_yeepay_paymentC

创建移动支付订单工具

ParametersJSON Schema
NameRequiredDescriptionDefault
amountYes交易金额
goodsNameYes商品名称
orderIdYes商户订单号
userIpNo用户IP

TDQS

C2.7/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. It states '创建' (create) which implies a write/mutation operation, but doesn't disclose any behavioral traits like authentication requirements, rate limits, whether the operation is idempotent, what happens on failure, or what the expected response looks like. This is inadequate for a mutation tool with zero annotation coverage.

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 - a single phrase that directly states the tool's purpose. There's zero waste or unnecessary verbiage, and it's appropriately sized for what it communicates.

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 payment creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or important behavioral aspects. Given the complexity of payment processing and the lack of structured metadata, the description should provide more complete context about the operation.

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%, with all parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.

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 '创建移动支付订单工具' translates to 'Create mobile payment order tool', which clearly states the action (create) and resource (mobile payment order). However, it doesn't distinguish from its sibling 'query_yeepay_payment_status' beyond the basic verb difference, and the purpose could be more specific about what type of payment order is being created.

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. There's no mention of prerequisites, when-not-to-use scenarios, or how it relates to the sibling tool 'query_yeepay_payment_status' for checking payment status after creation.

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

query_yeepay_payment_statusC

查询支付状态工具

ParametersJSON Schema
NameRequiredDescriptionDefault
orderIdYes商户订单号

TDQS

C2.6/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. '查询' (query) implies a read-only operation, but the description doesn't specify authentication requirements, rate limits, error conditions, or what happens when querying non-existent orders. For a payment status tool with zero annotation coverage, this leaves significant behavioral gaps.

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 - just 6 Chinese characters that directly state the tool's purpose. There's zero wasted language, though this conciseness comes at the cost of completeness. The structure is front-loaded with the core function stated immediately.

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 payment status query tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned, possible status values, error handling, or integration context. The agent would need to guess about the response format and behavioral characteristics, making this incomplete for practical use.

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 the parameter 'orderId' documented as '商户订单号' (merchant order number). The description adds no additional parameter information beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting for parameter documentation.

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 payment status tool) states the basic purpose of querying payment status, which is clear but vague. It specifies the verb '查询' (query) and resource '支付状态' (payment status), but doesn't distinguish from its sibling 'create_webpage_yeepay_payment' or provide specific details about what payment system or scope is involved.

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. There's no mention of prerequisites, timing considerations, or comparison with the sibling tool 'create_webpage_yeepay_payment'. The agent must infer usage context solely from the tool name and basic purpose.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedcreate_webpage_yeepay_payment
    • First observedquery_yeepay_payment_status
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.9/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one creates a payment order, and the other queries the payment status. There is no overlap or ambiguity between these functions, making it easy for an agent to select the correct tool based on the task.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with underscores: 'create_webpage_yeepay_payment' and 'query_yeepay_payment_status'. The naming is predictable and readable, with no deviations in style or convention.

Tool Count2/5

With only two tools, the server feels thin for a payment processing domain. While the tools cover creation and status querying, typical payment workflows might require additional operations like refunds, cancellations, or listing transactions, making the tool count insufficient for comprehensive coverage.

Completeness2/5

The tool set is severely incomplete for a payment processing server. It lacks essential operations such as refunding payments, canceling orders, handling webhooks, or retrieving transaction lists. This creates significant gaps that could lead to agent failures when attempting full payment lifecycle management.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • yop-mcp

    yop-platform
    A
    license
    A
    quality
    C
    maintenance
    yop-mcp 是一个专为易宝支付开放平台(YOP)设计的 MCP (Model Context Protocol) Server，提供了一套完整的工具函数，帮助开发者通过AI助手（如Claude、Cursor等）更便捷地获取YOP平台的相关信息、生成密钥对、下载证书等操作。
    10
    3
    Apache 2.0

  • yapi-mcp

    geq1fan
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server for YApi that enables developers to search, view, create, and update API definitions directly from MCP-compatible IDEs.
    2
    MIT

  • Libs MCP Service

    AdminRHS
    F
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol (MCP) service for integration with external platforms, providing CRUD operations for 23 entity types through a standardized MCP interface.
    11
    -