Skip to main content
Glama
AmirTlinov

PostgreSQL API SSH MCP Server

by AmirTlinov
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

SentryFrogg MCP Server

Русская версия • Docs • MCP configuration • Integration stack • Changelog

License: MIT Node.js >=18 CI

SentryFrogg is a stdio-based Model Context Protocol (MCP) server that gives LLM agents a production-grade toolbox for PostgreSQL, SSH (incl. SFTP), and HTTP. Use it when you want real infrastructure access without glue scripts: profiles, streaming pipelines, runbooks, and auditability are built in.

If you want your agent to move real data (API ↔ SFTP ↔ Postgres), run controlled SSH ops, and leave a traceable trail — this is the server.

Why SentryFrogg

  • One profile system across Postgres, SSH, and HTTP.

  • Streaming pipelines between HTTP, SFTP, and Postgres for large payloads.

  • Reliability primitives: retry/backoff, pagination, timeouts.

  • Runbooks + state for multi-step workflows and repeatable ops.

  • Intent layer with capability registry, previewed plans, and evidence bundles.

  • Observability with trace/span metadata and audit logs (redacted).

  • Encrypted local profile store (AES-256-GCM).

  • Safe-by-default local writes (no overwrite unless overwrite: true).

  • Optional unsafe local mode for full agent autonomy (local exec + filesystem).

Related MCP server: pg-mcp

Agent-first DX (quality-of-life)

  • help({ query }) supports keyword search across tools/actions/fields/aliases.

  • Typos get “did you mean” suggestions for tools, actions, and parameters.

  • Errors are typed and actionable (usually include a hint + minimal working example).

  • Safer defaults: secret redaction everywhere; “raw” secret export is opt-in and gated.

  • Long-running exec/SSH flows prefer explicit status/progress over “detached silence”.

Use cases

  • Sync or backfill data between APIs, SFTP drops, and PostgreSQL.

  • Run controlled remote operations via SSH with auditability.

  • Build repeatable incident runbooks for agents and operators.

Quick examples

Ingest JSONL into Postgres:

{
  "action": "run",
  "flow": "http_to_postgres",
  "http": { "url": "https://example.com/events.jsonl" },
  "postgres": { "profile_name": "default", "table": "events" },
  "format": "jsonl",
  "batch_size": 500
}

Export Postgres to SFTP:

{
  "action": "run",
  "flow": "postgres_to_sftp",
  "postgres": { "profile_name": "default", "table": "events" },
  "format": "csv",
  "sftp": { "profile_name": "default", "remote_path": "/tmp/events.csv", "overwrite": true }
}

Quick start

  1. Install: npm install

  2. Configure your MCP client (stdio):

    {
  "mcpServers": {
    "sentryfrogg": {
       "command": "node",
       "args": ["/absolute/path/to/dist/sentryfrogg_server.js"]
     }
   }
 }

    More details: mcp_config.md.

  3. Start: npm start

  4. In your MCP client: call help (try help({ query: "ssh exec" })), then profile_upsert for PostgreSQL/SSH

Tools

  • help

  • legend

  • mcp_workspace

  • mcp_jobs

  • mcp_artifacts

  • mcp_psql_manager

  • mcp_ssh_manager

  • mcp_api_client

  • mcp_repo

  • mcp_state

  • mcp_runbook

  • mcp_project

  • mcp_context

  • mcp_env

  • mcp_vault

  • mcp_capability

  • mcp_intent

  • mcp_evidence

  • mcp_alias

  • mcp_preset

  • mcp_audit

  • mcp_pipeline

  • mcp_local (unsafe, opt-in)

Short aliases are also available (e.g. sql/psql, ssh, api/http, repo, job, artifacts, workspace, intent, pipeline; plus local when unsafe mode is enabled).

Reference + examples: docs/tools.md.

Intent UX

  • Define capabilities in capabilities.json (override path via MCP_CAPABILITIES_PATH).

  • Context snapshots are stored in context.json (override path via MCP_CONTEXT_PATH).

  • mcp_intent compiles to a runbook plan, dry-run by default; write/mixed effects require apply: true.

  • Evidence bundles are stored under .sentryfrogg/evidence (override path via MCP_EVIDENCE_DIR).

