This server provides a tool to retrieve detailed information about work items (requirements) by their ID via the MCP protocol.
Retrieve Work Item Details: Fetch structured JSON data containing the plain text description, image URLs, and raw HTML content of a work item by providing its ID (e.g., YEPPPP-154).
Error Handling: Returns standardized error messages if the external API request fails.
Security: Supports secure handling of sensitive information (organization ID and API token) through environment variables or .env files.
Deployment Options: Compatible with Docker deployment for production use.
Development Tools: Provides utilities for local development and testing with features like hot reload.
Agent Integration: Exposes the get_workitem_description tool that agents can discover and use without needing to handle authentication details.
Supports containerized deployment with various methods for environment variable injection, allowing secure configuration of credentials for production environments.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Workitem Server get description for workitem YEPPPP-154"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
本项目推荐使用 uv 进行依赖管理和运行。
pip install uv # 或参考 uv 官方文档uv pip install -r requirements.txtRelated MCP server: Alibaba Cloud RDS OpenAPI MCP Server
推荐使用 .env 文件或环境变量注入敏感信息。
必需：
organizationId：阿里云组织ID
x-yunxiao-token：阿里云API Token
fastmcp 和 uv 支持自动加载项目根目录下的 .env 文件，无需额外代码。
启动服务时（如 uv run mcp run mcp_server.py），会自动读取 .env 文件中的变量。
你也可以用 python-dotenv 手动加载（如有特殊需求）。
在项目根目录下新建 .env 文件，内容如下：
organizationId=your_org_id
x-yunxiao-token=your_token.env 文件用于本地开发和测试，请勿提交敏感信息到代码仓库。
建议在 .gitignore 文件中加入 .env，防止泄漏：
# .gitignore
.envdocker build -t yx-mcp .通过 --env-file 挂载 .env 文件
在项目根目录准备好 .env 文件（内容同上）
启动容器：
docker run --env-file .env -p 9000:9000 yx-mcp通过 -e 传递环境变量
直接在命令行传递敏感信息：
docker run -e organizationId=your_org_id -e x-yunxiao-token=your_token -p 9000:9000 yx-mcp通过 volume 挂载 .env 文件
将本地 .env 文件挂载到容器内：
docker run -v $(pwd)/.env:/app/.env -p 9000:9000 yx-mcp安全提示： 不要将
.env文件 COPY 进镜像，避免敏感信息泄漏。推荐用--env-file或-e方式传递。
# 方式一：直接用环境变量
export organizationId=your_org_id
export x-yunxiao-token=your_token
uv run mcp run mcp_server.py
# 方式二：自动加载 .env 文件（推荐）
uv run mcp run mcp_server.py本服务通过 MCP 协议暴露 get_workitem_description 工具，参数为需求ID（如 YEPPPP-154），返回结构化 JSON，包含：
text：纯文本描述
images：图片 URL 列表
html：原始 HTML 内容
{
"id": "YEPPPP-154",
"text": "需求描述文本...",
"images": ["https://...jpg"],
"html": "<div>...</div>"
}若外部 API 请求失败，返回 { "error": "错误信息" }，agent 可据此判断。
通过 MCP 协议自动发现和调用 get_workitem_description 工具。
仅需传入 id 参数，无需关心 org_id/token。
推荐用 uv run fastmcp dev mcp_server.py 进行本地开发，支持热重载和交互测试。
支持标准 MCP agent 生态。
通过需求 ID 获取需求详情, 内部会有图片需要一起解析
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 需求ID，必须以 YEPPPP 开头，如 YEPPPP-154 |
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 mentions that '内部会有图片需要一起解析' (internal images need parsing), which adds some context about output complexity. However, it lacks details on permissions, rate limits, error handling, or the return format. For a read operation 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences in Chinese, front-loading the core purpose. The second sentence about image parsing adds relevant context without unnecessary elaboration. It could be slightly more structured but avoids waste, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 minimally adequate. It states the purpose and hints at output complexity (images), but lacks details on behavioral aspects like authentication or response format. Without annotations or output schema, it should provide more context for a read operation, resulting in an average score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond what the input schema provides. The schema has 100% coverage with a clear description of the 'id' parameter (requirement ID starting with YEPPPP). The tool description only repeats '需求 ID' without extra syntax or format details, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '通过需求 ID 获取需求详情' (get requirement details via requirement ID). It specifies the verb ('获取' - get) and resource ('需求详情' - requirement details), making the action explicit. However, it doesn't differentiate from siblings since none are provided, so it cannot earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 mentions '内部会有图片需要一起解析' (there will be internal images that need to be parsed together), which hints at a specific context but doesn't clarify use cases, prerequisites, or exclusions. Without explicit when/when-not instructions or named alternatives, it scores low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_work_item_descriptionScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'get_work_item_description' has a clear and distinct purpose of retrieving work item details by ID.
The single tool name follows a consistent verb_noun pattern ('get_work_item_description'), and with only one tool, there is no inconsistency to evaluate. The naming is clear and predictable.
A server named 'MCP Workitem Server' suggests a domain of work item management, but with only one tool (get_work_item_description), it is too few for the apparent scope. This severely limits functionality, as agents cannot create, update, delete, or list work items, making it incomplete for typical workflows.
The tool set is severely incomplete for a work item management domain. It only provides a 'get' operation, missing essential CRUD/lifecycle coverage such as create, update, delete, and list operations. This will cause significant agent failures in handling work items effectively.
MCP server enabling AI agents to manage Bitrix24 features via standardized protocol
Remote MCP server for China brand visibility, destination demand, and KOL discovery workflows.
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
Tigris MCP Server seamlessly connects AI agents to Tigris bucket and object management.
