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).

Default index pattern:

If the stand's config sets elastic.indexPattern, it's used as the default index for os_search and os_indices — you can omit index/index_pattern entirely and query logs right away. Check list_services output for the configured indexPattern before falling back to discovery below.