Development

  • npm run check

  • npm test

  • npm run smoke (Docker) — see integration/README.md

Security

This server can execute SQL/SSH/HTTP by design. Run it only in environments you trust.

  • Vulnerability reporting: SECURITY.md

  • Public release checklist: PUBLIC_RELEASE_CHECKLIST.md

License

MIT — see LICENSE.

Available Tools

3 tools
mcp_api_clientB

🌐 API Client - безопасные HTTP запросы: get, post, put, delete, patch, check_api. Валидация URL, санитизация заголовков, защита от SSRF, ограничения размера данных.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesHTTP действие
auth_tokenNoBearer токен авторизации
dataNoДанные для POST/PUT/PATCH
headersNoHTTP заголовки
urlYesURL для запроса

TDQS

B3.2/5.0
Behavior3/5

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. It adds value by mentioning security features like URL validation, header sanitization, SSRF protection, and data size limits, which go beyond the input schema. However, it lacks details on error handling, response formats, or rate limits, leaving gaps in behavioral understanding for a tool with multiple parameters and no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and lists key features efficiently in a single sentence. It avoids unnecessary elaboration, but the inclusion of an emoji (🌐) and security details, while informative, slightly reduces conciseness. Overall, it's appropriately sized with minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a multi-method HTTP client with 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers security aspects and basic actions but lacks information on response handling, error scenarios, or integration context, which are important for an agent to use this tool effectively without structured output guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description doesn't add any specific meaning or usage details for parameters beyond what the schema provides, such as explaining 'check_api' or data formats. This meets the baseline for high schema coverage without extra param info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs 'безопасные HTTP запросы' (secure HTTP requests) with specific methods listed (get, post, put, delete, patch, check_api), making the verb+resource combination explicit. However, it doesn't distinguish this from sibling tools like mcp_psql_manager or mcp_ssh_manager, which handle different domains entirely, so differentiation isn't needed but the purpose remains clear without being tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 or in what contexts it's appropriate. It lists the actions available but doesn't specify prerequisites, when to choose one method over another, or any exclusions, leaving the agent without usage direction beyond the basic functionality.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_psql_managerC

🐘 PostgreSQL Manager - безопасные операции с базой данных: setup_profile, list_profiles, quick_query, show_tables, describe_table, sample_data, insert_data, update_data, delete_data, database_info. Шифрование AES-256-CBC, защита от SQL injection, валидация входных данных.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesДействие PostgreSQL
dataNoДанные для insert/update
databaseNoИмя базы данных
hostNoХост PostgreSQL
limitNoЛимит записей
passwordNoПароль PostgreSQL
portNoПорт PostgreSQL
profile_nameNoИмя профиля подключения (по умолчанию 'default')
sqlNoSQL запрос
table_nameNoИмя таблицы
usernameNoИмя пользователя PostgreSQL
whereNoWHERE условие

TDQS

C2.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It mentions security features (AES-256-CBC encryption, SQL injection protection, input validation) which are valuable behavioral disclosures. However, it doesn't describe mutation consequences (what gets deleted/updated), error handling, performance characteristics, or what happens when actions fail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise with two sentences, but the first sentence is overloaded with 10 action names. The security features are mentioned but not integrated with the tool's purpose. The emoji adds character but no functional value. The structure could be improved by separating action listing from security features.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 12 parameters, 10 possible actions, no annotations, and no output schema, the description is inadequate. It doesn't explain return formats, error conditions, or how different actions map to different parameter requirements. The security claims are mentioned but not contextualized within the tool's operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 12 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the 10 action values but doesn't explain which parameters are required for which actions or how they interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states this is a PostgreSQL Manager that performs 'безопасные операции с базой данных' (secure database operations) and lists 10 specific actions. It distinguishes from siblings by focusing on PostgreSQL database operations rather than API or SSH management. However, it doesn't specify what makes it a 'manager' versus just a PostgreSQL tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 the sibling tools (mcp_api_client, mcp_ssh_manager). It lists available actions but doesn't explain when to choose specific actions like 'quick_query' versus other query-related actions, or prerequisites for using the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_ssh_managerB

