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., "@Transporeon Company Settings MCP Server list all settings for company 273471 in pd"
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 that provides intelligent access to Transporeon's internal company settings API. This server enables AI assistants to retrieve, search, and analyze company configuration settings across different environments with smart pagination and search capabilities.
β οΈ Internal Use Only: This server is designed exclusively for internal Transporeon use and requires VPN access to internal network resources.
π Smart Search: Find specific content within large configuration files with line numbers and context
π Line-Based Pagination: Navigate through large settings efficiently using line ranges
π― Multi-Environment Support: Access settings across Production, Integration, and Acceptance environments
π Secure Authentication: Bearer token authentication with automatic encoding/decoding
β‘ Intelligent Processing: Automatic base64 decoding and XML formatting for readability
π Comprehensive Filtering: Filter by setting type, owner, and child objects
Related MCP server: commercetools Commerce MCP
Node.js 18 or higher
VPN access to Transporeon internal network
Valid API tokens for PD, AC, IN
Podman Desktop
Cursor IDE or any MCP-compatible client
Clone the repository
git -c http.sslVerify=false clone https://github.com/larkinmaxim/mcp_customer_settings_http.gitRun the secure setup script
# If execution policy prevents running scripts, first enable it:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
# Navigate to project directory
cd mcp_customer_settings_http
# Run secure containerized setup
.\Secure-Setup.ps1The secure setup script will:
β Securely collect API tokens (with input masking)
β Create Podman secrets (encrypted token storage)
β Build hardened container (non-root, read-only filesystem)
β Deploy with security best practices
β Test deployment and token validation
Available options:
.\Secure-Setup.ps1 # Full secure setup
.\Secure-Setup.ps1 -TokensOnly # Rotate API tokens only
.\Secure-Setup.ps1 -BuildOnly # Build container only
.\Secure-Setup.ps1 -DeployOnly # Deploy existing container
.\Secure-Setup.ps1 -Clean # Clean then full setupInstall dependencies
npm installBuild the project
npm run buildConfigure Cursor
For containerized deployment (recommended):
{
"mcpServers": {
"company-settings": {
"url": "http://localhost:3001/mcp"
}
}
}Security Note: The containerized approach is strongly recommended as it keeps tokens secure in Podman secrets rather than in configuration files.
Once configured, the MCP server provides these tools to AI assistants:
// Get all settings for a company with optional filtering
list_company_settings({
companyId: 273471,
environment: "pd",
type: "COMPANY"
})// Get lines 1667-1700 of a specific setting
get_company_setting({
companyId: 273471,
keyName: "tsmConfig",
environment: "pd",
offset: 1666, // Start from line 1667 (0-based)
limit: 34 // Get 34 lines (1667-1700)
})// Find all occurrences of "otherTruckSize" with context
search_in_setting({
companyId: 273471,
keyName: "tsmConfig",
searchTerm: "otherTruckSize",
contextLines: 3
})Smart Authentication: Secure bearer token authentication with automatic validation
Intelligent Decoding: Automatically detects and decodes base64-encoded settings
Line-Based Navigation: Navigate large XML configurations using line numbers from search results
Context-Aware Search: Find content with surrounding lines for better understanding
pd - Production (default)
in - Integration
ac - Acceptance
The MCP server requires separate tokens for each environment:
TP_SETTINGS_TOKEN_PD - Production environment token
TP_SETTINGS_TOKEN_IN - Integration environment token
TP_SETTINGS_TOKEN_AC - Acceptance environment token
All three environment tokens must be provided for the server to function properly.
For routine token maintenance, use the secure token rotation feature:
# Rotate all API tokens without rebuilding container
.\Secure-Setup.ps1 -TokensOnlyThis will prompt for new tokens and update them securely without interrupting service for longer than a container restart.
# Run TypeScript compiler in watch mode
npm run dev
# Start the server directly
npm startmcp_customer_settings_http/
βββ src/
β βββ index.ts # MCP server wiring and request handlers
β βββ handlers.ts # Tool implementations
β βββ settingsClient.ts # API client and business logic
β βββ toolSchemas.ts # Tool schemas exposed to MCP
β βββ config.ts # Configuration management
β βββ constants.ts # Application constants
β βββ types.ts # TypeScript interfaces
βββ dist/ # Compiled JavaScript (generated)
βββ Documentation/ # Project documentation
βββ package.json
βββ tsconfig.json
βββ README.mdnpm run build - Compile TypeScript to JavaScript
npm start - Run the compiled server
npm run dev - Development mode with watch
npm run clean - Remove compiled files
VPN Required: This server only works within the Transporeon internal network
Bearer Token: Secure API token authentication required
Internal Use: Designed exclusively for Transporeon employees and authorized personnel
Network Isolation: API endpoints are not accessible from the public internet
Internal API only - not guaranteed to be stable
May have incompatible changes without notice
Rate limiting may apply
Use line-based pagination for large settings (limit + offset)
Search first to find relevant line numbers, then use pagination to get specific ranges
Line numbers from search results can be used directly with pagination offset
Verify VPN connection is active
Check if you can access Transporeon admin dashboard
Try different environments (pd, in, ac)
For containerized deployment:
# Check if tokens are properly configured in secrets
podman secret ls | findstr tp_token
# Test tokens manually
podman exec transporeon-mcp node -e "const { verifyEnvironmentTokens } = require('./dist/handlers.js'); verifyEnvironmentTokens().then(console.log).catch(console.error);"
# Rotate tokens if needed
.\Secure-Setup.ps1 -TokensOnlyFor manual installation:
Ensure all three environment token variables are set: TP_SETTINGS_TOKEN_PD, TP_SETTINGS_TOKEN_IN, TP_SETTINGS_TOKEN_AC
Verify tokens have necessary permissions for respective environments
Check token expiration with system administrators
Token Rotation Errors:
# If container is not running, start it first
podman ps --filter name=transporeon-mcp
podman start transporeon-mcp # if not running
# Then rotate tokens
.\Secure-Setup.ps1 -TokensOnlyContainer Issues:
# Check container logs
podman logs transporeon-mcp --tail 50
# Restart container
podman restart transporeon-mcp
# Full redeployment if needed
.\Secure-Setup.ps1 -CleanVerify company ID is correct
Check if setting exists in the specified environment
Ensure correct setting key name format
Use pagination for large settings (limit < 50 lines recommended)
Search for specific content instead of retrieving entire settings
Consider using different environments if one is slow
API Issues: Contact the Company Settings API maintainer
Network Access: Contact Transporeon IT for VPN access and network configuration
Token Management: Contact system administrators for API token issues
MCP Issues: Check the main project documentation or development team
MIT
Get a specific company setting by key name. Returns the setting with decoded value if it was encoded.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional: Filter by setting type (defaults to COMPANY) | |
| limit | No | Optional: Limit the number of lines returned (useful for very long settings) | |
| owner | No | Optional: Filter by owner ID | |
| offset | No | Optional: Number of lines to skip from the beginning (for pagination) | |
| keyName | Yes | Setting key name to retrieve | |
| companyId | Yes | Company ID (integer) | |
| childObject | No | Optional: Filter by child object ID | |
| environment | No | Environment: pd (default), in, or ac | pd |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It adds a useful behavioral detail: 'Returns the setting with decoded value if it was encoded.' However, it does not mention error handling, authentication requirements, or how pagination parameters affect results, leaving room for more disclosure.
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?
The description is a single, well-structured sentence with no redundant information. It efficiently conveys the core action and a key behavior.
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?
For a simple get tool, the description covers the essential intent and the decoding behavior. No output schema is provided, so the return value is only vaguely described as 'the setting,' but the parameter schema handles the optional fields. It could further clarify the purpose of offset/limit for line-based settings, but overall it's reasonably complete.
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?
The input schema already covers all 8 parameters with descriptions, so the baseline is 3. The description adds no extra parameter meaning beyond naming the key; it doesn't elaborate on optional filters like type, owner, or environment.
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?
The description clearly states the tool's function: 'Get a specific company setting by key name.' It uses a specific verb ('Get'), identifies the resource ('company setting'), and narrows scope ('specific... by key name'), which distinguishes it from sibling tools like list_company_settings and search_in_setting.
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?
The phrase 'specific... by key name' implies the tool is for retrieving a single known setting, but it does not explicitly mention when to use it instead of list or search alternatives. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all company settings from the Transporeon settings API. Returns settings formatted as Markdown with decoded values for encoded settings.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional: Filter by setting type | |
| owner | No | Optional: Filter by owner ID | |
| keyName | No | Optional: Filter by specific setting key name | |
| companyId | Yes | Company ID (integer) | |
| childObject | No | Optional: Filter by child object ID | |
| environment | No | Environment: pd (default), in, or ac | pd |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the output is formatted as Markdown and that encoded settings are decoded, which adds useful behavioral context. However, it does not mention whether pagination occurred, potential large payloads, read-only implications, or any other caveats, leaving some behavioral aspects undisclosed.
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?
The description is concise, two short sentences, front-loaded with the action, and contains no extraneous words. Every sentence adds value.
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?
The description adequately covers the core purpose and return format for a simple list tool, especially given the rich schema. It states the output is Markdown with decoded values, which is enough given no output schema. However, it does not mention potential issues like large result sets or any limitations (e.g., inability to filter without optional params), but the schema offsets this. Overall, it is nearly complete for a list operation.
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?
Schema description coverage is 100%, with all six parameters having clear descriptions including enums and defaults. The description adds no extra per-parameter meaning, so the schema already does the heavy lifting. The global mention of decoding does not clarify parameter usage.
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?
The description clearly states the tool lists company settings from the Transporeon settings API, using the specific verb 'list' and a clear resource. It also mentions the return format (Markdown with decoded values). However, it does not explicitly differentiate from sibling tools like get_company_setting or search_in_setting, though the name and 'all' hint at a broader scope.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that get_company_setting should be used for a single setting or search_in_setting for searching. No exclusions, prerequisites, or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for specific text within a company setting and return matching lines with surrounding context.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional: Filter by setting type (defaults to COMPANY) | |
| owner | No | Optional: Filter by owner ID | |
| keyName | Yes | Setting key name to search within | |
| companyId | Yes | Company ID (integer) | |
| searchTerm | Yes | Text to search for within the setting value | |
| childObject | No | Optional: Filter by child object ID | |
| environment | No | Environment: pd (default), in, or ac | pd |
| contextLines | No | Number of lines before and after each match to include (default: 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns matching lines with surrounding context, which is useful. However, it omits details like case sensitivity, search pattern semantics (exact vs. substring), and behavior when no matches are found. This is a moderate level of transparency for a read-like search tool.
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?
The description is a single sentence that is direct and front-loaded with the action and target. It contains no fluff or redundant information, making it highly concise.
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?
The tool has 8 parameters and no output schema, so the description needs to provide enough context. It states the core purpose but doesn't explain how optional filters (type, owner, childObject, environment) narrow the search, nor does it describe the output structure beyond 'matching lines with context.' The schema covers parameter details, but the description could offer more cohesive guidance for this multi-parameter search tool.
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?
The input schema has 100% coverage for all 8 parameters, so the baseline is 3. The description's mention of 'surrounding context' aligns with the contextLines parameter but does not add new meaning beyond the schema's own descriptions. No additional parameter semantics are provided.
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?
The description clearly states the tool's function with a specific verb ('search') and resource ('company setting'), and mentions returning matching lines with context. This distinguishes it from siblings like list_company_settings and get_company_setting, which have different purposes (listing vs. retrieving full settings).
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?
The description implies the tool is used when you need to find specific text within a setting's value, which is a clear use case. However, it does not explicitly say when to use this instead of alternatives, such as get_company_setting for full retrieval. The sibling names provide context, but no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that all environment tokens (pd, in, ac) are valid by making test requests to each environment. This helps diagnose authentication issues.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions making test requests, which implies network calls, but doesn't disclose side effects, rate limits, required permissions, or how results are returned. The behavior on invalid tokens or failure is also unspecified, leaving significant gaps.
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?
The description is two sentences, front-loaded with the action, and every word adds value. It's efficient and well-structured without unnecessary detail.
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?
For a zero-parameter diagnostic tool, the description is fairly complete: it states what it does and why to use it. However, without an output schema or annotations, it could still mention the format or meaning of verification results, leaving a small gap in completeness.
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?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter information because none is needed, and the baseline for 0-param tools is 4, which is appropriate here.
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?
The description clearly states the tool's function: verifying environment tokens (pd, in, ac) by making test requests. This distinguishes it from sibling tools like list_company_settings, which target company settings, making the purpose unambiguous.
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?
The description provides clear context by stating the tool 'helps diagnose authentication issues,' implying it should be used for troubleshooting auth problems. However, it doesn't explicitly mention when not to use it or compare to alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: listing all settings, retrieving a specific setting, searching within a setting, and verifying environment tokens. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern in snake_case (list_company_settings, get_company_setting, search_in_setting, verify_environment_tokens). The naming is predictable and readable.
With 4 tools, the set is well-scoped for a company settings server. Each tool covers a necessary operation without redundancy, and the count is within the ideal range.
The tool set covers the full lifecycle of reading and searching company settings, plus a diagnostic tool for environment tokens. No obvious missing operations are apparent for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
CompanyLens is a remote MCP server giving AI agents instant access to official company registry data across 19 jurisdictions in Europe, the Americas, and Asia-Pacific. Eighteen read-only tools let you search companies and people, look up officers and beneficial owners, map corporate networks through shared directors, screen names against the UK disqualified directors register, find every company at a registered address, and pull filing history β all from a single connector. Visit our website: https://companylens.io
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
Shared, permission-aware company context for AI agents, with provenance, approvals and audit.
Agent-native API for Finnish public company data via YTJ. Pay-per-call $0.01 USDC over x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/larkinmaxim/mcp_customer_settings_http'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
