Skip to main content
Glama

COPT-MCP 🚀

基于杉数科技开发的COPT求解器的MCP服务,提供专门为大语言模型设计的文档和示例

ChengJiale150 开发

Python COPT FastMCP License Version

English | 中文


📖 目录

Related MCP server: linked-docs

🎯 项目简介

COPT-MCP 是一个基于 Model Context Protocol (MCP) 的服务,为支持MCP的客户端提供COPT求解器的相关接口的详细文档与示例,旨在实现COPT求解器的文档AI化适配,降低模型幻觉,提高大模型使用COPT求解器的准确性。

为什么需要COPT-MCP

COPT求解器是一款针对大规模优化问题的高效数学规划求解器,支持多种优化问题,是解决复杂运筹规划问题的不二之选。然而,COPT求解器的相关信息在公开场合较少,导致大模型在调用COPT求解器时,容易出现幻觉,影响使用体验。直接输入COPT的官方文档,也会因为文档过长,远超模型上下文长度上限,而且过多的无关文档内容也会影响模型理解,导致上下文迷失。

COPT-MCP旨在为大模型提供COPT求解器的相关接口的最小可行文档与示例,通过精心组织与选取文档内容,实现COPT求解器的文档AI化适配,输出最小必要信息,降低模型幻觉,提高大模型使用COPT求解器相关接口的准确性。

COPT-MCP的优势

  • 🔧 多类型支持: 支持多种规划问题与编程语言

  • 📚 丰富的示例库: 提供详细的代码示例和API说明

  • 📖 学术引用支持: 提供Word和BibTeX格式的引用模板

  • 🔌 MCP协议: 通过MCP协议方便与各类大模型与Agent嵌入集成

  • 🚀 轻量化部署: 无需安装额外软件,仅需Python虚拟环境

  • 📝 中文文档: 完整的中文文档和示例说明

✨ 功能一览

类型

名称

描述

Tool

get_citation

获取COPT的引用格式

Tool

get_reference

获取COPT的指定语言接口对应问题的参考示例

Tool

get_api_doc

根据查询指令返回最相似的API文档

🛠️ 安装与使用

环境要求

  • Python 3.12+

  • FastMCP

  • uv (推荐,用于版本管理)

安装步骤

  1. 克隆项目

git clone https://github.com/ChengJiale150/COPT-MCP.git
cd COPT-MCP
  1. 安装依赖

pip install uv
uv sync
  1. 配置环境变量

在config.json文件中配置模型的必要的API_KEY,这里默认使用的是硅基流动的相关模型

"embedding": {
    "url": "https://api.siliconflow.cn/v1/embeddings",
    "api_key": "<your api key>"
},
"reranker": {
    "url": "https://api.siliconflow.cn/v1/rerank",
    "api_key": "<your api key>"
}
  1. 运行MCP服务

uv run fastmcp run server.py

在客户端中集成

你可以使用FastMCP自动集成该MCP服务,具体详见MCP集成文档,这里以使用FastMCP在Cursor中集成为例:

fastmcp install cursor server.py

或者也可以在支持MCP的客户端配置文件中手动添加:

{
  "mcpServers": {
    "COPT-MCP": {
      "command": "uv",
      "args": [
        "run",
        "--with", "fastmcp",
        "--with", "requests",
        "--with", "sqlite_vec",
        "fastmcp", "run", 
        "your/path/to/COPT-MCP/server.py"
      ],
      "env": {},
      "transport": "stdio"
    }
  }
}

其他配置详见详细配置指引

🔧 详细介绍

COPT-MCP提供三个核心工具,帮助AI助手更好地为用户提供优化求解服务。

获取引用格式

工具名称: get_citation

功能: 获取COPT求解器的学术引用格式,支持Word和BibTeX格式。

参数:

  • citation_type (str): 引用类型

    • "word": 适用于Word文档的引用格式

    • "bibtex": 适用于BibTeX文件的引用格式

返回: 对应格式的引用文本

使用说明:

  • 当用户需要在其学术论文中引用COPT求解器时,AI助手可以调用get_citation工具,并传入"word""bibtex"参数,获取对应格式的引用文本。

  • 引用对应的格式文本位于resource/citation文件夹中,可以自行查看并修改。