🔐 SSH Manager - безопасные SSH операции: setup_profile, list_profiles, execute, system_info, check_host. Защита от command injection, санитизация команд, ограничения безопасности.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesДействие SSH
commandNoКоманда для выполнения
hostNoХост SSH сервера
passwordNoПароль SSH
portNoПорт SSH
profile_nameNoИмя профиля подключения (по умолчанию 'default')
usernameNoИмя пользователя SSH

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It mentions security features like 'Защита от command injection, санитизация команд, ограничения безопасности' (protection against command injection, command sanitization, security restrictions), which adds valuable behavioral context beyond the basic action list. However, it doesn't cover other important behaviors like error handling, authentication requirements beyond password, or performance characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences: one stating the purpose and listing actions, another describing security features. It's front-loaded with the core functionality. The emoji and security details add value without excessive verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters, no annotations, and no output schema, the description provides basic purpose and security context but lacks important details. It doesn't explain return values, error conditions, or how different actions use different parameter subsets. The security mentions are helpful but insufficient for full understanding of this multi-action SSH tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema - it doesn't explain how parameters relate to different actions or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs 'SSH операции' (SSH operations) and lists specific actions like setup_profile, list_profiles, execute, system_info, check_host. It distinguishes from sibling tools (mcp_api_client, mcp_psql_manager) by focusing on SSH management, but doesn't explicitly differentiate within its own action types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 specific actions (e.g., when to use 'execute' vs 'system_info'), nor when to use this tool versus sibling tools. It mentions security features but doesn't explain their practical implications for usage decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedmcp_api_client
    • First observedmcp_psql_manager
    • First observedmcp_ssh_manager
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: mcp_api_client handles HTTP API requests, mcp_psql_manager manages PostgreSQL database operations, and mcp_ssh_manager performs SSH operations. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the task.

Naming Consistency5/5

All tool names follow a consistent pattern with the prefix 'mcp_' followed by a descriptive suffix (api_client, psql_manager, ssh_manager). This uniformity enhances readability and predictability across the tool set.

Tool Count3/5

With only 3 tools, the server feels thin for its broad purpose of handling PostgreSQL, API, and SSH operations. While each tool bundles related functions, the low count may limit granular control and could be expanded to better cover the domain's scope.

Completeness4/5

The tools provide comprehensive coverage for their respective domains: API client supports common HTTP methods, PostgreSQL manager includes essential CRUD operations and database management, and SSH manager covers key remote execution tasks. Minor gaps might exist, such as advanced API features or SSH file transfers, but core workflows are well-covered.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Terminal MCP Server

    weidwonder
    A
    license
    B
    quality
    F
    maintenance
    An MCP server that allows AI models to execute system commands on local machines or remote hosts via SSH, supporting persistent sessions and environment variables.
    1
    36
    28
    MIT

  • pg-mcp

    stuzero
    F
    license
    Not graded
    quality
    D
    maintenance
    PG-MCP is an HTTP server implementation that enables AI systems to interact with PostgreSQL databases via MCP, providing tools for querying, connecting to multiple databases, and exploring schema resources. The system enriches context by extracting table/column description from database catalogs.
    27
    -

  • Zaturn

    kdqed
    A
    license
    A
    quality
    C
    maintenance
    An open-source MCP server that connects to various data sources (SQL databases, CSV, Parquet files), allowing AI models to execute SQL queries and generate data visualizations for analytics and business intelligence.
    12
    75
    MIT

  • FastPostgresMCP

    llm-graph
    A
    license
    B
    quality
    D
    maintenance
    A blazing fast MCP server that enables AI agents to interact with multiple PostgreSQL databases, providing functionality to list tables, inspect schemas, execute queries, and run transactions.
    4
    121
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AmirTlinov/PSQL_SSH_API_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server