eRegulations API 데이터 액세스를 위한 모델 컨텍스트 프로토콜(MCP) 서버 구현입니다. 이 서버는 eRegulations 인스턴스에 대한 구조화되고 AI 친화적인 액세스를 제공하여 AI 모델이 행정 절차에 대한 사용자 질문에 더 쉽게 답변할 수 있도록 합니다.
표준화된 프로토콜을 통해 eRegulations 데이터에 액세스하세요
쿼리 절차, 단계, 요구 사항 및 비용
LLM 도구 사용을 안내하는 MCP 프롬프트 템플릿
표준 I/O 연결을 사용한 간소화된 구현
Related MCP server: MCP Boilerplate
서버를 실행하는 데 권장되는 방법은 GitHub 컨테이너 레지스트리(GHCR)에서 게시된 Docker 이미지를 사용하는 것입니다. 이렇게 하면 일관되고 격리된 환경이 보장됩니다.
지엑스피1
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 사용하여 서버를 직접 실행하는 것은 환경 불일치 가능성으로 인해 더 이상 사용되지 않습니다.~~
~~```배쉬
EREGULATIONS_API_URL= https://example.com/api && export 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.