获取参考示例

工具名称: get_reference

功能: 获取指定问题类型和编程语言的参考示例代码,包含详细的数学建模说明和代码注释。

参数:

  • problem_type (str): 求解问题类型(目前仅支持以下类型)

    • "LP": 线性规划 (Linear Programming)

    • "MIP": 混合整数规划 (Mixed Integer Programming)

    • "SOCP": 二阶锥规划 (Second-Order Cone Programming)

    • "NLP": 非线性规划 (Nonlinear Programming)

  • language (str): API接口语言(目前仅支持以下类型)

    • "Python": Python接口

返回: 包含数学定义、代码示例和详细注释的Markdown格式文档

使用说明:

  • 当用户需要解决COPT求解器相关问题时,AI助手会优先调用get_reference工具,并传入problem_typelanguage参数,获取对应问题的参考示例,利用大模型良好的Few Shot理解能力,降低模型幻觉,提高模型使用COPT求解器的准确性。

  • 参考示例代码位于resource/example/{problem_type}/{language}.md文件中,可以自行查看并修改,也可以根据需要添加更多示例。

获取API文档

工具名称: get_api_doc

功能: 根据查询指令返回最相似的API文档信息

参数:

  • instructions (str): 查询指令,支持自然语言描述与代码片段的查询,参考的查询指令如下:

    • "name": 查询API名称,如"Model.addConstr()"/"Envr()"

    • "description": 查询需求描述,如"使用矩阵建模添加一组线性约束"

  • language (str): API接口语言(目前仅支持以下类型)

    • "Python": Python接口

  • domain (str): 查询指令对应的字段,目前支持的领域如下:

    • "name": 查询API名称

    • "description": 查询API描述

  • recall_num(int): 查询召回数量,默认为10,最大为25

  • return_num(int): 重排序后最终返回数量,默认为3,最大为8

返回: 包含API名称、描述、示例代码的Markdown格式文档

使用说明:

  • 当大模型不清楚COPT求解器的相关API时,会优先调用get_api_doc工具,并传入instructionslanguagedomainrecall_num参数,获取对应API的文档。

  • 数据来源为COPT求解器的官方文档,通过嵌入模型召回最相似的API文档,并经过重排序返回给大模型。

  • 数据存储在resource/api_doc/{language}文件夹中,分别存储为JSON格式(原始数据,用于用户查看)与db格式(用于模型查询)。

  • 由于API文档数量较多,目前尚不完善,已完成的API文档详见resource/api_doc/{language}文件夹中的TODO.md,后续会持续更新,欢迎大家贡献更多API文档。

🤝 贡献指南

我们欢迎社区贡献!如果您想为COPT-MCP项目做出贡献,请:

  1. Fork 本仓库

  2. 创建您的特性分支 (git checkout -b feature/AmazingFeature)

  3. 提交您的更改 (git commit -m 'Add some AmazingFeature')

  4. 推送到分支 (git push origin feature/AmazingFeature)

  5. 开启一个 Pull Request

贡献类型

  • 🐛 Bug修复

  • 📝 旧功能完善

  • ✨ 新功能开发

  • 📚 文档改进

  • 🧪 测试用例添加

  • 🌍 国际化支持

📝 更新日志

下述日志仅记录版本大更新记录的概要,具体信息详见更新日志

最新信息

  • v0.4.0(2025-08-10) 添加非线性规划(NLP)的参考示例,完善了MCP类型注释

历史信息

  • v0.1.0(2025-07-29) 初始版本,完成COPT-MCP的快速集成与使用

  • v0.2.0(2025-07-31) 完善了Python的API接口的全部文档,get_api_doc添加了重排序功能

  • v0.3.0(2025-08-04) 修改了文档结构,添加了详尽的MCP安装支持

  • v0.4.0(2025-08-10) 添加非线性规划(NLP)的参考示例,完善了MCP类型注释

🤗 致谢

