Implementación de un servidor de Protocolo de Contexto de Modelo (MCP) para acceder a los datos de la API de eRegulations. Este servidor proporciona acceso estructurado y optimizado para IA a las instancias de eRegulations, lo que facilita que los modelos de IA respondan a las preguntas de los usuarios sobre los procedimientos administrativos.
Acceda a los datos de eRegulations a través de un protocolo estandarizado
Consulta procedimientos, pasos, requisitos y costos
Plantillas de indicaciones de MCP para guiar el uso de la herramienta LLM
Implementación optimizada mediante conexiones de E/S estándar
Related MCP server: MCP Boilerplate
La forma recomendada de ejecutar el servidor es usar la imagen de Docker publicada desde el Registro de Contenedores de GitHub (GHCR). Esto garantiza un entorno consistente y aislado.
# 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-serverReemplace https://your-eregulations-api.com con la URL base real de la instancia de eRegulations a la que desea conectarse (por ejemplo, https://api-tanzania.tradeportal.org ).
El servidor escucha las solicitudes JSON de MCP en la entrada estándar y envía respuestas a la salida estándar.
A continuación se muestra un ejemplo de cómo se podría configurar un cliente (como Claude) para usar este servidor a través de 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"
}
}
}
}(Recuerde reemplazar también el valor EREGULATIONS_API_URL en la sección env ).
Alternativamente, puedes instalar y ejecutar el servidor usando Smithery:
Visite https://smithery.ai/server/@unctad-ai/eregulations-mcp-server para obtener el comando de instalación.
~~Ejecutar el servidor directamente usando npx está obsoleto debido a posibles inconsistencias del entorno.~~
~~```golpe
exportar EREGULATIONS_API_URL= https://ejemplo.com/api && exportar NODE_ENV=producción && 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.
