Which integrations are available for this server?

Allows searching OpenSearch indices with Query DSL, listing indices, and inspecting index mappings. Allows executing read-only SQL queries on PostgreSQL databases with connection pooling and safety.

How do I use mcp-tester-helper?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-tester-helper Run a health check on staging" 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.

mcp-tester-helper

by Pstasov

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

mcp-tester-helper

A unified MCP (Model Context Protocol) server for multi-stand infrastructure testing: REST APIs, PostgreSQL databases, and OpenSearch — all through a single config file.

Built for DevOps, QA, and developers who need AI-assisted testing across multiple environments (stands).

Features

🔀 Multi-stand — switch between dev / test / prod environments via config
🔒 Secure auth — OAuth tokens and DB credentials stay server-side, never exposed in AI chat
🌐 REST API — test any microservice endpoint with auto-authentication
🐘 PostgreSQL — run SQL queries with connection pooling and read-only safety
🔍 OpenSearch — search logs, list indices, inspect mappings via Query DSL
📋 Service Discovery — AI can list available stands and services
❤️ Health Checks — verify stand infrastructure availability

Related MCP server: Postmancer

Quick Start

npx -y mcp-tester-helper --config ./config.json

Configuration

MCP Client Setup

Add to your MCP client configuration (Claude Desktop, Antigravity, Cursor, etc.):

{
  "mcpServers": {
    "infra": {
      "command": "npx",
      "args": ["-y", "mcp-tester-helper", "--config", "/path/to/config.json"],
      "env": {
        "STAGING_USERNAME": "admin",
        "STAGING_PASSWORD": "secret",
        "REST_ENABLE_SSL_VERIFY": "false"
      }
    }
  }
}

Config File (`config.json`)

{
  "stands": {
    "dev": {
      "auth": {
        "url": "https://auth.dev.example.com/oauth/token",
        "type": "json",
        "user": "DEV_USERNAME",
        "pass": "DEV_PASSWORD"
      },
      "elastic": {
        "url": "https://opensearch.dev.example.com:9200",
        "user": "DEV_ELASTIC_USER",
        "pass": "DEV_ELASTIC_PASS"
      },
      "database": {
        "host": "db.dev.example.com",
        "port": 5432,
        "db": "dev_db",
        "user": "DEV_DB_USER",
        "pass": "DEV_DB_PASS"
      },
      "services": {
        "billing": {
          "url": "https://billing.dev.example.com/api",
          "openapi": "api-docs/billing.json"
        }
      }
    }
  }
}

Note: user and pass fields contain environment variable names, not actual credentials. Actual values come from .env file or MCP client env config.

Auth Types

Type	Description	Content-Type
`json` (default)	`{"username":"...","password":"..."}`	`application/json`
`oauth2`	`grant_type=password&username=...&password=...`	`x-www-form-urlencoded`

Environment Variables

Variable	Description	Default
`REST_RESPONSE_SIZE_LIMIT`	Max response body size in bytes	`10000`
`REST_ENABLE_SSL_VERIFY`	Set to `false` to skip SSL cert verification	`true`

Tools Reference

`test_request` — HTTP API Calls

Test a REST API endpoint with auto-authentication.

{
  "stand": "staging",
  "service": "orders",
  "method": "GET",
  "endpoint": "/api/v1/health"
}

