Skip to main content
Glama
qilincoder

PyCopilot

by qilincoder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

PyCopilot

一个基于 MCP (Model Context Protocol) 的 Python 服务端项目, 支持多个工具。

功能特性

  • 加法计算工具 (add): 支持两个数字相加

Related MCP server: Addition MCP Server

环境要求

  • Python 3.10+

  • uv (Python 包管理器)

安装

  1. 克隆或下载本项目

  2. 安装依赖：

uv sync

运行

项目支持多种运行方式：

方式 1: 使用 uvx (推荐)

uvx --from . pycopilot

或者直接安装后运行：

uv tool install .
uvx pycopilot

方式 2: 使用 uv run

uv run pycopilot

方式 3: 作为 Python 模块运行

python -m pycopilot

方式 4: 传统方式 (向后兼容)

uv run main.py
# 或
python main.py

在 Cherry Studio 中使用

配置步骤

  1. 打开 Cherry Studio

  2. 进入设置 -> MCP 服务器配置

  3. 添加新的 MCP 服务器，配置如下：

推荐配置 - 使用 uvx

服务器名称: PyCopilot

命令:

uvx

参数:

[
  "--from",
  "D:\\Home\\Projects\\PyCopilot",
  "pycopilot"
]

工作目录: (可选)

D:\Home\Projects\PyCopilot

备选配置 1 - 使用 uv run

命令:

uv

参数:

[
  "run",
  "--directory",
  "D:\\Home\\Projects\\PyCopilot",
  "pycopilot"
]

配置文件示例

如果 Cherry Studio 支持配置文件导入，可以使用以下 JSON 配置：

推荐配置 - uvx 方式

{
  "mcpServers": {
    "pycopilot": {
      "command": "uvx",
      "args": [
        "--from",
        "D:\\Home\\Projects\\PyCopilot",
        "pycopilot"
      ]
    }
  }
}

备选配置 - uv run 方式

{
  "mcpServers": {
    "pycopilot": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "D:\\Home\\Projects\\PyCopilot",
        "pycopilot"
      ]
    }
  }
}

使用示例

配置完成后，在 Cherry Studio 的对话中，你可以使用以下方式调用加法工具：

请帮我计算 123 + 456

MCP 服务端会自动调用 add 工具进行计算并返回结果。

可用工具

add - 加法计算

描述: 计算两个数字的和

参数:

  • a (number): 第一个数字

  • b (number): 第二个数字

返回: 两个数字的和

示例:

{
  "a": 10,
  "b": 20
}

返回: "The sum of 10 and 20 is 30"

项目结构

PyCopilot/
├── src/
│   └── pycopilot/
│       ├── __init__.py       # 包初始化文件
│       ├── __main__.py       # 模块入口点
│       └── server.py         # MCP 服务端核心实现
├── main.py                   # 向后兼容的入口点
├── pyproject.toml            # 项目配置文件（含 scripts 配置）
├── README.md                 # 项目说明文档
└── .venv/                    # 虚拟环境目录

相关资源

Available Tools

2 tools
addA

Add two numbers together. Returns the sum of a and b.

ParametersJSON Schema
NameRequiredDescriptionDefault
aYesThe first number
bYesThe second number

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It states the operation (addition) and return value (the sum). For a pure, stateless arithmetic operation, there is minimal risk or side-effect behavior to disclose further. The description covers the essential behavioral contract adequately.

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, informative sentences with zero waste. Every word earns its place, and the key information is front-loaded in the first sentence.

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?

This is a simple tool with 2 parameters, full schema coverage, and no output schema. For an arithmetic operation like this, the description is complete - it states what it does and what it returns. The low complexity means no further documentation is necessary.

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 both parameters (a and b) having descriptions in the schema. The description mentions 'a and b' which maps directly to the parameters, but adds no additional semantic detail beyond the schema's own documentation. Baseline 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 has a specific verb ('add'), clear resource ('two numbers'), and states the result ('Returns the sum'). It clearly communicates the operation. It doesn't explicitly distinguish from the sibling 'multiply' tool, but the verb 'add' makes the difference self-evident.

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 its usage: use it when adding numbers. It doesn't explicitly state when not to use it or mention the sibling 'multiply' alternative. However, given the simplicity of the tool, the implied usage is reasonably clear and adequate.

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

multiplyA

Multiply two numbers together.

ParametersJSON Schema
NameRequiredDescriptionDefault
aYesThe first number
bYesThe second number

TDQS

A3.6/5.0
Behavior3/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. 'Multiply two numbers together' is a pure computation with no side effects implied, which is reasonably transparent. However, it doesn't state return type, precision handling, or whether very large numbers have special behavior. The simplicity of the operation makes this acceptable but not thorough.

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 4-word sentence that is exceptionally economical. Every word earns its place with no fluff, no redundancy, and no wasted structure. For a tool of this simplicity, this is ideal conciseness.

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?

This is a trivially simple tool: 2 parameters, both required, both documented at 100%, no output schema, no nested objects, no annotations. Given this minimal complexity, the single-sentence description is largely sufficient for an agent to select and invoke it correctly. The only minor gap is the lack of a defined return format, but for a pure arithmetic operation this is easily inferred.

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%, meaning both parameters (a and b) are already fully described as 'The first number' and 'The second number'. The description adds minimal value beyond the schema - it just restates that two numbers are multiplied. Baseline 3 is appropriate since the schema does the heavy lifting and the description confirms the relationship between the two parameters.

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 'Multiply two numbers together' clearly states the verb (multiply), resource (two numbers), and outcome. It's distinct from its sibling 'add' which would be used for addition. A minor gap is that it doesn't specify any return behavior or edge cases, but the purpose is 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 implies usage context (multiplying two numbers), and the sibling 'add' provides some implicit differentiation for arithmetic operations. However, there's no explicit guidance on when to choose this over add, no mention of number type constraints (integers vs floats), overflow considerations, or ordering implications.

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 updatesv0.1.0
    • First observedadd
    • First observedmultiply
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

A3.7/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct - one adds and one multiplies. There is no ambiguity between them.

Naming Consistency4/5

Both tools follow a consistent verb-only naming convention (add, multiply), which is simple and predictable.

Tool Count3/5

Two tools feels very thin, even for a simple calculator server. A set like this could reasonably include subtract, divide, or other basic operations, but for its very narrow apparent scope it's borderline.

Completeness3/5

The tool surface is extremely limited, covering only two basic arithmetic operations. There's no indication of a broader domain purpose that would justify additional tools, but for a calculator-style server this is somewhat acceptable yet still quite thin.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers