用于访问 eRegulations API 数据的模型上下文协议 (MCP) 服务器实现。该服务器提供结构化、AI 友好的 eRegulations 实例访问，使 AI 模型能够更轻松地回答用户关于行政流程的问题。
通过标准化协议访问电子法规数据
查询流程、步骤、要求和费用
MCP 提示模板用于指导 LLM 工具的使用
使用标准 I/O 连接简化实施
Related MCP server: MCP Boilerplate
推荐使用 GitHub 容器注册表 (GHCR) 中发布的 Docker 镜像来运行服务器。这可以确保环境的一致性和隔离性。
# Pull the latest image (optional)
docker pull ghcr.io/unctad-ai/eregulations-mcp-server:latest
# Run the server, providing the target eRegulations API URL
export EREGULATIONS_API_URL="https://your-eregulations-api.com"
docker run -i --rm -e EREGULATIONS_API_URL ghcr.io/unctad-ai/eregulations-mcp-server将https://your-eregulations-api.com替换为您要连接到的 eRegulations 实例的实际基本 URL（例如， https://api-tanzania.tradeportal.org ）。
服务器在标准输入上监听 MCP JSON 请求并将响应发送到标准输出。
下面是如何配置客户端（如 Claude）以通过 Docker 使用该服务器的示例：
{
"mcpServers": {
"eregulations": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"EREGULATIONS_API_URL",
"ghcr.io/unctad-ai/eregulations-mcp-server:latest"
],
"env": {
"EREGULATIONS_API_URL": "https://your-eregulations-api.com"
}
}
}
}（记住也要替换env部分中的EREGULATIONS_API_URL值。）
或者，您可以使用 Smithery 安装并运行服务器：
访问https://smithery.ai/server/@unctad-ai/eregulations-mcp-server获取安装命令。
~~由于潜在的环境不一致，直接使用npx运行服务器已被弃用。~~
~~```bash
导出 EREGULATIONS_API_URL= https://example.com/api && 导出 NODE_ENV=production && npx -y @unctad-ai/eregulations-mcp-server@latest
## Configuration
The server requires the URL of the target eRegulations API.
### Environment Variables
- `EREGULATIONS_API_URL`: **(Required)** URL of the eRegulations API to connect to (e.g., `https://api-tanzania.tradeportal.org`). Passed to the Docker container using the `-e` flag.
## Available Tools
The MCP server provides the following tools:
### `listProcedures`
Lists all available procedures in the eRegulations system.
### `getProcedureDetails`
Gets detailed information about a specific procedure by its ID.
Parameters:
- `procedureId`: ID of the procedure to retrieve
### `getProcedureStep`
Gets information about a specific step within a procedure.
Parameters:
- `procedureId`: ID of the procedure
- `stepId`: ID of the step within the procedure
### `searchProcedures`
Searches for procedures by keyword or phrase. Note: This currently searches related objectives based on the underlying API and may include results beyond direct procedure names.
Parameters:
- `keyword`: The keyword or phrase to search for
## Prompt Templates
The server provides prompt templates to guide LLMs in using the available tools correctly. These templates explain the proper format and parameters for each tool. LLM clients that support the MCP prompt templates capability will automatically receive these templates to improve their ability to work with the API.
## Development
```bash
# Run in development mode
npm run start
# Run tests
npm test
# Run tests with watch mode
npm run test:watch
# Run test client
npm run test-client
```| Name | Required | Description | Default |
|---|---|---|---|
| procedureId | Yes | ID of the procedure to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| procedureId | Yes | ID of the procedure | |
| stepId | Yes | ID of the step within the procedure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | The keyword or phrase to search for procedures. This will be wrapped in a JSON object with a 'keyword' property when sent to the API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.0getProcedureDetailsgetProcedureSteplistProceduressearchProceduresScored across 4 tools
The tools have overlapping purposes focused on procedures, but their names suggest distinct functions: getProcedureDetails likely retrieves comprehensive information, getProcedureStep targets specific steps, listProcedures enumerates procedures, and searchProcedures finds them based on criteria. Without descriptions, some ambiguity remains about the exact boundaries between getProcedureDetails and getProcedureStep, but the naming provides reasonable differentiation.
All tool names follow a consistent verb_noun pattern with camelCase styling: getProcedureDetails, getProcedureStep, listProcedures, and searchProcedures. The verbs (get, list, search) are clear and appropriate, and the noun 'Procedures' is consistently used, making the naming highly predictable and readable.
With 4 tools, the count is reasonable for a server focused on regulations or procedures, as it covers key operations like listing, searching, and retrieving details. It might be slightly thin if more complex actions (e.g., create, update, delete) are needed for the domain, but for a read-only or query-focused interface, it is well-scoped and manageable.
The tool set provides good read/search coverage for procedures, including listing, searching, and getting details/steps, which suggests a query-oriented domain. However, there are notable gaps: no create, update, or delete tools imply a read-only surface, which might be intentional but limits agent workflows if modifications are needed. Without descriptions, it's unclear if this is by design or an omission.
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for Studex tools, notifications, and profile integrations
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
