Eine Model Context Protocol (MCP)-Serverimplementierung für den Zugriff auf eRegulations-API-Daten. Dieser Server bietet strukturierten, KI-freundlichen Zugriff auf eRegulations-Instanzen und erleichtert KI-Modellen die Beantwortung von Benutzerfragen zu Verwaltungsverfahren.
Zugriff auf eRegulations-Daten über ein standardisiertes Protokoll
Abfrageverfahren, Schritte, Voraussetzungen und Kosten
MCP-Eingabeaufforderungsvorlagen zur Anleitung der LLM-Tool-Nutzung
Optimierte Implementierung durch Standard-E/A-Verbindungen
Related MCP server: MCP Boilerplate
Die empfohlene Methode zum Ausführen des Servers ist die Verwendung des veröffentlichten Docker-Images aus dem GitHub Container Registry (GHCR). Dies gewährleistet eine konsistente und isolierte Umgebung.
# 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-serverErsetzen Sie https://your-eregulations-api.com durch die tatsächliche Basis-URL der eRegulations-Instanz, mit der Sie eine Verbindung herstellen möchten (z. B. https://api-tanzania.tradeportal.org ).
Der Server wartet auf MCP-JSON-Anfragen auf der Standardeingabe und sendet Antworten an die Standardausgabe.
Hier ist ein Beispiel, wie ein Client (wie Claude) konfiguriert werden könnte, um diesen Server über Docker zu verwenden:
{
"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"
}
}
}
}(Denken Sie daran, auch den Wert EREGULATIONS_API_URL im Abschnitt env zu ersetzen.)
Alternativ können Sie den Server mit Smithery installieren und ausführen:
Besuchen Sie https://smithery.ai/server/@unctad-ai/eregulations-mcp-server für den Installationsbefehl.
~~Das direkte Ausführen des Servers mit npx wird aufgrund potenzieller Umgebungsinkonsistenzen nicht mehr empfohlen.~~
~~```bash
export EREGULATIONS_API_URL= https://example.com/api && export NODE_ENV=Produktion && 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.
