This MCP server provides secure remote execution and database query capabilities for AI copilot tools through policy-controlled SSH and PostgreSQL connections.
Core capabilities:
Execute SSH commands - Run commands on remote servers through configured profiles with command allowlists, output quotas, execution timeouts, and concurrency limits
Query PostgreSQL databases - Execute SQL queries with statement pattern restrictions, row limits, and execution time constraints
Train machine learning classifiers - Orchestrate classifier training jobs remotely using SSH profiles with customizable command templates and subclass iteration
Enforce security policies - All operations governed by command regex patterns, execution limits, and production mode enforcement
Manage credentials securely - Store secrets via environment variables, filesystem paths, or inline JSON with support for base64-encoded keys
Control concurrency - Limit simultaneous operations per profile with cancellation-aware execution and progress notifications
Test and debug - Built-in simulator and integration test suite for testing without external AI client tools
Integrate with AI Copilots - Connect to GitHub Copilot in VS Code, Cursor, or other MCP-compatible AI tools
Enables execution of database queries against PostgreSQL databases through RDBMS connections
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., "@Infer MCP Server run python train.py on training-cluster with dataset /data/images"
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.
This is an MCP (Model Context Protocol) server providing resource access via SSH and RDBMS connections. It is designed to integrate with AI Copilot tools like GitHub Copilot in VS Code and Cursor.
Install dependencies: npm install
Build: npm run build
Run: npm start
Related MCP server: MCP SSH Session
SSH command execution enforced through configured profiles, command allowlists, and output quotas
PostgreSQL database queries limited to configured connections and statement patterns
Per-profile concurrency limits with cancellation-aware execution and progress notifications
Classifier training orchestration via SSH profiles
The server loads configuration from either INFER_MCP_CONFIG_PATH (JSON file) or INFER_MCP_CONFIG (inline JSON string). A starter config is available at config/sample-config.json; copy .env.example to .env and update paths/secrets as needed.
Secrets can be provided inline, via environment variables, or read from disk. Example:
{
"sshProfiles": {
"training-cluster": {
"host": "cluster.example.com",
"username": "trainer",
"privateKey": {
"path": "./secrets/training-cluster.key"
},
"policy": {
"allowedCommands": ["^python\\s+train.py\\b"],
"maxExecutionMs": 900000,
"maxOutputBytes": 1048576
}
}
},
"databaseProfiles": {
"training-metadata": {
"connectionString": { "env": "TRAINING_METADATA_DB_URL" },
"allowedStatements": ["^\\s*SELECT\\b", "^\\s*WITH\\b"],
"maxRows": 1000,
"maxExecutionMs": 20000
}
},
"training": {
"defaultCommandTemplate": "python train.py --dataset={{datasetPath}} --class={{subclass}}",
"defaultTimeoutMs": 600000
}
}sshProfiles define reusable credentials for tools such as sshExecute and trainClassifier. For password, privateKey, or passphrase, supply either a raw string, { "env": "VAR_NAME" }, or { "path": "relative/or/absolute" }. Base64-encoded files are supported with { "path": "...", "encoding": "base64" }. Policies control command allowlists, maximum runtime, captured output size, and per-profile maxConcurrent slots. The sample config includes a local-test profile against 127.0.0.1 with placeholder credentials (tester / changeme) so you can quickly exercise SSH tooling via a local daemon—update these values before real use.
databaseProfiles centralise PostgreSQL access. Statements must match the configured regex allowlists and respect row/time limits, with maxConcurrent restricting simultaneous queries per profile.
training controls defaults for classifier jobs.
Configure in your AI tool's MCP settings to connect to this server.
For VS Code GitHub Copilot: Add to mcp.json in .vscode folder.
You can debug this MCP server using VS Code's debugger.
Build the project (npm run build) and use the simulator to exercise tools locally without an agent client:
npm run simulate -- list
npm run simulate -- call sshExecute '{"profile":"training-cluster","command":"python train.py --help"}'
npm run simulate -- call dbQuery '{"profile":"training-metadata","query":"SELECT * FROM jobs LIMIT 5"}'Override defaults with environment variables:
MCP_SERVER_COMMAND – binary to launch (default node)
MCP_SERVER_ARGS – comma-separated arguments (default build/index.js)
MCP_SERVER_CWD – working directory for the spawned server
For staging validation, copy config/staging-config.json, populate the referenced secrets, and set INFER_MCP_CONFIG_PATH=$(pwd)/config/staging-config.json before running npm run simulate -- … commands. For quick localhost smoke-tests, aim INFER_MCP_CONFIG_PATH at config/sample-config.json, ensure your SSH server accepts the local-test credentials, or tweak that profile to match an existing local account. The server runs in permissive local-test mode by default; set INFER_MCP_MODE=production to re-enable SSH policy enforcement for the loopback profile when you deploy.
Build the project (npm run build) so the simulator artifact exists.
Configure staging credentials via INFER_MCP_CONFIG_PATH or INFER_MCP_CONFIG (the staging sample references environment variables and secret files under config/secrets/).
Run npm run test:integration to execute Vitest suites that shell out to the simulator (guarded by INTEGRATION=1).
The integration suite expects the simulator to list sshExecute, dbQuery, and trainClassifier; extend tests/integration/ with additional cases as you add tools.
Execute a SQL query on a PostgreSQL database using a configured profile
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes | Database profile to use | |
| query | Yes | SQL query to execute | |
| parameters | No | Positional parameters for the query | |
| timeoutMs | No | Query timeout in milliseconds | |
| rowLimit | No | Override maximum number of rows to return |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| rowCount | Yes | |
| truncated | Yes | |
| durationMs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'execute a SQL query' which implies read/write operations but doesn't disclose behavioral traits like whether it supports transactions, what happens with DDL vs DML queries, error handling, or security implications. For a database tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the core functionality, making it easy for an agent to quickly understand what the tool does.
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?
Given the tool has 5 parameters, no annotations, but does have an output schema (which means return values are documented elsewhere), the description is minimally adequate. It covers the basic purpose but lacks behavioral context and usage guidance that would be helpful for a database operation tool. The existence of an output schema reduces the need to explain return values, but other gaps remain.
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%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (profile, query, parameters, timeoutMs, rowLimit). Baseline 3 is appropriate when the schema does the heavy lifting, though the description could have explained parameter relationships or constraints.
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 action ('Execute a SQL query') and target resource ('PostgreSQL database using a configured profile'), providing specific verb+resource combination. However, it doesn't differentiate from sibling tools like sshExecute or trainClassifier, which operate on different systems entirely, so it doesn't need sibling differentiation but could mention it's for database operations specifically.
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 doesn't mention when this tool is appropriate (e.g., for database queries vs. other operations) or when not to use it (e.g., for non-SQL operations). With sibling tools like sshExecute for shell commands and trainClassifier for ML tasks, some basic differentiation would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a command on a remote server via SSH using a configured profile
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes | SSH credential profile to use | |
| command | Yes | Command to execute | |
| cwd | No | Working directory on remote host | |
| env | No | Environment variables for the command | |
| timeoutMs | No | Execution timeout in milliseconds | |
| maxOutputBytes | No | Maximum bytes to capture from stdout/stderr |
| Name | Required | Description |
|---|---|---|
| signal | No | |
| stderr | Yes | |
| stdout | Yes | |
| exitCode | Yes | |
| truncated | Yes | |
| durationMs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action. It fails to mention critical aspects like security implications, permission requirements, potential side effects (e.g., command execution risks), or error handling, which are essential for a tool that executes commands remotely.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand quickly.
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?
Given the tool's complexity (remote command execution with 6 parameters) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks details on behavioral traits and usage guidelines, which are crucial for safe and effective use, leaving gaps 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 schema description coverage is 100%, so the schema fully documents all parameters. The description does not add any additional meaning or context beyond what the schema provides, such as examples or usage notes for parameters like 'profile' or 'timeoutMs'.
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 specific action ('Execute a command') and resource ('on a remote server via SSH using a configured profile'), distinguishing it from sibling tools like dbQuery and trainClassifier which involve database operations and machine learning tasks respectively.
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?
No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description lacks context about suitable scenarios or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run classifier training commands on a remote host via SSH
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes | Credential profile for SSH access | |
| subclasses | Yes | List of subclasses to train | |
| datasetPath | Yes | Remote dataset path | |
| commandTemplate | No | Command template to run on the remote host; overrides configuration if provided | |
| timeoutMs | No | Optional timeout per subclass execution in milliseconds | |
| dryRun | No | If true, render commands without executing them |
| Name | Required | Description |
|---|---|---|
| job | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions remote execution via SSH but lacks critical details: whether this is a read-only or destructive operation (training typically modifies models), authentication requirements beyond the 'profile' parameter, potential side effects (e.g., file system changes on remote host), rate limits, or error handling. The description is insufficient for a mutation tool with zero annotation coverage.
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, efficient sentence that front-loads the core purpose without unnecessary elaboration. Every word earns its place by specifying the action, target, and mechanism concisely.
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?
Given the tool's complexity (remote execution, 6 parameters, mutation likely required for training) and the presence of an output schema (which reduces need to describe return values), the description is minimally adequate. However, with no annotations and a mutation-oriented task, it should provide more behavioral context (e.g., safety warnings, prerequisites) to be fully 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?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between parameters like how 'commandTemplate' interacts with 'subclasses'). Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('Run classifier training commands') and the mechanism ('on a remote host via SSH'), which is specific and actionable. It distinguishes from sibling tools like 'sshExecute' by focusing specifically on classifier training rather than general SSH execution. However, it doesn't explicitly differentiate from 'dbQuery' beyond the SSH context.
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 like 'sshExecute' or 'dbQuery'. It doesn't mention prerequisites (e.g., SSH setup, classifier framework availability), nor does it specify scenarios where this tool is preferred over general SSH execution for training tasks.
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. Dates show when Glama detected each change.
v1.0.0dbQuery10 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / connectionStringRemoved value: -{
- "description": "Database connection string",
- "type": "string"
-}Input schema / properties / parametersAdded value: +{
+ "description": "Positional parameters for the query",
+ "items": {},
+ "type": "array"
+}Input schema / properties / profileAdded value: +{
+ "description": "Database profile to use",
+ "type": "string"
+}Input schema / properties / query / minLengthAdded value: +1Input schema / properties / rowLimitAdded value: +{
+ "description": "Override maximum number of rows to return",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+}Input schema / properties / timeoutMsAdded value: +{
+ "description": "Query timeout in milliseconds",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+}Input schema / requiredPrevious value: -[
- "connectionString",
- "query"
-]New value: +[
+ "profile",
+ "query"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "durationMs": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "rowCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "rows": {
+ "items": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "truncated": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "rows",
+ "rowCount",
+ "truncated",
+ "durationMs"
+ ],
+ "type": "object"
+}sshExecute14 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / command / minLengthAdded value: +1Input schema / properties / cwdAdded value: +{
+ "description": "Working directory on remote host",
+ "type": "string"
+}Input schema / properties / envAdded value: +{
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "Environment variables for the command",
+ "type": "object"
+}Input schema / properties / hostRemoved value: -{
- "description": "SSH host",
- "type": "string"
-}Input schema / properties / maxOutputBytesAdded value: +{
+ "description": "Maximum bytes to capture from stdout/stderr",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+}Input schema / properties / passwordRemoved value: -{
- "description": "SSH password",
- "type": "string"
-}Input schema / properties / portRemoved value: -{
- "default": 22,
- "description": "SSH port",
- "type": "number"
-}Input schema / properties / profileAdded value: +{
+ "description": "SSH credential profile to use",
+ "type": "string"
+}Input schema / properties / timeoutMsAdded value: +{
+ "description": "Execution timeout in milliseconds",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+}Input schema / properties / usernameRemoved value: -{
- "description": "SSH username",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "host",
- "username",
- "password",
- "command"
-]New value: +[
+ "profile",
+ "command"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "durationMs": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "exitCode": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "signal": {
+ "type": "string"
+ },
+ "stderr": {
+ "type": "string"
+ },
+ "stdout": {
+ "type": "string"
+ },
+ "truncated": {
+ "additionalProperties": false,
+ "properties": {
+ "stderr": {
+ "type": "boolean"
+ },
+ "stdout": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "stdout",
+ "stderr"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "stdout",
+ "stderr",
+ "truncated",
+ "exitCode",
+ "durationMs"
+ ],
+ "type": "object"
+}trainClassifier3 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "job": {
+ "additionalProperties": false,
+ "properties": {
+ "commandTemplate": {
+ "type": "string"
+ },
+ "completedAt": {
+ "type": "string"
+ },
+ "datasetPath": {
+ "type": "string"
+ },
+ "profile": {
+ "type": "string"
+ },
+ "startedAt": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "succeeded",
+ "failed",
+ "cancelled"
+ ],
+ "type": "string"
+ },
+ "tasks": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "command": {
+ "type": "string"
+ },
+ "completedAt": {
+ "type": "string"
+ },
+ "dryRun": {
+ "type": "boolean"
+ },
+ "error": {
+ "type": "string"
+ },
+ "logs": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "at": {
+ "type": "string"
+ },
+ "context": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "level": {
+ "enum": [
+ "info",
+ "warn",
+ "error"
+ ],
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "level",
+ "message",
+ "at"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "durationMs": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "exitCode": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "signal": {
+ "type": "string"
+ },
+ "stderr": {
+ "type": "string"
+ },
+ "stdout": {
+ "type": "string"
+ },
+ "truncated": {
+ "additionalProperties": false,
+ "properties": {
+ "stderr": {
+ "type": "boolean"
+ },
+ "stdout": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "stdout",
+ "stderr"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "stdout",
+ "stderr",
+ "truncated",
+ "exitCode",
+ "durationMs"
+ ],
+ "type": "object"
+ },
+ "startedAt": {
+ "type": "string"
+ },
+ "status": {
+ "$ref": "#/properties/job/properties/status"
+ },
+ "subclass": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "subclass",
+ "command",
+ "dryRun",
+ "status",
+ "logs"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "profile",
+ "datasetPath",
+ "commandTemplate",
+ "status",
+ "startedAt",
+ "tasks"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "job"
+ ],
+ "type": "object"
+}dbQuerysshExecutetrainClassifierEach tool has a clearly distinct purpose: dbQuery handles SQL queries on PostgreSQL, sshExecute runs general commands via SSH, and trainClassifier specifically trains classifiers via SSH. There is no overlap in functionality, making tool selection unambiguous for an agent.
The naming is mixed: dbQuery and sshExecute follow a verb_noun pattern, but trainClassifier uses a verb_noun format without underscore separation. While readable, this inconsistency in convention (snake_case vs. camelCase) reduces predictability across the set.
With only 3 tools, the server feels thin for a general-purpose 'Infer MCP Server' that spans database queries, SSH execution, and machine learning tasks. This limited set may not adequately cover the implied scope, leaving gaps in related operations.
The tool surface is severely incomplete for the inferred domain of data and remote operations. There are no tools for database management (e.g., create/update tables), SSH file operations, or classifier evaluation/deployment, creating significant gaps that will hinder agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
PostgreSQL, MySQL, OpenAPI/Swagger, and shared Agent Memory with scoped access.
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Validates AI infra code on real VMs. Self-corrects until it works. No containers, no sandboxes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jackyxhb/InferMCPServer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