Parameter	Required	Description
`stand`	✅	Target stand name
`service`	✅	Service name from config, or `"elastic"` for OpenSearch
`method`	✅	`GET`, `POST`, `PUT`, `DELETE`, `PATCH`
`endpoint`	✅	Path (e.g. `/api/v1/users`)
`body`		Request body (for POST/PUT/PATCH)
`headers`		Extra headers (don't pass Authorization)

`db_query` — PostgreSQL Queries

Execute read-only SQL queries with connection pooling.

{ "stand": "staging", "query": "SELECT * FROM schema.table LIMIT 10" }

All queries run inside BEGIN TRANSACTION READ ONLY — data modifications are blocked.

`os_search` — OpenSearch Query DSL

Search OpenSearch indices using the full Query DSL.

{
  "stand": "staging",
  "index": "app-logs-*",
  "query_body": {
    "query": { "match": { "level": "ERROR" } },
    "size": 10,
    "sort": [{ "@timestamp": "desc" }]
  },
  "fields": ["@timestamp", "message", "level"]
}

`os_indices` — List OpenSearch Indices

{ "stand": "staging", "index_pattern": "app-logs-*" }

`os_mappings` — Index Mappings

{ "stand": "staging", "index": "app-logs-2025.07" }

`list_services` — Service Discovery

{ "stand": "staging" }

Returns all services, database, and OpenSearch info for the stand.

`health` — Infrastructure Health Check

{ "stand": "staging", "target": "all" }

Pings services, OpenSearch, and PostgreSQL. Returns status and timing for each.

Security

🔐 Auth tokens are obtained automatically and cached server-side (with TTL)
🚫 Credentials never appear in tool responses sent to the AI
🔄 Automatic token refresh on 401 responses
📖 All SQL queries are wrapped in read-only transactions
✂️ Response bodies are truncated to prevent token overflow

Credits & Attribution

This project is built upon and inspired by the following open-source projects:

dkmaker/mcp-rest-api (MIT License) — REST API testing MCP server, used as the foundation for HTTP client and MCP server structure.
modelcontextprotocol/servers — server-postgres (MIT License) — Official PostgreSQL MCP reference implementation. Connection pooling and read-only transaction patterns.
elastic/mcp-server-elasticsearch (Apache-2.0 License) — Official Elasticsearch MCP server. Tool design for search, indices, and mappings (reimplemented from Rust to TypeScript for OpenSearch compatibility).

License

MIT

Available Tools

7 tools

db_queryA

Execute a read-only SQL query against a stand's PostgreSQL database. Use schema-qualified table names (e.g. "SELECT * FROM orders.users").

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL query. Use schema-prefixed table names (e.g. "SELECT * FROM schema.table").
`stand`	Yes	Target stand (e.g. staging)

TDQS

A4/5.0

Behavior3/5

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

States read-only nature clearly, but no further behavioral traits like error handling or response format are disclosed; no annotations provided.

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

Conciseness5/5

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

Two concise sentences with no redundant information, directly conveying the core purpose and a key usage instruction.

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

Completeness4/5

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

Given the two simple parameters and no output schema, the description adequately covers purpose and a critical usage guideline; missing minor details like result format.

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 already describes both parameters (100% coverage); description reinforces the schema-qualified naming requirement without adding substantial new meaning.

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

Purpose5/5

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

Clearly states it executes read-only SQL queries against a PostgreSQL database and emphasizes schema-qualified table names, distinguishing it from sibling tools.

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

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use schema-qualified table names with an example, but lacks explicit guidance on when not to use or alternatives.

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

healthB

Check availability of a stand's infrastructure: services, OpenSearch, and PostgreSQL.

ParametersJSON Schema

Name	Required	Description	Default
`stand`	Yes	Target stand (e.g. staging)
`target`	No	What to check. Default: "all"

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so the description must carry the burden. It describes a read operation but does not disclose any behavioral traits such as error handling, caching, authentication needs, or side effects beyond the obvious.

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

Conciseness5/5

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

Single sentence, front-loaded, no wasted words. The description is appropriately concise for a simple health-check tool.

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 tool's simplicity (2 params, no output schema), the description is minimally complete but lacks detail on the return format or any caveats, leaving the agent to infer behavior.

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 coverage is 100% and the description adds no new meaning beyond what the schema already provides. The parameters 'stand' and 'target' are fully described in the schema.

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

Purpose5/5

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

The description clearly states the verb 'check' and the resource 'infrastructure' of a stand, listing specific components (services, OpenSearch, PostgreSQL). It distinguishes from siblings like 'os_mappings' or 'list_services' which focus on specific aspects.

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?

No guidance on when to use this tool vs alternatives or when not to use it. The description only states what it does without any usage context or exclusions.

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

list_servicesA

List available stands and their services, databases, and OpenSearch endpoints from the config file.

ParametersJSON Schema

Name	Required	Description	Default
`stand`	No	Optional: specific stand to inspect. Omit to list all stands.

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It mentions the data source (config file) but does not disclose side effects, auth requirements, or read-only nature. As a list operation, it is likely safe, but this is not explicit.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that efficiently conveys the core purpose without unnecessary words.

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

Completeness5/5

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

For a simple list tool with one parameter and no output schema, the description adequately explains what is returned: stands, services, databases, and OpenSearch endpoints. No critical gaps remain.

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?

The only parameter 'stand' is fully described in the input schema (100% coverage). The tool description adds no additional meaning about the parameter beyond what the schema already provides.

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

Purpose5/5

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

The description clearly states the tool lists available stands with their services, databases, and OpenSearch endpoints from the config file. The verb 'list' is specific and distinct from sibling tools like os_mappings or health.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving configuration info but lacks explicit guidance on when to use it vs alternatives. No exclusions or when-not-to-use are provided.

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

os_indicesB

List available OpenSearch indices with doc counts and sizes.

ParametersJSON Schema

Name	Required	Description	Default
`stand`	Yes	Target stand (e.g. staging)
`index_pattern`	No	Optional index pattern (e.g. "app-logs-"). Default: ""

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, required permissions, rate limits, or side effects. It only states the action without additional context.

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

Conciseness5/5

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

The description is a single, concise sentence that immediately conveys the tool's purpose. Every word is necessary, with no redundancy or extraneous information.

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?

The description lacks details about the return format, pagination, or sorting, and there is no output schema to compensate. For a listing tool, this information would be useful for the agent to parse results correctly.

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 coverage is 100%, with both parameters (stand and index_pattern) having descriptions. The tool description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the verb 'list', the resource 'OpenSearch indices', and the specific information returned ('doc counts and sizes'). It effectively distinguishes from sibling tools like os_mappings (which shows mappings) and os_search (which performs searches).

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?

No guidance on when to use this tool versus alternatives, no prerequisites or exclusions provided. The description merely states what the tool does without contextual usage advice.

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

os_mappingsA

Get field mappings for a specific OpenSearch index.

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes	Index name to get mappings for
`stand`	Yes	Target stand (e.g. staging)

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It implies a read-only operation ('get') but does not disclose any behavioral traits beyond that, such as permissions needed or response format.

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

Conciseness5/5

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

Single sentence with no unnecessary words. Front-loaded and to the point.

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

Completeness4/5

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

For a simple retrieval tool with full schema coverage and no output schema, the description is sufficient. However, it might benefit from mentioning that it returns the mapping structure, though that is implied.

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 explains both parameters. The description adds no additional meaning beyond what is already in the schema.

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

Purpose5/5

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

The description uses a specific verb 'Get' and resource 'field mappings' with a clear target 'specific OpenSearch index'. It distinguishes itself from sibling tools like os_search (search) and os_indices (list indices).

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?

No guidance on when to use this tool versus alternatives (e.g., os_search or os_indices) or any prerequisites. The description does not address context or exclusions.

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

os_searchB

Search an OpenSearch index using Query DSL. Use for log analysis and data queries.

ParametersJSON Schema

Name	Required	Description
`index`	Yes	Index name to search (e.g. "app-logs-*")
`stand`	Yes	Target stand (e.g. staging)
`fields`	No	Optional: fields to return in _source
`query_body`	Yes	Complete OpenSearch Query DSL body (query, size, from, sort, aggs, etc.)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It fails to disclose side effects, permissions, rate limits, or any behavior beyond the search action. The description is too brief to convey behavioral traits.

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

Conciseness5/5

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

Two sentences with no fluff. Purpose is front-loaded and the description is well-structured and concise. Every sentence is meaningful.

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?

No output schema and no behavioral details. The tool involves nested Query DSL objects, but the description does not cover pagination, error handling, or return format. Incomplete for a search tool of this complexity.

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 coverage is 100% with all parameters described. The description does not add extra meaning beyond the schema; it only mentions 'Query DSL' which is already in the schema's parameter description. Baseline score of 3 is appropriate.

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?

Clearly states it searches an OpenSearch index using Query DSL, with a specific use case for log analysis and data queries. Distinguishes from siblings like db_query (database) and os_mappings (mapping info), but does not explicitly contrast with them.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a hint about when to use (log analysis and data queries) but no explicit guidance on when not to use or alternatives. The context from sibling tools implies differentiation but the description itself lacks exclusions.

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

test_requestA

Test a REST API or OpenSearch endpoint on a specific stand. Auth is handled automatically.

ParametersJSON Schema

Name	Required	Description
`body`	No	Optional request body
`stand`	Yes	Target stand name (e.g. dev, test, staging)
`method`	Yes	HTTP method
`headers`	No	Optional headers. Do NOT pass Authorization here.
`service`	Yes	Service name from config (e.g. billing, orders) or "elastic" for OpenSearch
`endpoint`	Yes	Endpoint path (e.g. "/api/v1/users")

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behaviors. It mentions automatic auth, but does not describe request behavior (e.g., side effects, error handling, response format), which is critical for a mutation-capable tool (supports POST, PUT, DELETE).

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

Conciseness5/5

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

The description is two sentences, front-loaded with purpose, and contains no redundant information. Every word serves a clear function.

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 6 parameters, 4 required, and no output schema, the description covers the core purpose and auth behavior but lacks details on response structure, error handling, or rate limits. Adequate but leaves gaps for complete understanding.

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 baseline is 3. The description adds minimal parameter-specific insight beyond the schema, except for the headers note to avoid Authorization. No additional semantics for other params.

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

Purpose5/5

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

The description clearly states the verb 'test' and the resource 'REST API or OpenSearch endpoint on a specific stand', distinguishing it from sibling tools like os_search or db_query which target specific backends.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for testing endpoints with automatic auth, but does not explicitly state when to use this tool versus alternatives (e.g., os_search for OpenSearch queries) or provide scenarios where it should not be used.

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.

7 tool updatesv1.0.0Jul 28, 2026
- First observeddb_query
- First observedhealth
- First observedlist_services
- First observedos_indices
- First observedos_mappings
- First observedos_search
- First observedtest_request

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct operation: infrastructure listing, health checking, endpoint testing, SQL queries, and three OpenSearch operations (indices, mappings, search). No two tools have overlapping purposes.

Naming Consistency4/5

Naming follows a mostly predictable pattern: OpenSearch tools use the prefix 'os_', database tool uses 'db_', and general tools use verb_noun (list_services, test_request). 'health' breaks the verb_noun pattern but is understandable.

Tool Count5/5

Seven tools is a well-scoped set for a testing helper server, covering essential operations without being overwhelming or too sparse.

Completeness5/5

The tools provide comprehensive coverage for read-only testing and debugging of stands, including listing services, health checks, API tests, SQL queries, and OpenSearch exploration. No obvious gaps for the intended purpose.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Testiny Test ManagementOAuth
io.testiny
An MCP server that provides access to Testiny projects, test cases and test runs
Testing & QA Tools Project Management
2
mcpOAuth
io.prisma
MCP server for managing Prisma Postgres.
Databases Developer Tools
247
LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3
SupabaseOAuth
com.supabase
MCP server for interacting with the Supabase platform
Cloud Platforms Databases Developer Tools
32,890

Related MCP Servers

mcp-uni
Developer Tools Agent Orchestration
iHeyTang
A
license
Not graded
quality
C
maintenance
A universal MCP server that acts as a unified gateway for dynamically connecting and managing multiple MCP servers via a single HTTP endpoint.
Updated a year ago (2025-08-26 07:48 UTC)
24
6
MIT
Postmancer
API Testing Developer Tools
hijaz
A
license
Not graded
quality
D
maintenance
A standalone MCP server for API testing and management, allowing AI assistants to interact with RESTful APIs through natural language.
Updated a year ago (2025-08-19 00:45 UTC)
23
28
MIT
Multi-DB MCP Server
Databases Developer Tools
1249zts
F
license
Not graded
quality
D
maintenance
A multi-database MCP server supporting PostgreSQL, ClickHouse, and MySQL that enables database exploration and SQL execution through MCP stdio or HTTP API.
Updated 3 months ago (2026-06-08 03:46 UTC)
-
gibRun MCP Server
Testing & QA Tools API Testing Databases
wirnat
A
license
Not graded
quality
D
maintenance
MCP server for end-to-end API testing with PostgreSQL integration, HTTP requests, Go build automation, and debugging support.
Updated 10 months ago (2025-11-13 03:16 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Pstasov/mcp-tester-helper'

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

mcp-tester-helper

Features

Quick Start

Configuration

MCP Client Setup

Config File (config.json)

Auth Types

Environment Variables

Tools Reference

test_request — HTTP API Calls

db_query — PostgreSQL Queries

os_search — OpenSearch Query DSL

os_indices — List OpenSearch Indices

os_mappings — Index Mappings

list_services — Service Discovery

health — Infrastructure Health Check

Security

Credits & Attribution

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Config File (`config.json`)

`test_request` — HTTP API Calls

`db_query` — PostgreSQL Queries

`os_search` — OpenSearch Query DSL

`os_indices` — List OpenSearch Indices

`os_mappings` — Index Mappings

`list_services` — Service Discovery

`health` — Infrastructure Health Check