本项目的成立与完成离不开下述诸位的无私帮助,没有他们就没有COPT-MCP的诞生,在此表示衷心的感谢:

  • 杉数科技: 感谢杉数科技开发了COPT求解器,并提供了详尽的官方文档,没有COPT求解器就没有COPT-MCP的诞生

  • FastMCP: 感谢FastMCP的开发者们,没有FastMCP就没有COPT-MCP的快速集成

  • Claude Code: 感谢Claude Code, TA是我使用过的最强大的AI编程助手,没有TA就没有COPT-MCP的快速开发

  • Cursor: 感谢Cursor, TA才是本篇README的第一作者,没有TA就没有COPT-MCP文档的快速完成

此外,还要感谢杉数COPT求解器交流2群(QQ群号:142636109)的各位大佬,大家的讨论给了我很多启发,让我对COPT求解器有了更深入的理解,在此表示衷心的感谢。

最后,感谢各位使用COPT-MCP,如果有什么问题或者建议,欢迎随时联系我,我会尽快回复。

📞 联系我们

相关链接


如果这个项目对您有帮助,请给我们一个 ⭐️

Made with ❤️ by ChengJiale150

Available Tools

3 tools
get_api_docA

根据查询指令召回并排序最相似的API文档,在你不清楚COPT的相关API用法时,可以调用此工具

Args: instructions: 查询指令,支持自然语言描述与代码片段的查询,参考的查询指令如下: - "name": 查询API名称,如"Model.addConstr()"/"Envr()" - "description": 查询需求描述,如"使用矩阵建模添加一组线性约束" language: API接口语言,目前支持的语言如下: - "Python": Python接口 domain: 查询指令对应的字段,目前支持的领域如下: - "name": 查询API名称 - "description": 查询API描述 recall_num: 查询召回数量,默认为10,最大为25 return_num: 重排序后最终返回数量,默认为3,最大为8

Hints: - 在能够明确API名称时,优先选择"name"字段 - 在希望精准查询特定API时,推荐选择"name"字段 - 在希望根据需求描述模糊查询时,推荐选择"description"字段

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYes查询指令对应的字段
languageYesAPI接口语言
recall_numYes查询召回数量
return_numYes重排序后最终返回数量
instructionsYes查询指令,支持自然语言描述与代码片段的查询

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It explains the retrieval and re-ranking behavior, the distinction between recall_num and return_num (with max values), and supported input types (natural language and code snippets). It doesn't state read-only behavior explicitly, but the search/ranking nature and absence of side effects is implied. It doesn't cover error cases or response format, but the output schema covers return structure.

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 well-structured with a front-loaded purpose sentence, a clear 'Args:' section with bullet-point examples, and a concise 'Hints:' section. Each part adds value; no filler or redundancy. The formatting aids readability and quick comprehension.

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?

The tool is a search/retrieval operation with 5 parameters, all covered in the description. The description provides use cases, parameter details, and hints. Since an output schema is present, not explaining return values is acceptable. The only minor gap is the lack of explicit mention about read-only nature or potential limitations, but overall it is complete for its complexity.

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?

