Configure your MCP client

I want to add an MCP server to whatever MCP client you are running inside of. Connect it and leave me in a state where I can call its tools immediately.

Server
- Name: mcpp
- URL: https://mcp.getmany.com.ua/mcp (HTTP / streamable transport)
- Auth: HTTP header Authorization: Bearer gm_YOUR_API_KEY_HERE

Steps
1. Identify which MCP client you're running inside of. If you genuinely cannot tell, ask me once and stop guessing.
2. Find the config file that THIS client actually reads — not just one with a plausible filename. Multiple files named `.claude.json`, `config.json`, `mcp.json`, `settings.json` etc. can coexist in the same home and only one is live. Determine the live one by:
   a. Checking the client's env vars (e.g. CLAUDE_CONFIG_DIR, CURSOR_CONFIG_DIR, CODEX_HOME) and `--help` for an explicit `--config` flag or documented path.
   b. Grepping existing, known-working server names from the client's own `mcp list` (or equivalent) output across candidate files. The file containing those entries is the live one.
   c. If no servers are configured yet, consult the client's official docs for the exact path and schema.
3. Match the schema and scope that ALREADY work in that file. If existing entries live under `projects.<dir>.mcpServers`, a sibling top-level `mcpServers` block may be silently ignored — replicate the structure that's proven to load. Default to user-global scope only if the client supports it there; otherwise tell me which directory the entry will be active from.
4. Add or update the mcpp entry using native HTTP transport with the Authorization header. Do not wrap it in npx mcp-remote or any stdio shim unless the client genuinely has no HTTP support.

Rules
- If an entry named mcpp already exists, print the old URL and old auth value to chat before overwriting. Don't silently destroy a working credential.
- Token hygiene: write the token using your file-edit tools only. Never pipe it through echo, cat <<EOF, printf, curl -H, or any shell command that lands in shell history or logs.
- Verify by reading, not by writing. After editing, run the client's own MCP list/status command (e.g. `claude mcp list`, `cursor mcp ls`, the equivalent for your client). If the new entry does NOT appear there, you wrote to the wrong file, wrong key, or wrong scope — fix it BEFORE reporting success or telling me to restart. An HTTP probe of the endpoint (curl, mcp inspector) only proves the server is up, not that the client loaded it.
- If your first edit lands in the wrong place, revert that file to its original contents instead of leaving dead config behind.

Report back
- Exact file path you edited (and any wrong files you tried first, with note that they were reverted).
- The block you wrote, with the token redacted as ***.
- Confirmation that the client's own list command now shows the new server.
- The exact reload action for my specific client — reconnect button, slash command, or full app restart. Always assume a reload is required for the running session. The live process caches its MCP registry at startup; editing the config does not refresh the live session. Do not claim "no restart needed" based on an external probe — those validate the endpoint, not that this session loaded the tools.
- Two verifications I can run after the reload:
  a. The client's MCP status/list command — proves URL + auth.
  b. Actually invoking one tool from the new server — proves this session loaded the schema.

If anything in this prompt conflicts with what you observe about my client (different config schema, different reload mechanism, scoping rules I didn't anticipate), follow what you observe and tell me what you changed.