The eRegulations MCP Server provides structured, AI-friendly access to administrative procedures data via the Model Context Protocol (MCP).
You can:
List all available procedures in the eRegulations system
Get detailed information about a specific procedure by its ID
Retrieve information about specific steps within a procedure
Search for procedures using keywords
Utilize predefined prompt templates that guide AI models in correctly using the server's tools
Enables deployment of the MCP server using Docker Compose for containerized setup and management.
Supports version control for cloning and managing the eRegulations MCP server codebase.
Provides integration for cloning the eRegulations MCP server repository from GitHub.
Facilitates installation of dependencies and project building through npm package management.
Click on "Install 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., "@eRegulations MCP Server what are the steps to register a business in Tanzania?"
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.
A Model Context Protocol (MCP) server implementation for accessing eRegulations API data. This server provides structured, AI-friendly access to eRegulations instances, making it easier for AI models to answer user questions about administrative procedures.
Access eRegulations data through a standardized protocol
Query procedures, steps, requirements, and costs
MCP prompt templates to guide LLM tool usage
Streamlined implementation using standard I/O connections
Related MCP server: MCP Boilerplate
The recommended way to run the server is using the published Docker image from the GitHub Container Registry (GHCR). This ensures a consistent and isolated environment.
# 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-serverReplace https://your-eregulations-api.com with the actual base URL of the eRegulations instance you want to connect to (e.g., https://api-tanzania.tradeportal.org).
The server listens for MCP JSON requests on standard input and sends responses to standard output.
Here's an example of how a client (like Claude) might be configured to use this server via 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"
}
}
}
}(Remember to replace the EREGULATIONS_API_URL value in the env section as well.)
Alternatively, you can install and run the server using Smithery:
Visit https://smithery.ai/server/@unctad-ai/eregulations-mcp-server for the installation command.
Running the server directly using npx is deprecated due to potential environment inconsistencies.
~~```bash
export 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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/unctad-ai/eregulations-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