The description adds significant meaning beyond the schema. It provides defaults for recall_num (10) and return_num (3), enumerates valid values for language ('Python') and domain ('name'/'description'), and gives illustrative query examples for instructions ('Model.addConstr()' and a description query). Schema descriptions are generic, so the description compensates effectively with concrete usage details.

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's purpose: to recall and rank the most similar API docs based on query instructions, specifically for COPT API usage. It distinguishes from sibling tools (get_citation, get_reference) by focusing on API documentation search, and uses a specific verb ('召回并排序') that conveys the retrieval and ranking behavior.

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 explicitly states when to use the tool ('when you are unclear about COPT's relevant API usage') and provides hints on selecting 'name' vs 'description' fields for different query scenarios. It doesn't explicitly mention when not to use it or name alternatives, but the context and field-level recommendations offer clear guidance.

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

get_citationA

获取COPT的引用格式

Args: citation_type: 引用类型,包括: - "word": 适用于word文档 - "bibtex": 适用于bibtex文件

ParametersJSON Schema
NameRequiredDescriptionDefault
citation_typeYes引用类型

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/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. It only describes the parameter and its values, without stating that this is a read-only operation, any permissions required, or side effects. The name 'get' implies read-only behavior, but the description does not confirm or elaborate on it.

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 brief and front-loaded with the main purpose. The Args block is clear and each element earns its place, with no unnecessary words or vague explanations.

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?

Given the simplicity of the tool (single parameter, output schema present), the description covers the essential purpose and parameter semantics sufficiently. It lacks mention of error handling or relationship to sibling tools, but these are not critical for such a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only describes the parameter as '引用类型' (citation type) with no allowed values. The description adds concrete enum values ('word' and 'bibtex') and their intended use cases, which is valuable semantic information that goes 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 states '获取COPT的引用格式' (Get COPT citation format), which is a specific verb and resource, and lists the supported formats. This clearly distinguishes it from the sibling tools 'get_reference' and 'get_api_doc'.

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 gives concrete guidance on the citation_type parameter values ('word' for Word documents, 'bibtex' for BibTeX files), which is helpful. However, it does not mention when to use this tool over get_reference or get_api_doc, so the usage context is only implied by the tool name and purpose.

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

get_referenceA

获取COPT的指定语言接口对应问题的参考示例,推荐在调用COPT解决对应问题前调用

Args: problem_type: 求解问题类型,目前支持的问题类型如下: - "LP": 线性规划(LP) - "MIP": 混合整数规划(MIP) - "SOCP": 二阶锥规划(SOCP) - "NLP": 非线性规划(NLP) language: API接口语言,目前支持的语言如下: - "Python": Python接口

ParametersJSON Schema
NameRequiredDescriptionDefault
languageYesAPI接口语言
problem_typeYes求解问题类型

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

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

The description does not disclose behavioral traits beyond the purpose itself. With no annotations provided, the description carries the full burden. It implies a read-only operation (get), but does not mention whether it returns code snippets, requires network access, or has any side effects. A basic 3 is given because the non-destructive nature is evident from the tool name.

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 concise and well-structured: a single lead sentence stating the purpose, followed by a clear Args list with bullet points for allowed values. Every sentence earns its place, with no redundant information.

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?

The description covers all necessary context for a two-parameter tool: purpose, when to use, and parameter values. An output schema exists, so return value details are not needed. It could be slightly more complete with an explicit mention that the example includes code, but overall it is fairly complete.

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?

While the schema provides generic descriptions for both parameters, the description adds significant value by enumerating all supported values for problem_type (LP, MIP, SOCP, NLP) and language (Python). This goes well beyond the schema's '求解问题类型' and 'API接口语言', making parameter meaning fully explicit.

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's purpose: to retrieve reference examples for a specified problem type and language in COPT. The verb '获取' (get) combined with the resource '参考示例' (reference examples) and specific parameters (problem_type, language) makes it specific and distinct from sibling tools like get_citation and get_api_doc.

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 provides clear usage context by recommending calling this tool before solving a problem with COPT. This tells the agent when to use it, but it does not explicitly mention alternatives or when not to use it, which would warrant a 5.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv0.4.0
    • First observedget_api_doc
    • First observedget_citation
    • First observedget_reference

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct resource: formatting citations, fetching reference examples, and searching API docs. There is no overlap in their purposes, and the descriptions make the appropriate use case for each clear.

Naming Consistency5/5

All tool names follow a consistent 'get_' prefix followed by a noun (citation, reference, api_doc). The naming pattern is uniform and predictable, making it easy to infer functionality.

Tool Count5/5

With 3 tools covering citations, examples, and API documentation, the server is well-scoped for its purpose as a COPT reference helper. The small count is appropriate because each tool provides distinct, essential functionality.

Completeness4/5

The server covers the main reference needs: getting citations, example code for specific problem types, and API documentation search. Minor gaps exist (e.g., only Python language support, no tool to list all available options), but these are acceptable for the stated domain.

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

  • A
    license
    B
    quality
    C
    maintenance
    Enables AI agents to automate COMSOL Multiphysics simulations, including model management, geometry building, physics configuration, meshing, solving, and results visualization through the MCP protocol.
    78
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to intelligently search and reference documentation using hybrid semantic + keyword search via MCP protocol.
    -
  • A
    license
    A
    quality
    D
    maintenance
    MCP server that provides AI with documentation for 221 JointQuant API functions and 2,479 data table fields, enabling accurate code generation without hallucination.
    6
    5
    MIT

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/ChengJiale150/COPT-MCP'

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