mcp-tester-helper

Rules for Working with Multi-Stand Infrastructure

This skill describes the algorithm for the AI assistant to execute requests to corporate services, logs, and databases using the mcp-tester-helper MCP server and a local configuration file.

1. Infrastructure Configuration

All information about stands (environments), their addresses, databases, and OpenAPI specs is stored in the configuration file config.json in the project root.

The AI assistant must before any request:

1. Read config.json.
2. Verify that the target stand (e.g. dev) and service exist in the config.

Structure of config.json:

• Stands (e.g. dev, test, staging, prod).
  • auth — stand authorization settings (URL, env variable names for login/password).
  • elastic — OpenSearch/Elasticsearch cluster access settings (for logs).
  • database — PostgreSQL database connection settings for this stand.
  • services — list of microservices, where the key is the system name (e.g. billing, users).
    • url — base URL of the service.
    • openapi — path to local Swagger/OpenAPI spec file or URL.

2. HTTP API Requests (Tool: test_request)

When the user asks to call a microservice:

1. The AI reads config.json and finds the service url and openapi spec.
2. If needed, studies the Swagger/OpenAPI file using view_file.
3. Calls the test_request tool:

{
  "stand": "dev",
  "service": "billing",
  "method": "POST",
  "endpoint": "/payments",
  "body": { ... }
}

Auth is automatic: the server obtains a token from the stand's auth URL and injects it into the request.

3. OpenSearch / Log Search (Tools: os_search, os_indices, os_mappings)

OpenSearch is part of each stand's infrastructure (the elastic section in config).

Preferred tools for log search:

• os_indices — list available indices (start here to discover index names).
• os_search — search with full Query DSL (for complex queries with filters, aggregations).
• os_mappings — inspect index field mappings before writing queries.